gpu - juegos - aplicacion clasica o universal

¿Puedes programar un juego de GPU puro? (9)

Soy un estudiante de maestría en CS, y el próximo semestre tendré que empezar a trabajar en mi tesis. He tenido problemas para idear una tesis, pero decidí que estaría relacionada con Computer Graphics, ya que me apasiona el desarrollo de juegos y deseo trabajar como programador profesional de juegos algún día.

Desafortunadamente, soy algo nuevo en el campo de los gráficos por computadora en 3D, tomé un curso de pregrado sobre el tema y espero tomar un curso avanzado el próximo semestre, y ya estoy leyendo una variedad de libros y artículos para aprender más. Sin embargo, mi supervisor piensa que es mejor si se me ocurre una idea de tesis general ahora y luego dedico tiempo a aprender sobre esto en preparación para hacer mi propuesta de tesis. Mi supervisor me ha proporcionado algunas buenas ideas, pero prefiero hacer algo más interesante por mi cuenta, que espero que tenga que ver con los juegos y me dé más oportunidades para aprender más sobre el campo. No me importa si ya se ha hecho, para mí la tesis es más una oportunidad para aprender sobre las cosas en profundidad y para hacer un trabajo sustancial por mi cuenta.

No sé mucho sobre la programación de GPU y todavía estoy aprendiendo sobre sombreadores e idiomas como CUDA. Una idea que tuve fue programar un juego completo (o tanto como sea posible) en la GPU, incluyendo toda la lógica del juego, la inteligencia artificial y las pruebas. Esto se inspira en la lectura de artículos sobre GPGPU y preguntas como esta . No sé qué tan factible es eso con mi conocimiento, y mi supervisor no sabe mucho acerca de las GPU recientes. Estoy seguro de que con el tiempo podré responder esta pregunta por mi cuenta, pero sería útil si pudiera conocer la respuesta con anticipación para poder considerar otras ideas.

Entonces, si has llegado tan lejos, mi pregunta: si usas solo sombreadores o algo como CUDA, ¿puedes crear un juego 3D completo y simple que explote la potencia bruta y el paralelismo de las GPU? ¿O me falta alguna limitación o diferencia entre las GPU y las CPU que siempre harán que una gran parte de mi código esté vinculado a la CPU? He leído sobre los motores de física que se ejecutan en la GPU, ¿por qué no todo lo demás?

No me importa si ya se ha hecho, para mí la tesis es más una oportunidad para aprender sobre las cosas en profundidad y para hacer un trabajo sustancial por mi cuenta.

Entonces tu idea de lo que es una tesis es completamente errónea. Una tesis debe ser una investigación original. -> edit: estaba pensando en una tesis doctoral, no en una tesis de maestría ^ _ ^

Acerca de su pregunta, los conjuntos de instrucciones y las capacidades de la GPU son muy específicos para las operaciones de punto flotante vectorial. La lógica del juego usualmente hace poco punto flotante y mucha lógica (ramas y árboles de decisión).

Si echas un vistazo a la página de Wikipedia de CUDA verás:

Utiliza un subconjunto del lenguaje C, libre de recursión y sin punteros.

Así que olvídate de implementar cualquier algoritmo de inteligencia artificial allí, que son esencialmente recursivos (como A * para el pathfinding). Tal vez podrías simular la recursión con pilas, pero si no está permitido explícitamente, debería ser por una razón. No tener punteros de función también limita algo la capacidad de usar las tablas de despacho para manejar las diferentes acciones según el estado del juego (se podrían usar construcciones encadenadas if-else, pero algo huele mal allí).

Esas limitaciones en el lenguaje reflejan que la HW subyacente está pensada para realizar tareas de procesamiento de transmisión. Por supuesto, hay soluciones alternativas (pilas, encadenadas si-si no), y teóricamente podrías implementar casi cualquier algoritmo allí, pero probablemente harán que el rendimiento sea muy malo.

El otro punto es sobre el manejo del IO, como ya se mencionó, esta es una tarea para la CPU principal (porque es la que ejecuta el sistema operativo).

El enfoque que puede estar buscando se llama "GPGPU" para "GPU de propósito general". Los buenos puntos de partida pueden ser:

Los rumores sobre éxitos espectaculares en este enfoque han existido desde hace algunos años, pero sospecho que esto se convertirá en una práctica cotidiana en unos pocos años (a menos que las arquitecturas de la CPU cambien mucho y se vuelvan obsoletas).

La clave aquí es el paralelismo: si tiene un problema en el que necesita una gran cantidad de unidades de procesamiento paralelo. Por lo tanto, tal vez las redes neuronales o los algoritmos genéticos pueden ser una buena variedad de problemas para atacar con el poder de una GPU. Tal vez también esté buscando vulnerabilidades en los hash criptográficos (suponer que si se agrieta el DES en una GPU sería una buena tesis). Pero los problemas que requieren un procesamiento en serie de alta velocidad no parecen ser tan adecuados para la GPU. Así que emular un GameBoy puede estar fuera de alcance. (Pero podría considerarse la emulación de un grupo de máquinas de bajo consumo).

