Direct3D Mobile on Atom + 945GSE

[STask]

Hello,

I am currently investigating hardware accelerated rendering options for our company's products on an Atom N270 with 945GSE chipset. We are running on Windows CE 6.0 and are using the Intel drivers found on the IEGD download page here https://www-ssl.intel.com/p/s/en_US/embedded/hwsw/software/iegd?iid=1194# download https://www-ssl.intel.com/p/s/en_US/embedded/hwsw/software/iegd?iid=1194# download

Hardware acceleration works but not very well. I have identified it as a problem with the driver after the test applications I have used work with the reference renderer.

Basically nothing is rendered when multiple calls to DrawPrimitive() are made. DrawPrimitive() and DrawIndexedPrimitive() have the same results. No errors are being returned by D3DM calls.

The variable g_bTryAndRenderTwo in the attached project turns drawing of multiple cylinders on and off. The g_bUseRef variable toggles the reference renderer. The attached screen shots show when one draw call is made (cylinder is rendered) and when two are made (cylinder is not rendered) unless using the reference renderer. The reference render is included in the zip file for convenience.

Interestingly if you comment out the second call to SetupMatrices() right before the second call to DrawPrimitive(), the cylinder is rendered but the second call seems to be ignored. This might sound like it is a problem with SetupMatrices() but if you use the following code in Render() and switch the two DrawPrimitive() calls you can see one half of the cylinder rendered. Enabling both calls results in only the first DrawPrimitive() working.

//g_pd3dmDevice->DrawPrimitive( D3DMPT_TRIANGLESTRIP, 0, (2*50-2) /2 );

//if( g_bTryAndRenderTwo )

//{

//SetupMatrices(-1.0f);

g_pd3dmDevice->DrawPrimitive( D3DMPT_TRIANGLESTRIP, 50, 48 );

//}

I have tried this on multiple machines (same specifications) with the same results.

This has been bothering me for over a week now and it seems I keep going around in circles.

Are there any known issues with the Intel drivers on Windows CE 6.0 that might explain the results I am getting? If there are, is there a work-around I may be able to use?

I appreciate the time you've taken to look over this already.

Cheers,

Sean

[Kirk_B_Intel]

Sorry for the delay in getting back to you on this.

One issue is that the 945GSE support is nearing end of life. You might want to consider a more "up to date" chipset as support is more likely to continue on later chipsets.

Another is that D3D Mobile is not the ideal 3D interface in WEC. Have you refered to the User's Guide for the list of supported functions? You also may want to work with your Intel Field Representative and get the Technical Product Spec (TPS) for your particular release of IEGD to see what is and what is NOT supported.

Hope this helps.

[STask]

Hi Kirk,

Thank you for your response. Unfortunately I am not in a position to change the platform we are using - as much as I would like to. Our company is doing some work for another who already have this platform deployed. I don't know the full details but I expect they are planning to re-flash the 1000's of machines already in the field to receive our software. Because we are a kind of "extra-party" we don't have direct access to an Intel field rep.

The user's guide in the IEGD does not reference any specific functions in D3D Mobile, it actually suggests that it is supported. The User's guide says to include the driver "iegd3dg3.dll" and "No other IEGD registry configuration is necessary for this feature to work.". I found a thread with a post by you Kirk, where you said "We use the Microsoft CETK to test D3Dm and except for a few minor anomalies, we do have a 96\% test pass rate meaning the code should be OK according to MS."

I have spent over two weeks searching for hardware acceleration solutions on this platform. It has become quite frustrating because the documentation I come across indicates that D3D Mobile is supported on this platform. It is most frustrating to see your application running perfectly on a different OS on the same hardware, showing that the hardware is more than capable and that there seems to be a missing software layer.

The salt in the wound here is seeing that there is support for OpenGL on this chipset for Linux. Is it not just a matter of changing the way the communication is done with the hardware to implement support for non-Linux platforms? If Intel aren't prepared to do the work, is there a chance of developers getting their hands on the required source code?

Regards,

Sean