IEGD 945GSE WinCE6.0, No Useful Graphics HW Acceleration?

[idata]

Hi All,

I wonder if anyone out there can help :). I'm having serious trouble getting any useful graphics acceleration out of IEGD on WinCE6.0.

I have a system with Atom+945GSE running WinCE6.0(R3). AlphaBlend, DirectDraw AlphaBlt and Direct3d Mobile, and OpenGL APIs are all present.

* GDI Returns SHADEBLENDCAPS 0x17 => which implies hardware acceleration for GDI AlphaBlend(). Yet the AlphaBlend() and TransparentBlt() blits are so slow as to indicate its software only.

* DirectDraw indicates no hardware acceleration for alpha blits.

* Direct3d Mobile DeviceCaps indicates no D3DMDEVCAPS_HWRASTERIZATION.

* OpenGL crashes with any attempt to call eglCreateContext().

Apart from OpenGL (which I'm guessing isnt supported on GMA950? only GMA500? - on WinCE), all APIs work but they appear to be software only.

In the Intel® Embedded Graphics Driver Feature Matrix, DirectDraw and Direct 3d Mobile are listed. Given it makes no sense to list them if only a software path is supported, I'm wondering what has gone awry with my setup.

The 945 under WinXP with the desktop driver supports accelerated GDI AlphaBlend(), Direct3D and OpenGL. Under WinXP, the 3d APIs work well with zone rendering support.

Any ideas? The way things are working now apart from basic GDI BitBlt() acceleration the 945 is basically not doing anything useful under WinCE.

Really frustrated here! :)

Thanks,

Samuel.

[Kirk_B_Intel]

* GDI Returns SHADEBLENDCAPS 0x17 => which implies hardware acceleration for GDI AlphaBlend(). Yet the AlphaBlend() and TransparentBlt() blits are so slow as to indicate its software only.

* DirectDraw indicates no hardware acceleration for alpha blits.

These two are directly related to a change MS made in WCE 6.0.

1. For Wince 5, the display driver layer had 2 sets of interfaces for GDI and DDRAW. IEGD supported both. But only allowed more advanced blitting features like pixel conversion and alpha blending on DDRAW only.

2. For WinCE 6, The OS middleware re-routes all DDRAW thru GDI (so the display driver layer has no more DDRAW interfaces being called). That means the driver is no unable to do any advanced blitting features on WinCE 6 (even if the application was calling DDRAW API's – which internally are now routed to GDI).

* Direct3d Mobile DeviceCaps indicates no D3DMDEVCAPS_HWRASTERIZATION.

This should be accelerated. Is there test or program we can use to troubleshoot this?

* OpenGL crashes with any attempt to call eglCreateContext().

It is true that on 945GSE we do not support OpenGL (that is only supported on US15W). However, you should not be getting a crash. Again, do you have a test, or application we can use to trobleshoot this issue?

Is there anyway you can get an Intel Premier Support account (through your Intel field rep)? This would allow us to work with you to understand and resolve your issues.

[idata]

Kirk, Thanks for the quick and detailed reply.

I can understand the unification of DDRAW+GDI drivers as DDRAW doesnt offer much extra (apart from overlays).

So should GDI AlphaBlend() be hardware accelerated? (I know it is under WinXP).

For Direct3d Mobile, my test is:

IDirect3DMobile* d3dm = Direct3DMobileCreate(D3DM_SDK_VERSION);

D3DMCAPS d3dmCaps;

HRESULT hr =

d3dm->GetDeviceCaps(D3DMADAPTER_DEFAULT,D3DMDEVTYPE_DEFAULT, &d3dmCaps);

if ((d3dmCaps.DevCaps & D3DMDEVCAPS_HWRASTERIZATION) == 0)

error("Direct3DMobile Device does NOT support hardware rasterization.");

Also, I can see by visual inspection its running very slow, so its not hardware accelerated.

For OpenGL ES, see the attached code snippet (ignore the hand dll loading, it happens both with static/dynamic dll linking). Looking at the vendor code it says "Win32/Poulsbo", also whilst debugging I saw "Tungsten" mentioned in the text segment of one of the dll's - which doesnt quite add up. Either its the videologic closed source driver somewhere in there or it's tungstens... or I'm confused. Either way it lets me do the initial egl calls, and always crashes on eglCreateContext() (I've tried a few egl setup routines from here and there, always the same result).

In terms of intel support, I thought I would try here as my WinCE image build ( BSP and NK.BIN, etc) is done out of taiwan - so I don't have a direct line to intel support.

I'm keen to stick with WinCE but I need GDI AlphaBlend() and/or a hardware accelerated 3d API. WinCE+ATOM+945GSE is such a nice tight little package, it would be great to get the hardware zinging... Now if only the driver had the pop of the WinXP Direct3D 945 driver. When zone rendering is on song that cranks!

Cheers

Samuel.

[Kirk_B_Intel]

Should AlphaBlend be accelerated has quite a different answer than should it be. In an ideal world everything possible would be accelerated. When MS shifted away from a seperate DDRAW, they effective bypassed our acceleration. At this point, it would a feature request to put the capability into the GDI code and we need the platform teams to drive that sort of need. If you have good influence over your Intel representative, this would be a great one to request for your platform segment.

