BenchMark 01: Alien Invasion

[Loover]

20 € a que calculando todo en la CPU y enviando todo de golpe (en los batchs que se puedan) en un DrawPrimitiveUp va más rápido Twisted Evil Incluso se podrian aprovechar los dual core actuales para hacer los calculos multitarea

Fijo que sí, la pregunta es: ¿cuánto? Respondiendo a esa pregunta tendría la que realmente me interesa: ¿merece la pena? :D

No entiendo porque a mi me da más FPS que a vosotros, tengo claramente peor ordenador, ¿por qué será? ¿será el core duo que se porta así de bien?:

Win XP SP2
Portatil Inspiron 9400
1GB RAM - DDR2
CORE 2 DUO Processor T7200 (2.0 GHZ)
Intel Media Accelerator 950 Graphics (128MB) => Caca de la vaca

Modo ventana: 95 FPS
Pantalla completa: 86 FPS

El caso es que nada más empezar, me da unos 50 fps o así, y un segundo después ya subre a las otras cifras.

[[EX3]]

Intel Media Accelerator 950 Graphics (128MB) => Caca de la vaca

No te creas. La 950 pego un cambio muy fuerte en rendimiento respecto a la 945, la que use esta mañana. Aun asi, en cuanto reinstale el Vista en el MacBook te lo confirmo.

El caso es que nada más empezar, me da unos 50 fps o así, y un segundo después ya subre a las otras cifras.

Eso es muy tipico y le pasa a casi todos los juegos o programas multimedia que conozco. Supongo que se tratara de alguna historia la gestion de recursos de la ventana o similar, alguna carga o gestion en segundo plano.

Salu2...

P.D.: Voy a ver si te puedo hacer la prueba con el AMD y la GeForce3.

[[EX3]]

Joder, va a ser que mi escritorio en mosaico semi ASCII semi iconos y demas artefactos graficos en el inicio anterior no era casualidad, eso o tu codigo se comporta de forma muy extraña segun tarjeta grafica :D

La tostadora de los 86º en 1 minuto:
AMD Athlon XP 1600+ (1533 MHz) medio jubilado... (chochea mas que el abuelo de los Simpsons)
1 GB de RAM (intactos espero xD)
nVidia GeForce 3 Titanium 64 Mb + Ultimos drivers para esta tarjeta
DirectX 9.0c + Actualizacion Noviembre 2007
Windows XP Pro SP2 Actualizado al dia

La prueba de 1024x768 me ha dado una media de 30/35fps nada mas!  :shock: Cojon! si la 950 del MacBook con el apoyo del Dual 2 Core no es capaz de mover el Half-Life 2 al minimo decentemente y la GeForce 3 soportando las chocheces del AMD tostado va sobrada! raro raro xDDDDDDD

La prueba de 1440x900 como me esperaba ni ha arrancado, si era en modo a pantalla completa, como leo en el log, era de esperar. Esa resolucion no la soporta mi monitor, lo mas cercano es 1600x900 (otra rara de las muchas que hay) y la anterior ya pasa al estandar 1280x1024. Te lo dije, las resoluciones panoramicas son un juego de azar segun monitores :D

Salu2...

[Loover]

Pues si es raro, pero vamos, no hago nada fuera de lo normal. Un DrawPrimitiveUp por objeto, como dije. Parece ser que cuando hay muchas llamadas a DrawPrimitiveUp seguidas, la aplicación se vuelve más dependiente de la CPU que de la GPU... ¿parece eso, no?

[zupervaca]

Hola,

Pues si es raro, pero vamos, no hago nada fuera de lo normal. Un DrawPrimitiveUp por objeto, como dije. Parece ser que cuando hay muchas llamadas a DrawPrimitiveUp seguidas, la aplicación se vuelve más dependiente de la CPU que de la GPU... ¿parece eso, no?

Hace unos años que ya comprobe esto con el test de los conejos de mi pagina web y ahora miles de tutoriales ya lo explican por fin, lo mejor que puedes hacer es que si vas a pintar la misma texturas repetidas veces tengas un vertexbuffer e indexbuffer grande y lo modifiques por con la cpu. (el indexbuffer solo se tendria que modificar una vez, cuando se cree)
El problema al usar una llamada por objeto es que la cpu espera a la confirmacion de la gpu de que lo ha pintado, asi que la cpu se queda parada mientras tanto.
Otro de los problemas es que cada llamada direct3d va a tener que llegarle al driver, cosa mala y que se debe de evitar ya que todas las llamadas de tu juego que salgan del codigo de tu juego seran lentisimas, de hay aquel codigo para el manager de cambios de estados.

Para demostrarte lo que te comento prueba este test de velocidad de los conejos que hice por el año 2006: http://www.davidib.com/projects/rabbits/rabbits.zip

Saludos

PD: El test de los ovnis me da ~53fps

[Loover]

Sip, es lo que comentó prompt y algunos más en otro hilo.

He probado los conejillos. El de Direct3d no se me inicia, en ogl, para cantidades altas se ralentiza bastante. ¿Eso es una llamada a Draw por conejo no? Es decir, como no debería hacerse en teoría. ¿No?

Pero lo malo de hacer solo una llamada a DrawPrimitive es:

Entiendo que podría calcular las posiciónes de los vértices de cada sprite y almacenarlos en un array y luego llamar a DrawPrimitive. Pero... ¿cómo le aplico a cada sprite diferente un estado de blending distinto llamando una sola vez a DrawPrimitive? Por que a mis sprites, a cada uno independientemente, le puedes cambiar el entitando, nivel de fade a un color, nivel de transparencia y el source y destination blending. ¿Hay alguna forma de almacenar dichos valores por vértice o algo así?

