Hardware Transform, duda

[Loover]

Hola,

Estoy intentando separar en un plugin (dll) del tipo "mi_plugin_direct3d_9.dll" todo lo relacionado al render y hacer llamadas desde LooverLib a dichas funciones para no tener que linkar con Direct3d en cada proyecto que use looverlib. Aparte que así luego sería mucho más fácil hacer otros plugins para opengl, sdl o lo que fuera.

Así que, para empezar a eliminar dependencias, estoy pensando en cambiar las funciones de LooverLib del tipo: D3DXMatrixTranslation, D3DXMatrixMultiply, etc por otras mias propias para abstraer la capa de render.

Sin embargo, si las cambio por las mias, no podré beneficiarme del Hardware T&L, ¿cierto?

Entonces, lo correcto, ¿qué sería? ¿Wrapear dichas funciones metiéndolas en "mi_plugin_direct3d_9.dll" en vez de hacer las mias propias? Algo del tipo:

[En "mi_plugin_direct3d_9.dll"
MatrixMultiply (bla bla)
{
   return D3DXMatrixMultiply (bla bla);
}

A ver si me contaís cómo lo haceis vosotros. Un saludo.

[[EX3]]

El objetivo a "largoooooooo plazo" que tiene mi actual proyecto de implementacion a .NET de dx_lib32 es centrar todo lo basico o el nucleo en si de "algo" llamemosle "framework" de forma que solo hiciese falta reescribir dicho nucleo para usar otra cosa que no sea DirectX en mi caso. De esta forma, las capas superiores o librerias satelites les daria igual en que estuviese programado en el nucleo o punta de la piramide, mientras cumpla una interfaz de llamadas no habria problema para usar una cosa u otra.

Salu2...

[Loover]

Yep, yep, de abstracción no hay problema ;) La duda es la otra (en negrita).

[[EX3]]

No me hagas mucho caso pero creo que el T&L tiene que ver mas con las rutinas del core de Direct3D que con la libreria de utiles D3DX (lo digo por las funciones de matrices que mencionas).

Salu2...

P.D.: A lo mejor estoy un poco espeso esta mañana, pero estas pregutando como wrappear correctamente tu libreria con la de DirectX, no?

[En "mi_plugin_direct3d_9.dll"
MatrixMultiply (bla bla)
{
return D3DXMatrixMultiply (bla bla);
}

Si es como este caso que pones, yo al menos si lo haria asi, total, si la libreria base me da ya la funcion que expongo en mi libreria, para que reescribirla?

[senior wapo]

Por lo que tengo entendido las funciones DX* usan SSE2, 3DNow y similares si están presentes. Si te lo montas por tu cuenta pierdes eso a menos que te lo hagas tú.

No tienen nada que ver con el HW T&L. Eso va después en la tuberia y es cosa del driver y la tarjeta. D3DXMatrixMultiply no debería interacionar con la tarjeta para nada.

[Loover]

P.D.: A lo mejor estoy un poco espeso esta mañana, pero estas pregutando como wrappear correctamente tu libreria con la de DirectX, no?

No, eso no es problema. Estoy preguntando lo que pregunté :D, lo que está en negrita. Pregunto si funciones como esas que he puesto (multiplicación de matrices, traslación, transformación de vértices, etc) utilizará Hardware Transformations por GPU en las tarjetas que lo permitan.

Creía que esto era así porque hace tiempo me dijeron que en OpenGl, las funciones de transformación, lo utilizan. Aquí discuten algo parecido: http://www.yakyak.org/viewtopic.php?t=61785&highlight=&sid=7d252629c962c99fe181ded101226643

Y también aquí (http://slashdot.org/article.pl?sid=01/03/23/2051242):

Transform and Lighting is nothing new - all 3D programs do transform - rotations, scales, translations, skews, projection, etc.

Take OpenGL as an example. The "T" (in "T&L") functions are glRotatef, glTranslatef, glScalef, and glMulMatrix. Before there was hardware T&L, people don't use these functions often - they write their own. And it was amazing that even a very simple unoptimized matrix transform code performs better than these gl functions most of the time.

What hardware T&L does (in terms of OpenGL) is to accelerate these functions in hardware - formerly, the OpenGL library does inefficient software transform. Now they'll just blast the arguments to some chip registers and let it do the rest. And it is fast, not only because it reduces bandwidth use (intra-chip communication is fast), but it also releases CPU cycles for other uses, which inevitably will have a positive impact on performance.

So, in short, if developers ditch their own matrix libraries and use the ones provided by the graphics API, they're already making use of hardware T&L. And, yes, unfortunately, hardware T&L only has things to do with frame rates - there's no other advantage than frame rate that hardware T&L provides.

Just remember - ALL effects are archeavable with software. The more you offload from the CPU to the GPU, the more CPU cycles you can save for physics, AI, and graphic effects that the hardware does not do yet. So, even hardware that "only" increases framerate sounds good enough for me.

¿Estás seguro que esas funciones de transformación no aprovechan la GPU mediante T&L en Direct3d, Senio Wapo? Porque en Opengl lo hacen.

Pero bueno, el mero hecho de perder cosillas que puedan tener implementadas explotando SSE2, 3DNow y tal... creo que mejor que las wrapee en vez de hacerlas yo mismo.

[senior wapo]

Esas funciones no lo usan (TnL). Tu a lo que te refieres es a la tuberia fija interna de OpenGL o Direct3D.

Direct3D lo aprovecha desde la versión 7  si usas un device con TnL (puedes enumerar el mismo device con y sin TnL). Pero para transformaciones de la tuberia, no para las funciones de D3DX.

En OpenGL las funciones de manipulación de matrices forman parte de la propia API gráfica desde siempre y usarán lo que al autor del driver le venga en gana. En la práctica se asume que es por hard cuando se pueda, pero no lo requiere la especificación y no cuentes con ello.

[Loover]

Gracias, ahora lo entiendo.

Y volviendo al tema, ¿crees que es mejor hacerlas yo mismo o wrapearlas? ¿Crees que dichas funciones utilizan hacks o ensamblador para ir más rápidas y/o historias de SSE2, 3DNow y que se notaría mucho la diferencia con las mías? En caso de crear una matriz de traslación o rotación, es trivial, pues es colocar unos valores, pero en casos de transformaciones y/o multiplicaciones quizás si que se notaría...

[Pogacha]

Depende de cuantas multiplicaciones de matrices hagas puede resultar en un cuello de botella o no, en Iconical Match si que lo es, hace cerca de 1 millon de multiplicaciones por frame, no obstante las operaciones estan wrappeadas y requiere de un 1Ghz para correr adecuadamente (en las situaciones pico obviamente). El tema de wrappearlas es para compatibilidad multiplataforma, supongo será tu caso tambien.

Tendras que calcular cuantas operaciones usaras ... y ver cuanto consume.

Otra cosas que puedes hacer es hacer uso de templates para optimizar la matematica, pero es un paso extra de trabajo que no se si vale la pena.

http://www.flipcode.com/archives/Faster_Vector_Math_Using_Templates.shtml

Habia otro enlace mucho mas desarrollado pero no pude dar con el.