As for OGL, I have a hint of what might be going on, but it is not clear if the OGL fails because WCE assumes there is automatic OGL support if a video driver is loaded, or if somehow the fact that we do have it for US15W (a sweeter package than the GSE IMHO) and that is somehow incorrectly being indicated by the driver somehow. I am going to have e tough time convincing someone to look at something that is not supposed to work anyway- ("It hurts when I do this" "Well, don't do this." :smileytongue:) so any help you can provide will help to get this attention.

[idata]

Thanks.

I guess given OGL isnt going to give any joy on WinCE+GSE, there isnt much point looking at it. If there is any take home on the OGL front - I'd say that the IEGD feature matrix and IEGD 10.2 User Guide didnt really seep into the brain of a simpleton like me. I guess its Appendix D. I couldnt quite parse when "Windows" meant "All windows" or when it meant WinXP or WinCE. In hindsight I guess "OpenGL for Windows is supported only on the US15W chipset." should be pretty clear to anyone (but me :)). I wanted to believe OGL ES was there I guess...

GDI AlphaBlend :(. Oh well it is only 2d. Let's blame MS for this one. Anyway they never upgraded GDI functions with a good spread of alpha support, rotations, zooms etc... oh wait its 2010 and its time for Direct2D... 1.5 decades too late... :)

Yes US15W would be nice - only downside is probably slightly less memory bandwidth - I'm dreaming of 1280x1024x32bpp@60Hz for my application. MBX/SGX are nice cores as well which I'm all too familiar with... But alas I cant change the chipset at this stage.

So I guess I have to pin all my hopes on our little friend Direct 3D Mobile... Current software only :(, I will have to dig deeper. If you could double check that it is really hardware accelerated on GSE it would be much appreciated... :)

Now 945GSE or GMA950 is generation 3.5? So the driver is essentially hidden in iegd3dg3.dll? (rather than iegd3dg4.dll). My concern is that in the 10.2 IEGD driver image d3dg3.dll is only 391KB, where as d3dg4.dll is 2337KB.

Oh well maybe I can see Linux in my future... :(

Cheers

Samuel

[Kirk_B_Intel]

US15W can do 1280 x 1024 on the internal LVDS, and with an appropriate sDVO based tranmitter, can get up to 1920x1080 (1080p on HDMI) and do high quality video to boot. Done it and have been amazed at the quaility and the capability at the lower power.

When we say Windows we do mean XP/XPE or Vista in XPDM mode, and Windows CE is typically WCE. Sorry that is confusing.

I do need to dig in a little deeper on 945GSE and Windows Moble3D to see what we do accelerate. Much of the blending and compositing has been focused on the US15w and follow ons for that style of graphics engine so I am not sure how far back that goes.

[idata]

Hi Kirk,

Did you manage to get any more insight into the status of WinCE 945GSE driver support?

I've played around a little with Direct3D Mobile (both in managed .net compact and vanilla C/C++). Its definitely reporting software rendering, but performance seems to be somewhere between software and hardware - rather too slow :(. But in terms of stability the whole of Direct3D Mobile feels unusable. The managed API quickly loses memory and fails to recover it even after an application quit and restart. And the raw unmanaged API also degrades quickly and eventually I'm unable to create the device. This is all on a simple application that does rotated/alpha textured quads. My feeling from poking around the web is that generally Direct3D Mobile is considered a little bit raw (across all WinCE/Mobile devices that is - really raw patchy support).

Is there a complete list of what API/functionality is supported with hardware acceleration and what isn't? I think most embedded dev's would find that really useful - it would really assist the OS + Chipset selection process.

Right now i'm crying out for accelerated GDI alpha blits and/or OpenGL ES. I know the chip can do it. Is there any low level interface I can access to touch the raw accelerated calls/features?

My application target is 60fps at 1280x1024@32bpp with 5+ layers of overdraw (with alpha compositing and rotations and zooms). I know the raw transistors are there to do it, and I know its possible under WinXP on the same hardware. I just can't seem to reach thru the driver stack into the hardware and light up those transistors...

Cheers & Thanks

Samuel.

[Kirk_B_Intel]

It took a while but I did get a definitive answer from development:

-The only h/w acceleration we are missing in WCE 6.0 is Alpha Blending and pixel conversion. All other GDI rendering functions are accelerated nearly the same as the DDRAW path on WCE 5.0.

-GDI Alpha blit using h/w acceleration is a new feature request. You need to work through your Intel Field Representative to influence our product planning and roadmap. If you have a Premier Support Account, you can put in a Quad item requesting this feature also.

-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. Maybe it is your use model that exposes a problem that the CETK does not show? IF you could provide a way for us to see the "instability" and/or memory leaks, then we could enter an issue in our tracking system and potentially get it fixed in a future release. Do you have a sample app, or test routine that we could use to reproduce your issue? We do not have any other DMD3 customers complaining at this time so there is nothing "big" open against D3Dm operation at this time.

- OGL ES is only supported on US15W (Menlow). It is possible to get OGL ES on other chipsets and on other OS other than Linux but this is a BIG new feature and would require a platform segment to make it top priority to get it on the roadmap. Please work with your Intel Field Rep to influence this requirement.

THX, Kirk