Porque está claro que si quieres hacer una sola llamada gigante a DrawPrimitive POR TEXTURA (pq no puedes hacer SOLO UNA llamada si cambia la textura, ¿no?), se lo tienes que pasar todo "mascado", vamos, todo transformado, no solo en el espacio, sino también lo que he citado de los estados de blending y demás.

Aparte, tendría que activar el DepthBuffer (cosa que ahora mismo no hago pues me basta con ordenar la lista de sprites por Z antes de dibujar).

[AK47]

El color se puede guardar en los vertices, por lo que en ese caso si podrias dibujar todos a la vez. En cuanto a estados de blending, deberias agrupar los sprites por estado. Asi, tienes una lista de estados por blending, y dentro de cada estado los ordenas por textura. Si hay mas cosas a tener en cuenta, pues tendras que aumentar esta jerarquia para acomodar todos los casos. La idea es que si mas de un sprite tienen todo en comun, deben ir en la misma llamada DrawPrimitive(UP). En total igual harias algo asi como 10 llamadas de dibujado por frame, por ejemplo.

Por cierto, haces culling de los sprites en el test de los ovnis?

En cuanto a lo de usar hilos, puedes tirar de los hilos de boots, que son portables. O sino te paso el mio que no es portable pero es muchisimo mas ligero que bajarse toda la libreria boost ;)

[Loover]

He desactivado el culling ;)

La idea era probar si había diferencias entre DrawPrimitive y DrawPrimitiveUp => según el test, al menos para quads, no la hay.

Luego os mando una con el culling activado.

Lo de los hilos, lo dejo de momento. No voy a meterme con optimización aún (o quizás nunca).

[Vicente]

He probado el test de los conejos en DX y OGL y si parece aprovechar la máquina mejor.

En DX:

- tengo unos 90 FPS con 13.000 conejos.
- con 30.000 conejos se me queda en 33 FPS.

En OGL:

- tengo como máximo 60 FPS (parece que esté limitado? en DX no lo está)
- con 30.000 conejos se me queda en 38 FPS.

Por si valen de algo los números para comparar. Un saludo!

Vicente

[[EX3]]

Este tema me esta interesando cada vez mas, me temo. Acabo de hacer una prueba de estres con mi libreria dibujando una textura 128x128 cubriendo toda la pantalla (1024x768) y dibujando en todos los niveles de Z (17 en total, de -8 a 8, un total de 1070 sprites) y no pasa de 28fps en la GeForce 3 :( A mi si me va a tocar mirar lo de usar vertexbuffers si quiero meter caña al render de dx_lib32 y la verdad que hacer agrupaciones de vertexbuffers por jerarquias segun textura o renderstates como comentais si podria hacerlo tal y como tengo diseñado el render, pero seria casi como reescribirlo por completo, lo que no me merece tanto la pena a dia de hoy.

Tengo una pregunta para los expertos en materia. Yo utilizo el specular en los vertices para aplicar efectos de iluminacion en los sprites, al igual que el color de vertice. Mi duda viene en si yo en un vertexbuffer tengo definido dos sprites juntos. No se si estos compartirian vertices al estar consecutivos (la esquina superior derecha de uno seria la esquina superior izquierda del segundo), esto no haria que se aplicaran colores de un vertice sobre ambos sprites? A lo mejor es una burrada lo que pregunto pero es que no me queda claro el funcionamiento de los vb.

Salu2...

P.D.: Pregunto esto aqui por que supongo que a Loover si se ve en la necesidad de implementar los vb tambien le entrara la misma duda.

[AK47]

Si los poligonos de dos sprites usan el mismo vertice, por supuesto que compartiran el specular o cualquier otra propiedad del vertice.

Lo de agrupar por estado del blender, textura, etc, es una de las partes criticas de cualquier motor 3D: hay que identificar que estados se pueden dar, y en funcion de eso crear los grupos y subgrupos que tocan a cada estado. Vamos, lo que se llama batching :)

[[EX3]]

Si los poligonos de dos sprites usan el mismo vertice, por supuesto que compartiran el specular o cualquier otra propiedad del vertice.

No me referia a que fuera mismo el vertice si no que hubiera dos vertices con las mismas coordenadas. Me referia mas a que si al procesar el buffer la GPU no mezclaria o "simplificaria" los dos vertices en uno, por algun proceso de optimizacion o algo similar, no?

Salu2...

[AK47]

Si son dos vertices diferentes, aún teniendolo todo igual la GPU los tratara por separado.

[[EX3]]

Genial pues :) Gracias por resolverme la duda.

Salu2...

[zupervaca]

Si quieres un codigo de ejemplo pasate por aqui: http://www.codeplex.com/dibplus/Release/ProjectReleases.aspx?ReleaseId=610
No digo que sea el mejor codigo del mundo, pero como guia te valdra.
La clase que te interesa esta en System/Drawing/sprite.h
Si le pegas un ojo veras que se crea un vertexbuffer e indexbuffer, este ultimo se inicializa una vez (cuando se crea) y el vertexbuffer se le ponen valores mas o menos coherentes (aunque no haria falta).
Para comenzar el render se llama a la funcion Begin y cuando quieres terminarlo a la End, despues entra la llamada a estas dos funciones tienes funciones que te permiten cambiar el estado de los sprites, estas propias funciones se encarga de pintar todo si es necesario, es decir, si cambia algun estado del render.

Saludos y espero que esto te ayude a mejorar la dx_lib32