We have an embedded board with an Atom N2600 (dual core but only one core enabled at the moment) and NM10 chipset. It appears that the reference platform distributed by our vendor used a version of the IEMGD driver (v.1.15). However, we made some changes to the BSP (WinCE 7) and mistakenly built without including the driver. The result was that graphics performance was terrible, and our main application (an industrial HMI) was chewing up 90+% of the CPU just from drawing the main screen.

We found and included the 1.12 driver, which has helped somewhat, but the performance stills seems slow, and worse that previous BSP's on Intel chips. We also tried the 1.15 driver, but this hasn't helped improve performance. (Running the CETK graphics tests with the driver vs. without does show some improvement.) Even doing a directory listing in \Windows takes far too long, and you can watch the files scroll one by one. Our application is bitmap-intense, and perhaps this also adds to the overhead. When flipping between screens we can see the display elements on each screen draw one at a time. There's no way a 1.6GHz system should be taking this long to do any sort of drawing with proper hardware support.

Is there a quick way to see what kind of hardware support the driver believes its getting from the system? We're using the default .reg settings, which don't appear to be much different between 1.12 and 1.15. I realize that this post might be a little light on details, but any help to nudge us in the right direction in terms of troubleshooting steps would be much appreciated.

Tools for checking hardware acceleration might vary depending on the code that you are using, one rough way to test if your platform supports HW acceleration is to install comercial tools that use HW accel and check if the acceleration can be enabled. For example VLC, Firefox, PowerDVD can enable HW accel.

There is also the DXDiag tool that might indicate if DirectDraw Acceleration and Direct3D Acceleration is enabled.

The DirectX have some sample applications that might be useful for you ddex1.exe ddex2.exe, tec.

What I can suggest for your application is to try with an Intel® Tunnel Creek platform, or with a fresh vendor supplied unit that you could start a new test.

Using the document User Guide: Intel® EMGD v1.15 and not modifying the BSP and following the instructions and using the recommended versions of MicroSoft, and check if you still have the performance problem.