Es viable hacer una tesis de maestría sobre un tema y con herramientas que, cuando comienzas, no estás familiarizado. Sin embargo, es una gran oportunidad para tomar!

Por supuesto, una tesis de maestría debe ser divertida. Pero en última instancia, es imperativo que pase con distinción y eso podría significar abordar un tema difícil que ya ha dominado.

Igualmente importante es su supervisor. Es imperativo que resuelva algún problema en el que muestren interés, con el que ellos mismos estén familiarizados, para que puedan interesarse en ayudarlo a obtener una excelente calificación.

Ha tenido un montón de tiempo de pasatiempo para rascarse, sin duda tendrá mucho más tiempo de pasatiempo en el futuro. Pero el tiempo de la tesis de maestría no es el tiempo para pasatiempos desafortunadamente

La respuesta ya fue elegida hace 6 años, pero para aquellos interesados en la pregunta real, Shadertoy, una plataforma WebGL de codificación en vivo, recientemente agregó la función "multipass" que permite la preservación del estado.

Aquí hay una demostración en vivo del juego de ladrillos que se ejecuta en Gpu.

Pensaría que un proyecto que se ocupe de una arquitectura de juego que se centre en múltiples CPU centrales y GPU sería interesante. Creo que este es todavía un área donde se está haciendo mucho trabajo. Para aprovechar el hardware actual y futuro de la computadora, se necesitarán nuevas arquitecturas de juegos. Fui a GDC 2008 y hubo algunas conversaciones relacionadas con esto. Gamebryo tenía un enfoque interesante en el que creaban hilos para procesar cálculos. Puede designar la cantidad de núcleos que desea utilizar para que, de no ser así, no pueda eliminar otras bibliotecas que puedan ser de varios núcleos. Me imagino que los cálculos también podrían dirigirse a GPU. Otros enfoques incluían apuntar a diferentes sistemas para diferentes núcleos para que los cálculos pudieran realizarse en paralelo. Por ejemplo, la primera parte de una charla que se sugirió fue colocar el renderizador en su propio núcleo y el resto del juego en otro. Existen otras técnicas más complejas, pero básicamente todo se reduce a cómo hacer que los datos lleguen a los diferentes núcleos.

Primero, no soy un ingeniero informático, por lo que mis suposiciones no pueden ser un grano de sal, tal vez nano escala.

¿Inteligencia artificial? No hay problema. Hay innumerables ejemplos de redes neuronales que se ejecutan en paralelo en Google. Ejemplo: http://www.heatonresearch.com/encog
Pathfinding? Simplemente intente algunos algoritmos de búsqueda de caminos paralelos que ya están en Internet. Solo uno de ellos: https://graphics.tudelft.nl/Publications-new/2012/BB12a/BB12a.pdf
¿Dibujo? Use la interoperabilidad de dx o gl con cuda o cl para que el dibujo no cruce la línea pci-e. Incluso puede realizar el trazado de rayos en las esquinas, por lo que ya no es necesario luchar con z, incluso con la pantalla de trazado de rayos puro se puede hacer con gpu convencional utilizando un límite de profundidad bajo.
¿Física? La parte más fácil, simplemente itere una integración simple de Euler o Verlet y, con frecuencia, verificaciones de estabilidad si el orden de error es grande.
Mapa / generación de terreno? Solo necesitas un Twister de Mersenne y un triangulador.
¿Guardar partida? Claro, puede comprimir los datos en paralelo antes de escribir en un búfer. Luego, un programador escribe los datos pieza por pieza en el HDD a través de DMA, de modo que no hay retraso.
Recursion Escriba su propio algoritmo de pila utilizando vram principal, no la memoria local, de modo que otros núcleos puedan ejecutarse en frentes de onda y la ocupación de GPU sea mejor.
¿Demasiado entero necesario? Puede convertir a un flotador y luego hacer 50-100 cálculos utilizando todos los núcleos y luego devolver el resultado a entero.
¿Demasiada ramificación? Calcule ambos casos si son simples, de modo que todos los núcleos estén alineados y terminen sincronizados. Si no es así, entonces puedes poner un predictor de ramificación de ti mismo para que la próxima vez, prediga mejor que el hardware (¿podría ser?) Con tu propio algoritmo genuino.
¿Demasiada memoria necesaria? Puede agregar otra GPU al sistema y abrir un canal DMA o un CF / SLI para una comunicación más rápida.
La parte más difícil en mi opinión es el diseño orientado a objetos, ya que es muy raro y depende del hardware para construir pseudo objetos en gpu. Los objetos deben estar representados en la memoria del host (cpu) pero deben estar separados en muchos arreglos en gpu para que sean eficientes. Objetos de ejemplo en la memoria del host: orc1xy_orc2xy_orc3xy. Ejemplos de objetos en la memoria gpu: orc1_x__orc2_x__ ... orc1_y__orc2_y__ ...

Si bien las GPU de hoy tienen una inmensa potencia computacional, lo son, independientemente de cosas como CUDA y OpenCL limitadas a un conjunto restringido de usos, mientras que la CPU es más adecuada para computar cosas generales, con extensiones como SSE para acelerar tareas comunes específicas. Si no me equivoco, algunas GPU no pueden hacer una división de dos enteros de punto flotante en el hardware. Ciertamente las cosas han mejorado mucho en comparación con hace 5 años.

Sería imposible desarrollar un juego que se ejecute por completo en una GPU. Necesitaría la CPU en algún momento para ejecutar algo , sin embargo, hacer que una GPU realice algo más que los gráficos (y la física incluso) de un juego sería ciertamente interesante. , con la trampa de que los desarrolladores de juegos para PC tienen el mayor problema de tener que lidiar con una variedad de especificaciones de máquinas, y por lo tanto tienen que limitarse a incorporar compatibilidad hacia atrás, complicando las cosas. La arquitectura de un sistema será un tema crucial: por ejemplo, la Playstation 3 tiene la capacidad de realizar varios gigabytes por segundo de rendimiento entre la CPU y la RAM, la GPU y la RAM de video, sin embargo, la CPU que accede a la memoria de la GPU llega a un máximo de 12MiB / s.

Todavía estoy esperando un emulador de Gameboy que se ejecute por completo en la GPU, que se alimenta de la propia ROM del juego y de la entrada del usuario actual y se traduce en una textura que muestra el juego, tal vez una segunda textura para la salida de sonido :)

El problema principal es que no puede acceder al almacenamiento persistente, a la entrada del usuario o a la salida de audio de una GPU. Estas partes deben estar en la CPU, por definición (aunque las tarjetas con HDMI tienen salida de audio, pero creo que no se puede controlar desde la GPU). Aparte de eso, ya puedes insertar grandes partes del código del juego en la GPU, pero creo que no es suficiente para un juego en 3D, ya que alguien tiene que introducir los datos en 3D en la GPU y decirle qué sombreadores deben aplicarse a qué parte . Realmente no se puede acceder de forma aleatoria a los datos en la GPU o ejecutar código arbitrario, alguien tiene que hacer la configuración.

Hace algún tiempo, simplemente configuraría una textura con los datos de origen, un destino de procesamiento para los datos de resultados y un sombreador de píxeles que haría la transformación. Luego representó un quad con el sombreado en el objetivo de procesamiento, que realizaría los cálculos, y luego volvería a leer la textura (o la usaría para renderizar más). Hoy en día, la cuarta y quinta generación de sombreadores (Shader Model 4.0 y lo que sea que esté en DirectX 11) se ha simplificado, por lo que puede tener sombreadores más grandes y acceder a la memoria con mayor facilidad. Pero aún tienen que ser configurados desde el exterior, y no sé cómo están las cosas hoy en día con respecto a mantener los datos entre marcos. En el peor de los casos, la CPU tiene que volver a leer desde la GPU y volver a presionar para retener los datos del juego, lo que siempre es algo lento. Pero si realmente puede llegar a un punto en el que un solo ciclo de configuración / representación genérica sería suficiente para que se ejecute su juego, podría decir que el juego se ejecuta en la GPU. Sin embargo, el código sería bastante diferente del código normal del juego. La mayor parte del rendimiento de las GPU proviene del hecho de que ejecutan el mismo programa en cientos o incluso miles de unidades de sombreado paralelo, y no se puede escribir un sombreado que pueda dibujar una imagen en una posición determinada. Un sombreador de píxeles siempre se ejecuta, por definición, en un píxel, y los otros sombreadores pueden hacer cosas en coordenadas arbitrarias, pero no tratan con píxeles . No será fácil, supongo.

Sugeriría probar los puntos que dije. Lo más importante es retener el estado entre marcos, en mi opinión, porque si no puede retener todos los datos, todo es imposible.

DESCARGO DE RESPONSABILIDAD: He realizado un doctorado, pero nunca he supervisado a un alumno, ¡así que tome todo lo que voy a decir con un grano de sal!

Creo que tratar de forzar la mayor cantidad de juego posible en una GPU es una excelente manera de comenzar tu proyecto, pero al final el punto de tu trabajo debería ser: " Hay una parte importante de muchos juegos, pero en eso El estado actual no encaja bien en una GPU: aquí es cómo lo modifiqué para que encajara bien ".

Por ejemplo, Fortran mencionó que los algoritmos de IA son un problema porque tienden a depender de la recursión. Es cierto, pero esto no es necesariamente un factor decisivo: el arte de convertir los algoritmos recursivos en una forma iterativa es visto favorablemente por la comunidad académica, y formaría una buena pieza central para su tesis.

Sin embargo, como estudiante de máster, no tienes mucho tiempo, por lo que realmente necesitarías identificar el núcleo de interés muy rápidamente. No me molestaría en intentar que todo el juego se ajuste realmente a la GPU como parte del resultado de tus maestros: lo trataría como un ejercicio solo para ver qué parte no encajaría, y luego me concentraría solo en esa parte.

Pero tenga cuidado con su elección de supervisor. Si su supervisor no tiene experiencia relevante, debe elegir a alguien más que la tenga.