He hecho un programa para probar cómo procesan los triángulos las tarjetas. He implementado 2 técnicas:
1ª técnica: Renderizar el objeto en el momento en el que se pide. De esta forma, la tarjeta y la CPU funcionan en paralelo trabajando al mismo tiempo.
2ª técnica: Crear una lista de vértices enorme por textura y al final de todo el proceso lanzar ese mega-paquete a la tarjeta. He leido en algunos sitios que esto es lo más óptimo...pero yo dudo de que la CPU no se aburra!!
Así que aquí está el programa(
http://webs.ono.com/dracular/test.zip ). Os pido que lo probeis y posteis vuestras especificaciones y que valores os da en los dos métodos, para ver si hay diferencias.
Empiezo yo:
Pentium 200 MMX. Savage 4 32MB W98 96 MB.
Técnica 1:5.25 FPS
Técnica 2:5.25 FPS
(lógico porque yo no tengo GPU!!)
[ Este Mensaje fue editado por: Drácula el 2002-05-03 15:07 ]
Hola Dracula,
En el ordenador del trabajo ni entra, pero claro... aqui tengo un iPentiumIII a 600 con 256MB de RAM pero... una Voodoo3 de 16Mb que, si bien y en teoria no deberia tirar a partir de DirectX7, la hago funcionar con DirectX8.0, sin embargo tu programa me dice que hay que tener instalado el DX8.1. a ver si me lo bajo en un rato y te digo los resultados, de todas formas esta noche cuando llegue a mi casa lo probare, alli tengo mi equipo 'de batalla' (un iPentiumIII a 600MHz con 256 MB de SDRAM pero una TNT2 de 32MB).
Un Saludo
Pues yo, ni me puedo bajar el zip.
:triste: ....
Bueno Dracula, ya he conseguido actualizar la maquina de la oficina, aunque esto es para morirse, y no se si de risa o de pena:
La demostracion funciona, tus modelos planetarios tienen 24520 vertices y 49000 caras, pero de las texturas, ni rastro... :sonriendo:
Es decir, no funciona bien con la Voodoo3, aunque eso si, quitandole la textura, la cosa va bastante bien, de hecho me da (y no esta nada mal para una 3DFx) 18.6 FPS
De todas formas, y como ya te he dicho, cuando esta noche llegue a mi casa lo pruebo con mi TNT2 (misma configuracion de procesador/RAM) y ya te comento...
Un Saludo
P.D. perdona por lo de antes, se me olvido ponerle lo de 'use folder names' al WinZip :sonriendo:
Si, si funciona, ahora si, y los resultados son los siguientes:
Metodo 1: 13.20 FPS
Metodo 2: 13.75 FPS
Como puedes ver en esta maquina no hay mucha diferencia en los metodos de procesamiento,p ero cuando haga la prueba en mi casa ya vere lo que sale
Para _Grey:
Pues el link a mi me funciona... que raro, no?
_________________
Julio Meca
ALPHA SOFTWARE
[ Este Mensaje fue editado por: Emotion el 2002-05-03 17:20 ]
Hi.
Método 1: 43 FPS
Método 2: 7 FPS
GeForce 256
Byez.
Pues ya esta! parece que GetRight no queria bajarlo....
Este es el resultado:
38.XX -> Metodo 1
13.XX -> Metodo 2
G-force2Mx200
Por cierto...... gracias por las texturas XD , de donde las has sacado??
Chao!.
Uhm.. me da a mí que te has pasado con el tamaño de la textura o algo así en el 2º método, porque debería ser más rápido con Tn&L. Busca un papel de Ratcliff en los archivos del GDC 2002 o papers de NVIDIA.
uy, casi se me olvidaba... mi sistema es Win98 sin prebuffer de video (es decir, nada de pildorazos :sonriendo:)
con una tarjeta mala de verdad :sonriendo: :
1: 6,6
2: 6,6
parece como que suda del metodo no? :sonriendo:
S3 Inc. Trio3D/2X
P3 700
128 MB
Windows 98
Yo también he leido ese documento, pero lo puse en duda. Por ello he desarrollado este test. Para mi es clarísimo: Hay que renderizar a cachos.
El 2º método, explicado en el doc ratcliff, se está viendo ineficiente en las aceleradoras que llevan GPU.
De todas, formas..¡seguid enviando vuestros test!
Todos los "pros" hablan de agrupar, todas las tarjetas hablan de llamadas de cientos//miles de triángulos, las DX dicen lo mismo... Sigo creyendo que no has hecho algo bien, pero ando muy liado como para rebatirtelo.
Te recomiendo que postees esto mismo en flipcode(weno, en inglés :lengua:).
No se yo... algo debe de haber mal en el segundo metodo...
P 233 MMX Voodoo Banshee
M1 -> 7 fps aprox
M2 -> 7 fps aprox
PIII 600 Geforce2 MX
M1 -> 32 fps aprox
M2 -> ¡¡6!! fps aprox
Aunque no me atreveria a preguntarte por el codigo que estas usando para el segundo metodo (ya que yo no programo con Direct3D, sino en OpenGL), cual es el metodo que sigues? es decir, algoritmicamente, cual es el proceso que sigues?
Hola Dracula
parece que definitivamente a mi no me entra en modo hardware con Merlin:
W2000, PIII 384M 850MHz, ATI RAGE MOVILITY-M1 16M
Metodo1: 2.70 FPS
Merodo2: 2.70 FPS
Debug:
INICIO Características del Device
HAL (sw vp): ATI RAGE MOBILITY-M1 AGP (Spanish) (D16)
FullScreenGamma OK
CanCalibrateGamma NO DISPONIBLE
Utilizando formato por defecto para las texturas A8R8G8B8
NO Soporta compresión DXT1
NO Soporta compresión DXT2
NO Soporta compresión DXT3
NO Soporta compresión DXT4
NO Soporta compresión DXT5
Escritorio: Ancho=1024 Alto=768
FIN Características del Device
_Grey: aqui hay de esos:
http://maps.jpl.nasa.gov/un saludo
[ Este Mensaje fue editado por: fiero el 2002-05-03 21:31 ]
Método 1:
Para cada esfera:
Procesar los vértices multiplicando por las matrices(esto lo hago para que se utilice la CPU)
Mandar el resultado a la tarjeta
Método 2:
Para cada esfera:
Anexar a una lista todos los vértices, también procesando los vértices haciendo uso intensivo de la CPU.
Y una vez terminado el proceso para cada esfera...
Para cada textura:
Mandar ese paquete enorme a la tarjeta.
Pensad que aunque procese vértices esto NO ES SIGNIFICATIVO, porque la GPU tiene que volverlos a procesar para hallar sus valores XYZRHW.
En el 2º método, es EVIDENTE que la CPU está a la espera todo el tiempo, porque sólo espera a que la tarjeta le permita seguir. Y los resultados son claros. Si no tengo GPU no me afecta para nada, pero si tengo, no la utilizo en paralelo, porque está siempre esperando...
Creo.... creo que ya se el por que de esto, en el Metodo2...
Tienes un vertexbuffer por cada esfera??haces Lock() y UnLock() por todas los vertexbuffer de las esferas??
y lo haces en cada cuadro de animacion??
Lo digo por que no es la manera adecuada de trabajar con los vertexbuffer... ni con los indexbuffers, pero como no se como funciona tu motor, igual no es eso.....
Pero diria que posiblemente sea por eso, o no?
Bueno Dracula, tal y como te prometi, he aqui los resultados con mi equipo de casa. te remito ahora los detalles de la configuracion:
Equipo
CPU - PentiumIII 600MHz
RAM - 256 MB SDRAM PC133 (2x128)
GPU - NVIDIA TNT2 M64/M64Pro 32MB AGP2X
SO - Windows98 SE
API - OpenGL 1.3.0/DirectX 8.1
Optimizaciones
PreBuffer 4MB IRQ11 (VGA+TVTuner+ACPI)
Cache Virtual 512MB Fija separada del Sistema
Version de los Drivers
Detonator4 28.32 OFICIAL
Bueno, pues las pruebas han arrojado un total de 26.33 FPS en el metodo 1 y un total de 29.33 FPS usando el metodo 2, con lo que, como ya te comente con el equipo de oficina, no hay demasiada diferencia, si bien aqui obtengo una tasa de animacion plenamente interactiva... muy buen trabajo :sonriendo:
Ah, casi se me olvidaba... el escritorio lo tengo a 1024x768 en 16bits y el formato de pixel escogido por windows ha sido 16bits en formato RGB 5:6:5
Espero que estos datos te puedan ayudar en algo
Drácula, no entiendo, transformas por software todos los vértices en ambos métodos?
Transformo para hacer algo con la CPU. Fijaos en esto:
Método 1:
CPU Trabajando(Aquí funcionamos en paralelo)
Volcar datos a la tarjeta
continuar con otra esfera
Método 2:
Para cada esfera:
CPU Trabajando
Al terminar:
Para cada textura:
Renderizar el Vertexbuffer(sin usar Locks!!)
continuar con otra textura
Para mi es evidente, que el método 2 hace que la CPU esté esperando porque primero tiene que esperar a que la tarjeta le diga que está libre antes de poder seguir trabajando. Sin embargo en el método 1, después de lanzar los triángulos a la tarjeta, hace muchas más cosas y cuando vuelve a mandar los siguientes, la tarjeta todavía no ha terminado, pero la espera es mínima.
No es paralelizable eso. Para renderizar una esfera ésta primero debe ser transformada. O eso al menos entiendo según la explicación del proceso que haces.
Es como aquello de paralelizar instrucciones de procesador que actúan en escritura+lectura sobre un mismo registro.
mov eax, 10
mov ebx, eax
No pueden ejecutarse en paralelo porque para que se pueda mover a ebx el contenido del registro eax, primero debe de terminar de ejecutarse la anterior instrucción.
mov eax, 10
mov ebx, 10
Sí que podría ejecutarse en paralelo.
Prueba a hacer algo parecido.
Buenas! sin saber exactamente que operaciones (y sobre todo, como y donde bloqueas los vertex buffers) es dificil saber donde se produce el cuello de botella en cada metodo. Por ejemplo, quiza no estes usando DISCARD al hacer lock de los vertex buffers "gordos" del segundo método, y si lo usas puede que de un subidon porque entonces el proceso de transformar todas las esferas si se podría hacer en paralelo con el de pintarlas. Si ya hacias el "d3dlock_discard" entonces habría que seguir analizando uno y otro metodo, de todas formas piensa que lo mas rapido con diferencia es cargar las mallas en memoria de video y usar al 100% el T&L y dejar la cpu para la ia
[ Este Mensaje fue editado por: mallrat el 2002-05-04 19:04 ]
Me respondo a mi mismo :sonriendo:
Lo que he dicho no es cierto, sí que podrían ejecutarse en paralelo si el driver guarda las operaciones a realizar en una cola interna, lo que suele hacer en la mayoría de los casos.
Mea culpa.
Para mallrat:
Pero si no mal recuerdo, Dracula dijo que no tenia GPU, con lo cual el T&L no lo hace por hardware... a no ser que estes hablando de T&L por software
Para Ithaqua:
Es posible paralelizar los comandos al driver? es decir, podria implementar Multithreading para el render con OpenGL??? yo habia oido que no se podia hacer... o sea que si soporta multiples instancias de render usando una cola?? jurrll... me he quedado mas liado que la pata de un romano... explicate :sonriendo:
Emotion:
pues... si, me referia a T&L por HW, aunque él no tenga, supongo que estará haciendo el motor pensando en los que si tenemos (joé que para eso me he gastao la pasta!) :ojo:
en cualquier caso el futuro (bueno, prácticamente el presente) es T&L por HW, así que mejor hacerlo pensando en ello, no?
supongo que Ithaqua se refiere al hecho de que el driver (por lo menos el de DX) va guardando las operaciones que le mandas hacer en una especie de "cola de comandos" por ejemplo si le dices que pinte una cosa de 1000 triangulos, va a volver al instante, el driver realmente lo hará en cuanto termine con la operación anterior.
(este paralelismo se puede estropear de muchas maneras, y eso es lo que hay que tratar de evitar para sacar el maximo de fps)
[ Este Mensaje fue editado por: mallrat el 2002-05-04 21:59 ]
Sí, me refiero al buffer interno de comandos del driver. El propósito es precisamente ese, poder paralelizar al máximo CPU/tarjeta.
De hecho puede darse el caso de que estés operando a nivel de CPU en el frame n, y los resultados en pantalla ser los del n-1, quedando por ejecutarse en la cola todos los comandos de render de un frame entero.
En OpenGL puedes forzar el vaciado de ese buffer (= ejecución de todos los comandos pendientes) con glFlush() o glFinish(). La diferencia es que el último no retorna hasta que se haya ejecutado la última instrucción pendiente.
Creo que hablais de unas cosas que realmente NO son fundamentales. A fin de cuentas, tengamos cachés parelelas o cualquier cosa que querais llamarle, el problema es localizar DONDE debe esperar el proceso. Y es en ses DONDE, cuando debes intentar realizar el paralelismo.
Al más bajo nivel, una tarjeta funciona así:
Esperar si la tarjeta ha terminado de procesar el último paquete
Mandar otro paquete
El cuello está en el trozo de espera. Por ello, si mandamos 2 paquetes seguidos, el 2º paquete tendrá que esperar a que el primero termine. Es evidente que se puede utilizar un sistema caché y tantas cosas que se dicen, pero recordemos que un caché provoca movimiento de memoria, y seguro que será memoria de sistema, por lo que yo PREFIERO QUE NO HAYA CACHE DE ESTE TIPO.
Y ya está, por que la tarjeta POR MUY BUENA QUE SEA, no procesará los triángulos en paralelo, y como primero tiene que terminar uno para que empiece el otro, no debemos mandar paquetes seguidos porque desperdiciamos CPU, como se ha visto claramente en los tests que vosotros mismos habeis realizado.
De todas formas, me gustaría que alguno de los que decís que esto no es así, hicierais lo mismo que yo:un pequeño test. Quizás yo esté equivocado, pero creo que ahora ya no basta la teoría, necesitamos demostraciones prácticas.
Un saludo a todos.
Sigo sin ver cual es la diferencia exacta entre el primero y el segundo. ¿Puedes concretar un poco mas en qué hace cada método? ¿Ambos envían los mismos datos no?
Lo de que la CPU esté en espera, hoy día en la gran mayoría de los casos no es así. Las tarjetas actuales son devoradoras de polígonos, y en motores mal programados (= mayoría) suelen estar bostezando casi todo el tiempo. Lo que está en la espera es la tarjeta, no la CPU.
Lo de la cache que tu dices que no quieres, es precisamente lo que hace que tu tarjeta funcione en paralelo con la CPU si las cosas van bien. Es necesaria.
La diferencia de FPS en tu ejemplo puede deberse principalmente al modo en el que se envían los datos a la tarjeta. Es mucha geometría, y dado que ocupa mucho ancho de banda el método de envío es crítico.
Si en el segundo ejemplo se alcanzan muy pocos FPS, no tiene por qué significar que la CPU esta en espera. Si la tarjeta es capaz de llegar en el primer caso a 130fps, por qué iba a costarle tanto esfuerzo renderizar en el segundo caso lo mismo?
Si esta renderizando a la sexta parte de la velocidad del primer caso los mismos datos, algún problema debe haber en el envío, o mucho proceso esta haciendo la CPU.
Explícame un poco mas a fondo el proceso si puedes :sonriendo:
Drácula, nadie ha hablado de cachés de memoria, los drivers de DX lo que tienen es una cola de comandos enviados a la tarjeta, cuando tu le mandas el segundo paquete no espera a terminar con el primero, básicamente almacena la operación a realizar y vuelve. Algunas tarjetas tienen una cola de comandos bastante grande y pueden llegar a almacenar los comandos para pintar un frame entero (es decir, las llamadas a Draw*Primitive, los cambios de estado, etc) pero por ejemplo si le pides hacer un Lock (y no usas discard o nooverwrite) de algo que está en la cola, entonces si que hace esa espera que tu dices, y precisamente ese es un posible cuello de botella a evitar.
[ Este Mensaje fue editado por: mallrat el 2002-05-05 16:23 ]
Drácula, pedias una prueba:
escenario de 7200 tris y 14000 vert. (aprox)
resolucion 800x600x32
fps: 282 (3.55 mseg)
tiempo de "render": 0.85 mseg.
tiempo de "present": 2.66 mseg
el tiempo de render es el tiempo gastado en llamadas a Draw(*)Primitive / SetTexture / etc.
el tiempo de "present" es lo que ha tardado la llamada a "Present()"
mallrat, no entiendo tu test. El mio se basa en que la cpu haga algo mientras trabaja la tarjeta. Por eso si lanzas todos los triángulos al final, la CPU está a la espera constantemente.
En tu test no me estás diciendo nada.
Repetiré mi teoría:
Imagina que tienes 3 texturas para todos tus polígonos(unos 100.000), y que en total hay 10 objetos.
La técnica 1 transforma los vértices en coordenadas mundo de cada objeto(CPU intensive!!) y lanza el resultado a la tarjeta(unos 10.000 polígonos). Esto se hace para cada uno de los 10 objetos.
La técnica 2 transforma los vértices en coordenadas mundo de cada objeto y anexa el resultado a un vertex buffer asociado a la textura. Una vez procesados todos los objetos, se recorre cada textura y se manda el vertex buffer directamente(sin hacer locks ni nada por el estilo)
El test demuestra que la GPU va guardando los comandos que le envias y los va procesando segun puede. En este caso los procesa durante el Present() ya que el driver no "debe" almacenar mas de un par de frames de comandos, si no recuerdo mal.
Es resumen, demuestra la existencia de un buffer de comandos. El tema está en que tu segundo metodo deberia ser igual de rápido porque mientras pintas todos y haces el Present, supuestamente el driver volveria del Present sin hacer *nada* salvo almacenar esos comandos y mientas calculas las siguientes esferas es cuando se pintan todas las del frame anterior.
Yo creo que la diferencia entre uno y otro en tu caso está en como mandas los datos a traves del agp. De todas formas yo no usaría el segundo metodo, te dará muchos problemas si quieres luego aprovechar el T&L por HW, creeme yo hacia algo parecido y ahora no lo haría ni loco.
El que avisa no es traidor... (un poquito cabron si acaso, eso si :lengua:)
[ Este Mensaje fue editado por: mallrat el 2002-05-05 21:35 ]
Porque no intentas hacer el proceso de envio de datos y lo que es los calculos usando multithreading? esa es la estructura basica de mi motor, y funciona bastante bien para CASI todo, y sobre todo ahora que se que puedo usar multithreading con OpenGL, tal vez puedas usar tu lo mismo, aunque depende de lo que quieras conseguir, claro esta...
De cualquier manera, y si te decides a intentarlo, te puedo pasar algo de codigo si quieres...
Un Saludo
Bien, parece que el tema tiene tomate. Yo no digo que lo que dices sea cierto, todo depende de cómo se programe ese caché.
Lo que sí quedo patente es que el 1er método es más rápido, o por lo menos la forma en la que yo lo he implementado!
Esperemos que haya más test para poder poner un poco de luz a este tema.
Respecto al comentario de Emotion, ¡qué ganas tengo de ver tu engine multithread! A mi me parece que debe complicarse todo un montón, pero...¡espero que me sorprendas! Suerte!
Gracias a todos.
En el ordenador del curro:
PII 400, 256 RAM, Windows 2000 Server
Matrox Millenium G400 DualHead
Metodo 1 -> 22.26 fps (640x499x16)
Metodo 2 -> 22.14 fps (640x499x16)
No entiendo exactamente lo que estas haciendo en lo que cuentas, pero los numeros que esta dando la gente son muy inferiores a lo que se consigue usando una GPU
La manera mas rapida de tirar poligonos con una GPU es
-Guardar los vertices en VBs estaticos
-Guardar los indices en IBs estaticos
-Tener los indices de manera que se aproveche la cache de vertices de la tarjeta (ver webs de nvidia o ati)
-Tener los vertices de manera que la lista de indices recorra ese array la manera mas lineal posible
-Tirar ristras grandes (>500) poligonos
Con eso puedes conseguir facilmente cifras de benchmark. La ultima vez que lo probe con mi motor, conseguia 20 millones de triangulos de segundo en una GF2 MX o 10 millones si usaba geometria con texturas, como unas 50 veces mas rapido de las cifras que esta posteando la gente con GForce