Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


OpenGL ES vs. Direct3DMobile


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 yoursort   Members   -  Reputation: 122

Like
0Likes
Like

Posted 12 January 2006 - 05:15 AM

Hi, for my bachelor thesis I want to develop a small 3D engine for the PocketPC (2003 and WM5). I think there are only 2 APIs for this: OpenGL ES and D3DM. I´ve been playing around with those two 3D APIs for a few days. I´ve tried some tutorials with basic stuff, e.g. initialization, render a textured cube and so on. The GLES samples are fine, they are running in an acceptable framerate on my iPAQ 1950 (300MHz). But the D3DM samples are very slow! A one triangle sample runs under 10 fps (the samples are from msdn). Before I tried the samples D3DM was my favourite because I can write in C# (I like the class hierarchy of the CompactFramework) and I wrote some DirectX stuff before. But now GLES seems to be the better one. What do you think? Do you have any experience with these APIs? Can I use GLES under C# (are there wrapper classes for it?) Why is D3DM so slow? Thx! [Edited by - yoursort on January 13, 2006 4:32:51 AM]

Sponsor:

#2 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 12 January 2006 - 03:42 PM

The iPAQ series are based on the 'Bulverde' processor (intel PXA270 class), which features a hardware 3D engine made by Imagination Technology (aka PowerVR MBX-S). I suspect the OpenGL ES driver is using the 3D hardware, where D3DM has been left in its original software version.

#3 outRider   Members   -  Reputation: 852

Like
0Likes
Like

Posted 12 January 2006 - 05:02 PM

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.

#4 yoursort   Members   -  Reputation: 122

Like
0Likes
Like

Posted 12 January 2006 - 10:39 PM

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.

#5 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 15 January 2006 - 03:50 PM

I wrote a few sample programs in both OGLES and D3DM which displayed from one to 16 triangles, with optional toggles for lighting, texturing and transparency. On my iMate Jam (O2 XDA to most of you) the performance was around 7-8 times better in OGLES with a single triangle and no options. With all options and 16 triangles OGLES was fairly slow but closer to 20 times faster than D3DM. This was running Windows Mobile 2003- apparently Windows Mobile 5.0 based devices are supposed to have much better D3DM support so the performance hit might not be as bad but it's still pretty clear in my mind that OGLES is the way to go.

#6 AVigesaa   Members   -  Reputation: 122

Like
0Likes
Like

Posted 19 January 2006 - 01:14 AM

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).

#7 don   Members   -  Reputation: 430

Like
0Likes
Like

Posted 19 January 2006 - 10:56 AM

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.



#8 yoursort   Members   -  Reputation: 122

Like
0Likes
Like

Posted 20 January 2006 - 03:12 AM

@ 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.

#9 AVigesaa   Members   -  Reputation: 122

Like
0Likes
Like

Posted 20 January 2006 - 03:59 AM

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.

#10 don   Members   -  Reputation: 430

Like
0Likes
Like

Posted 20 January 2006 - 07:50 AM

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.



#11 don   Members   -  Reputation: 430

Like
0Likes
Like

Posted 31 January 2006 - 12:19 PM

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.



#12 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 31 January 2006 - 12:36 PM

Yes, Dell Axim x50v and x51v have an integrated Intel 2700g card with a Power MBX-lite 3d processor (without vertex processing: is only a rasterizer). You can achieve a quite interesting frame rate in high resolution (480x640) (20-30 fps with textured, filtered, 10.000+ tris scenes). The drawback is that you have to use a sick and old OpenGL ES 1.0 Common Lite fixed-only library delivered by PowerVR (www.pvrdev.com). Old and sick because they supported OpenGL 1.1 on evey platform except of the WM5... And because they don't answer to emails and faxes... And other amazing junks like "32 bit Z buffers" and other funny bullshit. :P

On your iPaq you should use the Rasteroid (ex a. k. a. Gerbera) by Hybrid (www.hybrid.fi). This is a software (but very stable, clean and optimized) implementation of both OpenGL 1.0/1.1 Common and Common Lite profiles. This software is copyrighted but free for non commercial projects. Moreover, their site and the Hybrid staff is really cooperative: just have a check on their forum to gather more information or to obtain answers directly from the Rasteroid developers.

#13 yoursort   Members   -  Reputation: 122

Like
0Likes
Like

Posted 01 February 2006 - 09:36 AM

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]




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS