darksch escribió:Pues la verdad es que sí, debe ser para su motor. Porque a mí no me termina de gustar eso de dejar partes sin usar y sobrecargar otras. Es decir, al menos las partes del culling tradicional podían sacarlas del shader, no sé.
Viendo ese intento de macro-batching, también se explica bastante bien los resultados en las diferentes máquinas. Donde mejor va es en PC por la VRAM dedicada, luego PS4 por su GDDR, y por último XOne por su DDR. En XOne ocupar el ancho para transferir en un batching tan bestia le penaliza más. Además de tirar tanto de shader.
No sé, me parece que, aunque lo hayan pasado a DX12, es un motor muy pensado en su diseño para DX11, porque el batching lo quieren llevar al máximo extremo, cuando supuestamente en las nuevas API el overhead es casi nulo, siempre que se haga adecuadamente.
Buenas gente. No es cuestión de dejar funcionalidad fija sin usar (de hecho puedes tener cuellos de botella), es justo al revés, están maximizando el uso y el throughput de la GPU, por ejemplo eliminando los triángulos pequeños que cubren solo un pixel o incluso ninguno. La diferencia de rendimiento no tiene nada que ver con el tipo de memoria, tiene que ver con la potencia de cada máquina. En el paper indican claramente (está en las notas) que usan la eSRAM para tal menester. Por otra parte, tb lo explican en el paper, hacer más llamadas aún siendo mucho más eficiente, no siempre es lo mejor (hay mucho tiempo ocioso), de ahí la opción de usar una única drawcall, que no un batching.
No están haciendo ningún macrobatching al uso, están usando multi draw indirect (disponible en DX12 y desde hace tiempo en OpenGL 4.3), el cual te permite "encapsular" muchas llamadas en un buffer y usar una única drawcall (en OpenGL glMultiDrawElementIndirect/glMultiDrawArraysIndirect) para renderizar "todo del tirón" (realmente no es así pq lo q hace es coger el buffer y empezar a ejecutar las llamadas que hay en ese buffer). Es muchísimo más eficiente pq precisamente no tienes tráfico de datos entre CPU y GPU, también te ahorras el overhead de la API (es una única llamada) y este buffer con llamadas no tiene pq ser construido en la CPU, es la propia GPU la que mediante un compute shader puede "crearse" sus propias drawcalls sin intervención. No es el primer estudio que hace esto. Muchos otros están optando por este acercamiento puesto que es una forma muy muy eficiente de renderizar. Es lo que se llama GPU-driven rendering, o lo q es lo mismo, que la GPU hace un Juan Palomo, yo me lo guiso yo me lo como.
Dejo un artículo muy interesante (2013 en OpenGL de 20 a 40 millones de llamadas por segundo):
http://www.openglsuperbible.com/2013/10 ... ion-draws/Hasta donde yo recuerdo multi draw indirect no está disponible en DirectX 11, por lo que no es un motor pensado en base a DX11, ya q dicha característica no está expuesta en la API (si en el hardware).
darksch escribió:Y más específicamente, en XOne es un desperdicio total, ocupar el ancho en batching, cuando es innecesario. Con una simple llamada indirecta puedes renderizarlo todo, con lo cual lo que toca es sustituir tanto batching por configurar los PSO. Ellos mismos dicen que les ilusiona probarlo, a ver si es verdad y para la próxima lo hacen.
Es q es justamente lo que hacen, un indirect draw. XboxOne tiene una particularidad con respecto al PC que le permite aún más libertad y flexibilidad a la hora de manejar este tipo de llamadas, la cual queda pendiente para el futuro. Esto no quiere decir que no estén usando indirect draw, tan solo que podrán hacer hacer lo mismo pero de otra forma (más eficiente). Meternos en este camino es profundizar mucho y no creo q merezca la pena
.
Un saludo.
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
![[burla3]](/images/smilies/nuevos/burla_ani2.gif "burla3")
