OpenGL ES vs. Direct3DMobile

I don't think the Ipaq 1950 has any hardware support for 3D, you're probably thinking of the Axim 50v, which has the PowerVR chip. The PXA270 doesn't have any specific 3D support, so both D3DM and GL ES should be running completely in software.

Having said that, I don't know why one is slower than the other. I do remember that Intel provides an XScale optimized GL ES library mostly for the transformation part of the pipeline, so if your GL ES implementation uses the Intel libs maybe that's the difference.

I also think that my iPAQ has no hardware acceleration.
And I have a 300MHz Samsung SC32442 processor, not an Intel XScale, so I cannot use the XScale optimized libraries. I use the normal "vincent" library from sourceforge.net.

Are you using C# for the D3D app, and native C++ for the OpenGL-ES app? Unless a lot has changed in the PocketPC world, I wouldn't count on doing any realtime 3d with C# on that platform (without hardware acceleration, at least).

I've performed similar tests using Hybrid and Vincent OpenGL ES drivers on Intel XScale platforms and D3DM outperformed both of them.

If I had to guess I'd say that this isn't a problem with D3DM per-se, but rather the particular implementation of the D3DM driver on your iPaq. It has a Samsung CPU, right? If so, it wouldn't use the fast Intel XScale driver that I tested.

BTW, D3DM wasn't available on WM2003 devices, so I have no idea how you were testing it.

@ AVigesaa:

Yes that´s right, I´m using c++ for GL|ES and c# for D3DM. I cannot imagine that writing managed code can causes a heavy performance reduction on a so simple example programm, but I should try the unmanaged d3dm samples to check out the perfomance with c++.

@ don:

Yes I have Samsung processor in my iPAQ but I thought these are 100 % compatible to XScales?!
Maybe it doesn´t uses the optimized implementation.
I´m running Mobile 5 and not 2003. I have no answer how Anonymous Poster tested d3dm on a 2003 device.

Do you have any good resources for GL|ES and D3DM? I found www.typhoonlabs.com and http://www.zeuscmd.com/ very usefull.

Thx for your replies.

Yes, I would say that using C# is responbsible for a lot of the speed difference between the two. I'd like to see your results using unmanaged c++/D3DM.

yoursort:

You can determine which D3DM driver you have by calling IDirect3DMobile::GetAdapterIdentifier.

The Intel XScale has some additional instructions over the common ARM instruction set. Their D3DM driver uses these and as such won't run on non-Intel CPUs. Besides, you can't really blame Intel for their driver failing to run on a competitor's CPU. :)

If I can find a 1950/1955 around here I'll try some of my benchmarks and post results to this thread. Single triangle type of benchmarks don't mean much though unless your game only renders a single triangle.

AVigesaa:

The apparent performance difference between using C++ and C# would vary depending on what else is going on in the system. For example, if you're drawing very little it will appear like the C# overhead would be quite large, however once the majority of the time per-frame is spent elsewhere (i.e. in a software rasterizer filling pixels) I would imagine that the difference in the API interface will be a minimal portion of the time it takes to execute your render loop.
I do agree with you though that if you're trying to compare OpenGL ES to D3DM that you should use the same native interface with the two APIs.

Just a follow-up after I got my hands on an HP rx1955 iPaq:

Well there's no point in me running benchmarks like I had promised. This device is using the D3DM Reference driver as it's D3DM driver. I can't begin to tell you how bad of move this is. This driver should never end up on production devices as it's only used for driver verification and software development testing purposes. It's similar to the D3D Reference Rasterizer supplied with the DX SDK, in that it's designed to generate proper reference images - not for performance (nor is it supposed to be redistributed).

How HP was allowed to ship this as their D3DM driver is beyond my understanding because as far as I know, Microsoft forbids this sort of thing. Perhaps HP will offer an OS update in the future for this device that will include a legit D3DM driver.

First thx for all your replies!

@avigessa:
There are no noticeable speed differences for the little example programms between c++ and c#.

@don:
A while ago I checked my D3DM driver and didn´t thought about the reference driver because I thought every device with no hardware acceleration uses the reference driver.
But of course every vendor can write an optimized specific device driver. I hope there will be an OS update soon.

No, I do not blame Intel for an driver failing to run on a competitor's CPU. :)
But I thought that I´ve read something like: Samsung-CPUs are XScale-compatibe. But maybe that´s wrong.

@Anonymous Poster:
Until now I only used the vincent implementation but I will give the rasteroid implementation a try.

By now I´ve got a bit time until I have to decide the topic of my bachelor thesis. I only wanted to play a bit with the different APIs to see which fits best for me (especially for my device because I´ve got no money for another one ;)

[Edited by - yoursort on February 3, 2006 7:36:38 AM]