Interfaz Para Idirect3ddevice - Zupervaca

[ethernet]

     Interfaz para IDirect3DDevice

zupervaca nos proporciona un código que tiene que ver con la optimización de las llamadas a los métodos que nos ofrece Directx9. Qué mejor que las palabras del autor para explicar en qué consiste la clase:

Clase para no realizar tantas llamadas a los objetos COM de DirectX, al guardar en memoria de la aplicación el estado del device antes de realizar una llamada al objeto COM comprueba si le indicas un valor diferente al establecido ahorrándote la llamada al objeto COM y todos los cálculos que realicen las DirectX.

Como complemento a este COTW estaría bien que se discutiera la necesidad o no de tener un sistema de este tipo para las sucesivas llamadas a DX a la luz de un pequeño benchmark, a ver si alguien se anima a hacerlo.

El código lo podeis encontrar en la web de zupervaca en la siguiente URL:

http://www.davidib.com/codigofuente/cpp/dibDevice.rar

Código enviado por zupervaca



[/list]

[BeRSeRKeR]

 ProD y yo también teníamos una caché de estados implementada en el motor que desarrollamos hace unos años.

Le he estado echando un vistazo por encima y veo que para incializar los estados, utilizas los métodos Get* del device de Direct3D. Si no recuerdo mal, ese tipo de métodos (GetTransform, GetRenderState, etc) no tienen por qué devolverte un valor válido en dispositivos creados con el flag D3DCREATE_PUREDEVICE. Nosotros lo que hacíamos era inicializar los valores por defecto en base a los valores que indica la documentación del SDK y de esa forma nos curábamos en salud. :)

Pero vamos, que si hasta ahora te ha ido bien utilizando un "pure device" pues nada.

Nosotros también tenemos que implementar una caché de estados en el motor C#.

En cuanto a la conveniencia o no de una caché de estados pues creo que es bastante útil y mejora el rendimiento de la aplicación.

Aquí pongo un fragmento de la documentación del SDK:

When a device is created (IDirect3D9::CreateDevice), the type of device is specified with D3DDEVTYPE. A pure device (created with D3DCREATE_PUREDEVICE) filters a smaller subset of possible state change commands. It is very fast because is essentially streams the pipeline commands striaght to the hardware. A pure device does not do any validation of parameters, and does little or no redundant state filtering. In constrast, a non-pure device (created without D3DCREATE_PUREDEVICE) will check each state change for redundancy, and discard them. This reduces the amount of work that the device will need to perform.

y aquí pongo un comentario en el código del ejemplo "StateManager" que viene con el SDK:

A PURE device does not attempt to filter duplicate state changes (with some exceptions) from the driver.  Such duplicate state changes can be expensive on the CPU.  To create the proper state manager, the application determines whether or not it is executing on a PURE device.

Si ejecutas dicho ejemplo, verás que si el dispositivo ha sido creado como "pure device", te informa de los cambios de estado redundantes que se han evitado, pero si no lo creas como "pure device", no te informa de ello. Mirando una frase del fragmento que he puesto antes:

A pure device does not do any validation of parameters, and does little or no redundant state filtering. In constrast, a non-pure device (created without D3DCREATE_PUREDEVICE) will check each state change for redundancy, and discard them. This reduces the amount of work that the device will need to perform.

me lleva a pensar que si el dispositivo no fue creado como "pure device", él mismo se encarga de evitar los cambios redundantes de estado por lo que volver a realizar dicha comprobación sería redundante. De todas formas esto es algo que no he comprobado por mí mismo.

Saludos.

[zupervaca]

 otra cosa que puede llegar a asustar a muchos es que si ejecutas en modo de debug de direct3d veras varios mensajes de alerta de primera excepcion al intentar obtener estados que no existen, si quereis puedo cambiar la clase haciendo que la funcion de inicializar ponga los estados por defecto que vienen en directx en vez de obtenerlos, pero vamos si alguien lo hace y pone ese codigo aqui pos mejor que asi no lo hago yo  :lol:

pd: ese codigo es inicializar todos los valores de la clase y el device que no son pocos  (uoh)

saludos

[O2]

 Berserker, ese código del statemanager donde dices que viene? Es para echar un ojo a ver como hacen cuando el device no está definido como PUREDEVICE.

Quizá no lo encuentro por que tengo el SDK 9.0, no 9.0c...

Saludos

[BeRSeRKeR]

 En realidad el codigo del state manager no viene, es un helper de Direct3D. Tienes un ejemplo en el SDK.

Saludos.

[zupervaca]

 he probado lo del puredevice y si no se crea de esta manera sigue siendo lento, es decir, es mejor evitar las llamadas directas a directx sin comprobar si realmente se va o no a cambiar algo, lo he probado desde c++ unmanaged con lo que desde un lenguaje managed la cosa puede cambiar nunca se sabe

saludos