.net - tarjeta - world of warcraft no ha podido iniciar la aceleracion 3d solucion
Representación gráfica con aceleración 3D (12)
Esto hace que rendericemos aproximadamente 25 millones de muestras en una sola pantalla.
No, no, a menos que tengas una pantalla realmente grande . Dado que la resolución de la pantalla es probablemente más de 1.000 a 2.000 píxeles de ancho, realmente debería considerar diezmar los datos antes de graficarlos. Representar gráficamente un centenar de líneas en 1.000 puntos por línea probablemente no constituirá un gran problema, en cuanto al rendimiento.
Generamos gráficos para grandes conjuntos de datos. Estamos hablando de 4096 muestras por segundo y 10 minutos por gráfico. Un cálculo simple genera 4096 * 60 * 10 = 2457600 muestras por gráfico de líneas. Cada muestra es una FP de doble (8 bytes) de precisión. Además, renderizamos múltiples linegraphs en una pantalla, hasta alrededor de cien. Esto hace que rendericemos aproximadamente 25 millones de muestras en una sola pantalla. Utilizando el sentido común y los trucos simples, podemos obtener este código de rendimiento utilizando la CPU dibujando esto en un lienzo en 2D. Performant, es decir, los tiempos de renderización caen por debajo de un minuto. Como se trata de datos científicos, no podemos omitir ninguna muestra. En serio, esta no es una opción. Ni siquiera empieces a pensar en eso.
Naturalmente, queremos mejorar los tiempos de renderización utilizando todas las técnicas disponibles. Multicore, pre-rendering, caching son todos bastante interesantes pero no lo cortan. Queremos un renderizado de 30FPS con estos conjuntos de datos como mínimo, preferimos 60FPS. Ahora, este es un objetivo ambicioso.
Una forma natural de descargar la representación de gráficos es usar la GPU del sistema. Las GPU están hechas para trabajar con enormes conjuntos de datos y procesarlos en paralelo. Algunas pruebas simples de HelloWorld nos mostraron una diferencia de día y de noche en la velocidad de renderizado, usando la GPU.
Ahora el problema es que las API de la GPU como OpenGL, DirectX y XNA están hechas para escenas en 3D. Por lo tanto, usarlos para representar gráficos de líneas 2D es posible, pero no ideal. En la prueba de conceptos que desarrollamos, nos encontramos con que necesitamos transformar el mundo 2D en un mundo 3D. De repente tenemos que trabajar con el sistema de coordenadas XYZ con polígonos, vértices y más de la bondad. Eso está lejos de ser ideal desde una perspectiva de desarrollo. El código se vuelve ilegible, el mantenimiento es una pesadilla y se producen más problemas.
¿Cuál sería su sugerencia o idea para esto en 3D? ¿Es la única manera de hacer esto para convertir realmente los dos sistemas (coordenadas 2D versus coordenadas 3D y entidades)? ¿O hay una forma más elegante de lograr esto?
-¿Por qué es útil hacer múltiples muestras en un píxel? Ya que representa el conjunto de datos mejor. Digamos en un píxel, tenemos los valores 2, 5 y 8. Debido a algunos algoritmos de omisión de muestra, solo se dibuja el 5. La línea solo iría a 5 y no a 8, por lo tanto, los datos están distorsionados. También podría argumentar lo contrario, pero el hecho es que el primer argumento cuenta para los conjuntos de datos con los que trabajamos. Esta es exactamente la razón por la cual no podemos omitir las muestras.
No necesita eliminar puntos de su conjunto de datos real, pero seguramente puede refinarlo gradualmente cuando el usuario amplía. No sirve de nada 25 millones de puntos a una sola pantalla cuando el usuario no puede procesar todo eso. datos. Recomendaría que eche un vistazo a la biblioteca de VTK y a la guía de usuario de VTK, ya que hay información invaluable sobre cómo visualizar grandes conjuntos de datos.
Muchas gracias. Esto es exactamente lo que estaba buscando. Parece que VTK utiliza hardware para descargar este tipo de renderizado, también. Por cierto, supongo que te refieres valioso ;). En segundo lugar, el usuario obtiene información del ejemplo que di. Sin embargo, no es realmente conciso, la visión general de los datos puede ser oro puro para el científico. No se trata de procesar todos los datos para el usuario, se trata de obtener información valiosa de la representación. Los usuarios parecen hacer esto, incluso en la representación muy "alejada" del conjunto de datos.
¿Alguna más sugerencia?
No, no, a menos que tengas una pantalla realmente grande. Dado que la resolución de la pantalla es probablemente más de 1.000 a 2.000 píxeles de ancho, realmente debería considerar diezmar los datos antes de graficarlos. Representar gráficamente un centenar de líneas en 1.000 puntos por línea probablemente no constituirá un gran problema, en cuanto al rendimiento.
En primer lugar, no podemos omitir ninguna muestra cuando renderizamos. Esto es imposible. Esto significaría que la representación no es precisa para los datos en los que se basa el gráfico. Esto realmente es un área prohibida. Período.
En segundo lugar, estamos representando todas las muestras. Es posible que múltiples muestras terminen en el mismo píxel. Pero aún así, lo estamos representando. Los datos de muestra se convierten en la pantalla. Por lo tanto, se representa. Uno puede dudar de la utilidad de estos datos visualizados, por los científicos (nuestros clientes) en realidad están exigiendo que lo hagamos de esta manera. Y tienen un buen punto, en mi humilde opinión.
Envuelva la biblioteca en una biblioteca bidimensional más amable, con la Z y las rotaciones configuradas en 0.
-Adán
Mark Bessey lo mencionó, que podría carecer de los píxeles para mostrar el gráfico. Pero dadas tus explicaciones, supongo que sabes lo que estás haciendo.
OpenGL tiene un modo ortogonal que tiene una coordenada z dentro (0; 1). No hay proyección de perspectiva, los polígonos que dibuje serán planos para el área de recorte de pantalla.
DirectX tendrá similar. En OpenGL, se llama gluOrtho2d ().
No estoy seguro si esto es útil, pero ¿podría usar el tiempo como medida? es decir, ¿un cuadro es una z? Eso podría aclarar las cosas, tal vez? Entonces, ¿quizás podría estar aplicando deltas efectivamente para construir (es decir, en el eje z) la imagen?
OpenGL se complace en representar 2D si configura la proyección para que sea Ortho (no z). También debes diezmar tus datos. Prestar el mismo píxel 1000 veces es un desperdicio de GPU. Dedique su tiempo por adelantado con un decifrador de múltiples hilos de performat. Asegúrate de disparar grandes arreglos en la GPU usando arreglos de vértices u objetos de búfer de vértice (claramente soy un tipo de tipo OpenGL)
Realmente no tienes que preocuparte por el eje Z si no quieres. En OpenGL (por ejemplo), puede especificar vértices XY (con implícito Z = 0), girar el zbuffer, usar una matriz de proyección no proyectiva, y listo, está en 2D.
Si su código no se puede leer porque está tratando directamente con las cosas en 3D, necesita escribir una delgada capa de adaptador que encapsule todas las cosas 3D OpenGL y tome datos 2D en una forma conveniente para su aplicación.
Perdóname si me he perdido algo, y estoy predicando un diseño básico orientado a objetos para el coro. Sólo digo''...
Un kit de herramientas realmente popular para la visualización científica es VTK , y creo que se adapta a sus necesidades:
Es una API de alto nivel, por lo que no tendrá que usar OpenGL (VTK se basa en OpenGL). Existen interfaces para C ++, Python, Java y Tcl. Creo que esto mantendría tu código bastante limpio.
Puede importar todo tipo de conjuntos de datos en VTK (hay muchos ejemplos de imágenes médicas a datos financieros).
VTK es bastante rápido, y puede distribuir tuberías de gráficos VTK en varias máquinas si desea hacer visualizaciones muy grandes.
Respecto a:
Esto hace que rendericemos aproximadamente 25 millones de muestras en una sola pantalla.
[...]
Como se trata de datos científicos, no podemos omitir ninguna muestra. En serio, esta no es una opción. Ni siquiera empieces a pensar en eso.
Puede representar grandes conjuntos de datos en VTK mediante muestreo y mediante el uso de modelos LOD. Es decir, tendrías un modelo donde veas una versión de baja resolución desde muy lejos, pero si acercas la imagen verás una versión de mayor resolución. Así es como se realiza una gran cantidad de grandes conjuntos de datos.
No necesita eliminar puntos de su conjunto de datos real, pero seguramente puede refinarlo gradualmente cuando el usuario amplía el zoom. No sirve para procesar 25 millones de puntos en una sola pantalla cuando el usuario no puede procesar todo eso. datos. Recomendaría que eche un vistazo a la biblioteca de VTK y a la guía de usuario de VTK, ya que hay información invaluable sobre cómo visualizar grandes conjuntos de datos.
Me gustaría comentar sobre su afirmación de que no puede omitir las muestras, en la parte posterior de la respuesta de tgamblin.
Debería pensar en los datos que está dibujando en la pantalla como un problema de muestreo. Estás hablando de 2.4 millones de puntos de datos, y tratas de dibujarlos en una pantalla de solo miles de puntos (al menos, suponiendo que así sea, ya que te preocupan las tasas de actualización de 30 fps).
Entonces eso significa que por cada píxel en el eje x estás renderizando en el orden de 1000 puntos que no necesitas. Incluso si va por el camino de la utilización de su GPU (por ejemplo, mediante el uso de OpenGL) que todavía es una gran cantidad de trabajo que el GPU tiene que hacer para las líneas que no van a ser visibles.
Una técnica que he utilizado para presentar datos de muestra es generar un conjunto de datos que es un subconjunto de todo el conjunto, solo para renderizar. Para un píxel dado en el eje x (es decir, una coordenada de pantalla de eje X dada), debe representar un máximo absoluto de 4 puntos, que es el y mínimo, y máximo, el más a la izquierda yy más a la derecha. Eso representará toda la información que puede ser útil. Aún puede ver los mínimos y los máximos, y conserva la relación con los píxeles vecinos.
Con esto en mente, puede calcular el número de muestras que caerán en el mismo píxel en el eje x (piénselo como "contenedores" de datos). Dentro de un contenedor dado, puede determinar las muestras particulares para máximos, mínimos, etc.
Para reiterar, este es solo un subconjunto que se utiliza para la visualización, y solo es apropiado hasta que cambien los parámetros de visualización. p.ej. si el usuario se desplaza por el gráfico o hace un zoom, debe volver a calcular el subconjunto de representación.
Puede hacer esto si está utilizando OpenGL, pero dado que OpenGL usa un sistema de coordenadas normalizado (y le interesan las coordenadas de la pantalla del mundo real) tendrá que trabajar un poco más para determinar con precisión los contenedores de datos. Esto será más fácil sin usar OpenGL, pero luego no obtendrá el beneficio completo de su hardware de gráficos.
Quería señalar que, además de usar VTK directamente, hay otros dos productos creados en VTK que pueden interesarle.
1) ParaView (paraview.org) es una interfaz de usuario construida sobre VTK que hace que los productos de visualización científica sean mucho más fáciles. Puede representar todos los datos que desee siempre que tenga el hardware para manejarlos, y admite MPI para múltiples procesadores / núcleos / clústeres. Es extensible a través de complementos creados por el usuario y utiliza herramientas automatizadas para la creación y compilación de proyectos.
2) ParaViewGeo (paraviewgeo.mirarco.org) es un derivado de exploración geológica y minera de ParaView producido por la empresa para la que trabajo. Tiene soporte integrado para leer formatos de archivo que ParaView no tiene, como Gocad, Datamine, Geosoft, SGems y otros. Y lo que es más importante, a menudo trabajamos con otros grupos que tienen interés en el conocimiento científico con un producto libremente vinculado a la minería, como nuestro trabajo reciente con un grupo que hace modelos de elementos finitos / discretos. Vale la pena echarle un vistazo.
En ambos casos (PV y PVG) sus datos se consideran separados de su vista de esos datos, y como tal, nunca "renderizará" todos sus datos (ya que probablemente no tenga un monitor lo suficientemente grande como para hacerlo) pero tenga la seguridad de que todo estará "allí" procesado de su conjunto de datos como esperaba. Si ejecuta filtros adicionales en sus datos, solo lo que se puede ver se "renderizará", pero los filtros se computarán en TODOS sus datos, que aunque no todos sean visibles a la vez, todos estarán en la memoria.
Si está buscando números, hoy calculé tres cuadrículas regulares de 8 millones de células en PVG. Uno contenía una propiedad vectorial de 7 tuplas (7x 8 millones de valores dobles), los otros dos contenían una propiedad escalar (1x 8 millones de valores dobles cada uno) para un total de 72 millones de valores dobles en la memoria. Creo que la huella de memoria era cercana a los 500MB pero también tenía un conjunto de 400,000 puntos donde cada punto tenía una propiedad vectorial de 7 tuplas y algunos otros datos misceláneos disponibles también.