Developing D3DM Primary Hardware Device Driver

Can anyone help me with these issues?
We are trying to develop D3DM hardware-based device driver and we are
somewhat lost as to where to start since this is the first time ever
developing for D3DM device driver.

OpenGL ES driver/SDK development is done and is up and running fine.
We first tried to base our effort on the given D3DM null driver from
Platform Builder for Windows CE 5.0 catalog.
That null driver looked like a good place to start until we found that all
the D3DM applications need to call;

LoadLibrary(TEXT("d3dm_nulldrv.dll"))

and register as a software device. Now this method would work fine if we
stuff all our hardware-accelerated implementations to the d3dm_nulldrv.dll
and have the application developer go through the above stages before
creating a D3DM device (CreateDevice).

The problem with this method however is that WinCE documentation states that
this method is usually for software renderer drivers and it might cause
confusion among D3DM developers.
The proper way would be not going through those
LoadLibrary/RegisterSoftwareDevice process and go directly call CreateDevice
with default adapter and default device parameters, as stated in the WinCE
documentation as a proper hardware D3DM device driver creation.

So, in order for us to start developing the clean D3DM hardware-based device
driver in place of the null driver, where would we have to start? Would this
involve coming up with our own WinCE display driver implementation? Or can
we implement D3DM only and still use the default display device driver?

Any help on this issues would be greatly appreciated. Thanks.....

Don
Sat Jul 22 12:02:59 CDT 2006

If you register your driver as the D3DM system driver on the device,
applications won't have to go through the
LoadLibrary/GetProcAddress/RegisterSoftwareDevice routine. Since you're
developing a driver for a piece of 3D hardware, you'll most likely use a
remote-hooked driver (your driver DLL is loaded directly into GWES.exe).
See the following webpage describing how to set your driver as the
remote-hooked driver via the Registry:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceddk5/html/wce50condirect3dmobiledriverregistrysettings.asp

You can implement a D3DM-only driver, separate from the display or DDraw
driver on the device, however there might be some issues with sharing the
primary surface if all of these technologies aren't aware of each other at
the driver-level.




"Mike Khim" <khimmy@vdigm.com> wrote in message
news:%230K9XhJrGHA.4016@TK2MSFTNGP05.phx.gbl...
> Can anyone help me with these issues?
> We are trying to develop D3DM hardware-based device driver and we are
> somewhat lost as to where to start since this is the first time ever
> developing for D3DM device driver.
>
> OpenGL ES driver/SDK development is done and is up and running fine.
> We first tried to base our effort on the given D3DM null driver from
> Platform Builder for Windows CE 5.0 catalog.
> That null driver looked like a good place to start until we found that all
> the D3DM applications need to call;
>
> LoadLibrary(TEXT("d3dm_nulldrv.dll"))
>
> and register as a software device. Now this method would work fine if we
> stuff all our hardware-accelerated implementations to the d3dm_nulldrv.dll
> and have the application developer go through the above stages before
> creating a D3DM device (CreateDevice).
>
> The problem with this method however is that WinCE documentation states
> that this method is usually for software renderer drivers and it might
> cause confusion among D3DM developers.
> The proper way would be not going through those
> LoadLibrary/RegisterSoftwareDevice process and go directly call
> CreateDevice with default adapter and default device parameters, as stated
> in the WinCE documentation as a proper hardware D3DM device driver
> creation.
>
> So, in order for us to start developing the clean D3DM hardware-based
> device driver in place of the null driver, where would we have to start?
> Would this involve coming up with our own WinCE display driver
> implementation? Or can we implement D3DM only and still use the default
> display device driver?
>
> Any help on this issues would be greatly appreciated. Thanks.....
>

Mike
Sun Jul 23 20:09:30 CDT 2006

"Register" meaning, setting my D3DM driver as a remote hooked one in the
registry as described in MSDN?

Another things is what exactly is the purpose of that D3DM null driver?
Can I still modify it and transform it into hardware (system) driver by
remote-hooking?

"Don Crouch" <doncr@nwlink.com> wrote in message
news:12c4mhhbs8fs9b4@corp.supernews.com...
> If you register your driver as the D3DM system driver on the device,
> applications won't have to go through the
> LoadLibrary/GetProcAddress/RegisterSoftwareDevice routine. Since you're
> developing a driver for a piece of 3D hardware, you'll most likely use a
> remote-hooked driver (your driver DLL is loaded directly into GWES.exe).
> See the following webpage describing how to set your driver as the
> remote-hooked driver via the Registry:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceddk5/html/wce50condirect3dmobiledriverregistrysettings.asp
>
> You can implement a D3DM-only driver, separate from the display or DDraw
> driver on the device, however there might be some issues with sharing the
> primary surface if all of these technologies aren't aware of each other at
> the driver-level.
>
>
>
>
> "Mike Khim" <khimmy@vdigm.com> wrote in message
> news:%230K9XhJrGHA.4016@TK2MSFTNGP05.phx.gbl...
>> Can anyone help me with these issues?
>> We are trying to develop D3DM hardware-based device driver and we are
>> somewhat lost as to where to start since this is the first time ever
>> developing for D3DM device driver.
>>
>> OpenGL ES driver/SDK development is done and is up and running fine.
>> We first tried to base our effort on the given D3DM null driver from
>> Platform Builder for Windows CE 5.0 catalog.
>> That null driver looked like a good place to start until we found that
>> all the D3DM applications need to call;
>>
>> LoadLibrary(TEXT("d3dm_nulldrv.dll"))
>>
>> and register as a software device. Now this method would work fine if we
>> stuff all our hardware-accelerated implementations to the
>> d3dm_nulldrv.dll and have the application developer go through the above
>> stages before creating a D3DM device (CreateDevice).
>>
>> The problem with this method however is that WinCE documentation states
>> that this method is usually for software renderer drivers and it might
>> cause confusion among D3DM developers.
>> The proper way would be not going through those
>> LoadLibrary/RegisterSoftwareDevice process and go directly call
>> CreateDevice with default adapter and default device parameters, as
>> stated in the WinCE documentation as a proper hardware D3DM device driver
>> creation.
>>
>> So, in order for us to start developing the clean D3DM hardware-based
>> device driver in place of the null driver, where would we have to start?
>> Would this involve coming up with our own WinCE display driver
>> implementation? Or can we implement D3DM only and still use the default
>> display device driver?
>>
>> Any help on this issues would be greatly appreciated. Thanks.....
>>
>
>

Don
Tue Jul 25 12:16:30 CDT 2006

Yes, "register" means that you add the name of your driver DLL to the
Registry so that it will become the D3DM system driver. When the OS boots
and initializes GWES.exe, it will look in the Registry for the name of a
remote-hooked D3DM driver DLL, and if found, load the driver DLL.

The D3DM Null driver is a sample framework that driver writers are free to
use to develop their drivers. In its current state, it can run as a
remote-hooked driver or as a local-hooked driver. This driver sample
demonstrates how to parse the command buffer and create/destroy driver
contexts, surfaces, and other resources.


"Mike Khim" <khimmy@vdigm.com> wrote in message
news:OY0R$1rrGHA.4324@TK2MSFTNGP03.phx.gbl...
> "Register" meaning, setting my D3DM driver as a remote hooked one in the
> registry as described in MSDN?
>
> Another things is what exactly is the purpose of that D3DM null driver?
> Can I still modify it and transform it into hardware (system) driver by
> remote-hooking?
>

Mike
Tue Jul 25 19:46:14 CDT 2006

Thanks a lot.... Everything seems a lot clearer now.... Thanks again... ;0

"Don Crouch" <doncr@nwlink.com> wrote in message
news:12cckf4edp05t55@corp.supernews.com...
> Yes, "register" means that you add the name of your driver DLL to the
> Registry so that it will become the D3DM system driver. When the OS boots
> and initializes GWES.exe, it will look in the Registry for the name of a
> remote-hooked D3DM driver DLL, and if found, load the driver DLL.
>
> The D3DM Null driver is a sample framework that driver writers are free to
> use to develop their drivers. In its current state, it can run as a
> remote-hooked driver or as a local-hooked driver. This driver sample
> demonstrates how to parse the command buffer and create/destroy driver
> contexts, surfaces, and other resources.
>
>
> "Mike Khim" <khimmy@vdigm.com> wrote in message
> news:OY0R$1rrGHA.4324@TK2MSFTNGP03.phx.gbl...
>> "Register" meaning, setting my D3DM driver as a remote hooked one in the
>> registry as described in MSDN?
>>
>> Another things is what exactly is the purpose of that D3DM null driver?
>> Can I still modify it and transform it into hardware (system) driver by
>> remote-hooking?
>>
>
>