[Nick]

In light of epicstruggle's request for more activity in this forum, I figured we absolutely need a good old Direct3D versus OpenGL flamewar.

Actually I'm seriously interested what your favorite API is, why, and what you think about the future with Direct3D 10 and OpenGL 2.x. Also, is there any room for other API's? Will OpenGL|ES prevail in the embedded market? What's the importance of utility libraries like D3DX?

Let yourselves go!

[Simon F]

Originally Posted by Nick

Will OpenGL|ES prevail in the embedded market?

Wouldn't that more depend on the outcome of WinCE VS everything else?

[K.I.L.E.R]

I don't know how to start this war.
I've used both, liked them both but I prefer OpenGL because it isn't Microsoft.

[arjan de lumens]

Some points about the APIs that I feel are important:

• Features: DirectX is generally much quicker to incorporate new features into the mainline standard than OpenGL; OTOH, the extension mechanism of OpenGL permits new features to be exposed without having to go through Microsoft. A serious problem for OpenGL here has for a long time been the ridiculously slow pace of the OpenGL ARB, however this appears to be gradually improving.
• Driver architecture: With DirectX, writing drivers is generally much simpler than with OpenGL (many of the 'difficult' parts are placed in the Microsoft-supplied runtime rather than in the driver itself), with the result that the DirectX driver quality has practically always been better than OpenGL driver quality among vendors offering support for both (the only major exception here appears to be Nvidia). OTOH, DirectX has traditionally suffered heavy API call overhead compared to OpenGL - however DX10 is supposed to fix that problem.
• Compatibility: OpenGL is available for practically any platform, whereas DirectX is in practice Windows-only (yes, there are DirectX-to-OpenGL wrappers for Linux and MacOS, however they usually cause performance loss and other annyoing problems). Also, OpenGL does not break backwards compatibility between versions the way DirectX does, meaning that you can augment an existing application with new features without tearing up all the API interfacing code.
• Render-state handling: OpenGL's model of generally using 1 function call for every time a piece of state is to be changed adds annoying overhead if you're changing a lot of state in one go; also, it's hard to determine if any state can be reused at all. DirectX appears to be much better in this regard.
• Render-to-texture: While DirectX got this right something like 7 or 8 years ago (except for multisampling, which is supposed to be fixed in DX10), the only solutions available for OpenGL (pbuffers) were for a long time just awful, with respect to both performance and usage complexity. FBOs appear to mostly fix those problems, but they're STILL missing from the mainline standard. A similar, though less severe, complaint applied to vertex buffers for a long time as well.

As for the embedded market, OpenGL ES is getting rather entrenched by now, and the organization maintaining the standard (Khronos) is MUCH more aggressive than the ARB ever was (GLES2.0 is basically the same as desktop OpenGL2.0, minus the old fixed-function features and with slightly reduced resource/precision demands). There exists a mobile version of DirectX, but it appears to lag rather far behind on features and market penetration. Also, Microsoft is not yet really dominant in this market, and the companies that ARE dominant appear to be rather paranoid about Microsoft taking over this market too.

[nutball]

Originally Posted by arjan de lumens

• Compatibility: OpenGL is available for practically any platform, whereas DirectX is in practice Windows-only

One thing which bugs me about OpenGL is that although the core part of the standard is platform indepedent, there are still platform dependent elements in, for example, the way it integrates into the desktop. I'm referring to the wgl_ and glx_ extensions here.

In the recent years of increasingly rapid technological advance it seems to me that the non-Windows platforms have lagged somewhat in this regard. The wgl_ extensions appear months if not years before their glx_ equivalents. To some degree this is understandable (the two big PC-platform IHVs focus on Windows because that's where the market is), but I think it's also unfortunate.

A few examples of this: rendering to off-screen buffers, and floating-point frame buffers spring to mind. I waited 18 months - 2 years for these to become available under Linux, during which time they were readily available under Windows.

[ERP]

I don't dislike either API.
I'd need a good reason to pick OpenGL these days, probably compatability.

IMO DirectX more or less hit parity with openGL at about DX7, and it's been better in most ways since. The OpenGL extension model is really irritating.

The only thing I miss in DX is the imediate mode primitive submission for quick hacks and debugging. MS added this to the Xbox API, since it's natively supported by the undelying hardware and I was somewhat surprised it didn't make it back into DX9.

As for ES it's all about adoption rate.

[Cozmo]

Personally, with the continued shrinking of the fixed function pipe in both APIs, I see the relative importance of the core API, as a whole, diminishing, finding itself relegated to common plumbing chores as the programmable pipe takes up the responsibility of more and more of the goings on. In that sense, the shading languages become much more important and representative of the API's "look and feel", and that's where I see OpenGL, at least for the near-term PC landscape, wanting a bit.

Nvidia has apparently taken issue with some of the spec in GLSL, leading to an inconsistency across the board, which, IMHO, hurts the API - though I believe this comes with the very best of intentions. I admire a lot of what the ARB has done; but perhaps, in some ways, it was a hair ambitious and lacking in near-term practicality. Who knows; things could turn around quickly, and that forward-thinking could pay big dividends in the long run (I certainly hope so). And then there's OpenGL 3.0...

Me? I like both APIs - well, plenty to like and dislike on both sides, I suppose. But, as mentioned already, the ability to keep up with the technology is key; and this is where Direct3D has traditionally had the advantage, owing in no small part to its generational approach to versioning and its relatively narrow focus on game developers (though that's all about to change with Vista).

With D3D10, it looks as though Direct3D is beginning to favor OpenGL's layered approach to versioning. Perhaps they'll both find happiness somewhere in between. They've certainly learned a lot from each other.

[JHoxley]

I'm a 110% Direct3D person myself. Not that I'd be at all biased of course...

I can't really provide much comparison myself as I've only had brief run-ins in GL; but the extension mechanism never sat right with me. Yeah, you still get IHV differences under D3D, but it strikes me as being less of a mess than it is with GL.

I see the relative importance of the core API, as a whole, diminishing, finding itself relegated to common plumbing chores as the programmable pipe takes up the responsibility of more and more of the goings on.

I see what you're getting at, but I disagree.

Its role and responsibilities are (or have?) definitely changed, but its no less important IMO. D3D10's shader model is backed up by a very complex and powerful resource model - management of resources, interpretation (e.g. views/casting), binding and so on. Also, the effects framework moving into the core runtime is no small thing for the core API either...

Jack

[Cozmo]

Its role and responsibilities are (or have?) definitely changed, but its no less important IMO. D3D10's shader model is backed up by a very complex and powerful resource model - management of resources, interpretation (e.g. views/casting), binding and so on.

Points well taken, but that's where OpenGL 3.0 comes in. Resource access is going to be addressed for things like cubemap texture taps in geometry shaders, so we should see similar functionality in OpenGL - there's just the matter of when. Boy I'm sure hoping that this is already in the works. Anyway, my point was that this core functionality will be common to both API's, in one form or another; the difference, to my mind, will ultimately be the aesthetics of the shading languages, and the turnaround time for technology indoctrination within the API - which is where I fear OpenGL will lag behind, interminably.

Also, the effects framework moving into the core runtime is no small thing for the core API either...

The effects framework is cool, but it's fairly easy to slap something like that together for OpenGL. Direct3D has many comforts built in, for sure, but it's not as though those conveniences are at the core of the choice, at least not for me. I abstract my rendering engine to the point that the API I use makes little difference overall, except where already mentioned.

As for extensions, I've been using them for so long that they no longer seem irritating - though I can certainly understand the objection, on several grounds. But heck, they put hair on you chest (if only they'd put hair on my head).

[Rodéric]

I was soooo wiling to close this thread when I saw the title... but there's nothing in to warrant a lock


I prefer OpenGL for it's not being made by MS.
OpenGL 2.0 Pure was to be what D3D10 will be, it's very sad that it never came to life.

I'd say that OpenGL have features SOONER, but not in as ARB extensions though.
D3D7 was the first D3D to come close to OpenGL, but only D3D9 is on par with it IMO, however it's clear that D3D10 will be ahead of OpenGL when it comes to API quality. (Smooth clean API)

Forgot to say that OpenGL|ES 2.0 seems API centric cleaned up OpenGL, the way of the future ? (lacks some features you'd like for desktop though)

OpenGL 3.0 Shader centric, where are you ?!
(And yeah, I agree wgl/glx is no fun, I'm very happy EXT_framebuffer_object came to clear some of the mess, but it better be the rule to get rid of anything OS specific [except for opening a window, which you can't escape])

[JHoxley]

Originally Posted by Ingenu

I was soooo wiling to close this thread when I saw the title... but there's nothing in to warrant a lock

OMFG OpenGL sucks. Direct3D is better. Just is. Fact.

That any better for you?

Anyway, my point was that this core functionality will be common to both API's, in one form or another; the difference, to my mind, will ultimately be the aesthetics of the shading languages, and the turnaround time for technology indoctrination within the API

Yeah, I suppose thats a fair comment.

One thing I haven't seen raised so far that I think is equally important to the source-code/API level. Tools.

Slightly OT, but a lot of developers I've spoken to loved XBox development (instead of PS2) for the simple reason it had better tools, documentation, support and was just generally better to develop for. Not that one of the API's were substantially better/worse.

I can't really comment on the OpenGL side (hopefully someone else can), but simply downloading the DXSDK gets you "PIX for Windows", Debug Runtimes, Reference rasterizer, Texture Viewer/manipulation, dxops, dxviewer...

I'm not 100% sure, but things like NVPerfHUD are D3D only, right? Does RenderMonkey handle Cg/GLSL as well?

I've only heard of "gDebugger" in the OpenGL camp, but I'd imagine there have to be more. I've no idea what the standard of official OpenGL info/docs are either.

If you put the target market/audience to one side, then surely the API with the better tools/documentation is going to lead to quicker and easier development and happy programmers

Cheers,
Jack

[Xmas]

Originally Posted by Ingenu

OpenGL 3.0 Shader centric, where are you ?!
(And yeah, I agree wgl/glx is no fun, I'm very happy EXT_framebuffer_object came to clear some of the mess, but it better be the rule to get rid of anything OS specific [except for opening a window, which you can't escape])

Since OpenGL ES 2.0 and OpenGL 2.0 are already pretty close in functionality, I could imagine there being only be one 3.0 API. Hopefully using EGL then.

[Mintmaster]

Originally Posted by ERP

The only thing I miss in DX is the imediate mode primitive submission for quick hacks and debugging. MS added this to the Xbox API, since it's natively supported by the undelying hardware and I was somewhat surprised it didn't make it back into DX9.

Doesn't DrawPrimitiveUP and DrawIndexedPrimitiveUP cover all your needs? I can't see it getting much simpler than that.

[drpepper]

This is not much of a flamewar...

Anyways, question. OpenGL ES gets rid of the "fixed-function" as one poster points out. What is this and how does this make it more suitable for embedded applications?

Now flame on guys.

[Rodéric]

Originally Posted by drpepper

This is not much of a flamewar...

Anyways, question. OpenGL ES gets rid of the "fixed-function" as one poster points out. What is this and how does this make it more suitable for embedded applications?

Now flame on guys.

Fewer entry points; less complex driver, less place taken, less bug opportunities, better/easier profiling...
The API is a lot less complex, I don't know but I think it's (wild guess here) 30% of the number of functions of OpenGL.

I think you wrongly assume that embedded systems = low end hardware, that's not quite true, check PowerVR hardware (MBX/SGX) and you'll see it's rather capable. (to say the least)

I like OpenGL|ES 2.0, it's a lot cleaner, got rid of lots of old not so useful entries, not quite what I would like OpenGL3.0 to be, but very close.
(I'd like some removed capabilities kept.)

[darkblu]

jeez guys, these are the most pathetic attempts at a flame war i've seen on these bords yet! here, let me give you a hand..

d3d took a very long a painful road till it got to any level of maturity. in contrast nothing i ever saw in ogl (i'm a bit lagging though, still at 1.4) made me say 'WTF!?' the way things have in d3d. having spent way more time in d3d than in any other API let me say it leaves a long-lasting bitter aftertaste (my present project is ogl-centric but i still catch myself in d3d-thinking patterns and caps paranoia). last but not least, i don't like APIs that are trying to closely direct the future development of hw. same control grip scheme MS got on the desktop core with windows now exists in the GPU market. now and then a sufficienty heavy-weight GPU IHV manages to get in bed with MS and knock some sense into their heads, but that also means individual IHV indoctrination and the imminent 'the other party sucked in bed' post-declarations from both the sides.

[LeGreg]

Originally Posted by drpepper

This is not much of a flamewar...
Anyways, question. OpenGL ES gets rid of the "fixed-function" as one poster points out. What is this and how does this make it more suitable for embedded applications?

With a regular implementation of opengl, the driver would probably take all the available memory of those embedded platforms (software rasterizer included).

OpenGLES is used on the PS3 for example which has not so much RAM, but a powerful gpu.

[speedy1]

Let me use my feeble DX knowledge and make the next comparison:

OpenGL has PBOs on NVIDIA (aka. fast async DMA upload of textures) - DX9 does not

DX9 has proper instancing - OpenGL extension is in beta on NVIDIA

DX9 has proper render to vertex array - OpenGL has it only on NVIDIA

DX9 has better profiling tools - OpenGL catches up slowly on NVIDIA

OpenGL is portable - DX9 not really

OpenGL is backwards compatible - DX9 not really

OpenGL is forward compatible - DX9 not really

OpenGL is prettyer umm. because lot of thought goes into each API part? - DX(9) catches up, somewhat

OpenGL has faster batches - DX9 is bloated there

other than that - DX9 has fences? and what about HW occ. culling?

as a game developer using OpenGL, I can just hope ATI catches up soonish..

[ector]

"DX9 has proper render to vertex array - OpenGL has it only on NVIDIA"

Correction: DX9 doesn't really support render to vertex array but ATI has invented a hack to make it possible.

And this, I'm not happy about. I want it on Nvidia without having to switch to GL


"OpenGL is prettyer umm. because lot of thought goes into each API part? - DX(9) catches up, somewhat"

I'd argue that while OpenGL is easy to do simple things in with glVertex etc, DX9 is a far better organized API. It just feels much more logical. But that might just be me...

But DX10 is REALLY well designed. I doubt anyone will argue against that. Too bad we can't use it yet..

"OpenGL has faster batches - DX9 is bloated there"

Absolutely, although they are fixing this in Vista with the new driver model, both for D3D10 and to a smaller degree for D3D9. Can't wait...

"other than that - DX9 has fences? and what about HW occ. culling? "

Yes, D3D has the same kind of occlusion queries, basically.

[JHoxley]

Originally Posted by ector

But DX10 is REALLY well designed. I doubt anyone will argue against that. Too bad we can't use it yet..

Well, you can - you just have to install Vista Beta 2 and the June SDK first.

Up until Vista exploded on my HW I was using D3D10 from last summer... it's nothing but a breath of fresh air.

Originally Posted by ector

"OpenGL has faster batches - DX9 is bloated there"

Absolutely, although they are fixing this in Vista with the new driver model, both for D3D10 and to a smaller degree for D3D9. Can't wait...

The thread I started in the general 3D hardware/technology forum contains some figures backing up the 10x faster submission speeds.

Difficult to tell for sure when running on the RefRast though!

Jack

[DudeMiester]

It depends on what you mean by DirectX, if you mean DX9 then I'd say OGL is better, but no so with DX10. It incorperates most of the features that makes OGL better (shared GPU, not much kernal code) and it has a much more streamlined API, but it's categorically not extensible, it's non-portable and not a public industry standard. Thus, DX10 is slightly better from a technical perspective, but slightly worse from a cross-platform/maintainability perspective.

However, this advantage will not last. First of all, control OpenGL will be transferred from the ARB to the Kronos Group by the end of this year, which will help ensure faster updates and stronger marketing. Second, OpenGL has excellent profiling, at least with Nvidia, thanks to the latest versions of NVPerfHUD. Most importantly, there are already plans for an OGL 3.0 that breaks backwards compatibility and is far more sophicsticated then DX10. Of course, this still maintains BC by seperating the API into legacy and current profiles, which the application selects by how it loads OGL. Anyways, the proposed API fully abstracts all state into well-structured objects, exposes shaders for geometry, framebuffer sampling and texturing sampling, offers more types of interpolants, adds instancing, and throws in some more sophisticated data formats/arrays. It will come out in the form of OGL extentions starting ASAP until the final API can be decided on.

http://www.gamedev.net/columns/event...cle.asp?id=233

[SoftwareGuy256]

I looked at Q3 source and it seemed to have glVertex3f() scattered in several places. From what I read, D3D is basically 1000 batches per frame max. Does such a limit exist for OpenGL?

[ERP]

Originally Posted by SoftwareGuy256

I looked at Q3 source and it seemed to have glVertex3f() scattered in several places. From what I read, D3D is basically 1000 batches per frame max. Does such a limit exist for OpenGL?

Not exactly.
OpenGl doesn't have the small batch problem in the same way.
It's still a good idea to limit the number of batches submitted, but it's nothing like a crucial.

[Rolf N]

Originally Posted by SoftwareGuy256

I looked at Q3 source and it seemed to have glVertex3f() scattered in several places. From what I read, D3D is basically 1000 batches per frame max. Does such a limit exist for OpenGL?

No. OpenGL has always had a proper driver model, so the API overhead was entirely up to the implementors (ATI, NVIDIA et al) and in practice is much much lower than Direct3D, which is making switches to kernel mode and back all the time for no good reason.

Of course this has never been relevant up until now, but because Microsoft has promised to fix this glaring flaw with Vista, it's now the most important thing ever

Beware of people bullshitting you into buying Vista for its "DX9L support to make your old games run even smoother". Trust me, will happen soon. Those are the same people that used to say OpenGL is "for workstation apps, not for games".

[db]

Originally Posted by zeckensack

No. OpenGL has always had a proper driver model, so the API overhead was entirely up to the implementors (ATI, NVIDIA et al) and in practice is much much lower than Direct3D, which is making switches to kernel mode and back all the time for no good reason.

Of course this has never been relevant up until now, but because Microsoft has promised to fix this glaring flaw with Vista, it's now the most important thing ever

Beware of people bullshitting you into buying Vista for its "DX9L support to make your old games run even smoother". Trust me, will happen soon. Those are the same people that used to say OpenGL is "for workstation apps, not for games".

No. The fixes in Vista have nothing to do with uncessary calls to the kernel. I don't know why the myth persists that D3D calls the kernel more often the OpenGL. They both buffer to cmd buffers in user mode and then send them to the kernel. They may chose to use different buffer sizes, but they fundamentally do they same thing. The place where they differ is that the D3D runtime in XP builds machine independent buffers and the IHV driver translates them to machine specific tokens in kernel mode. In Vista the runtime calls a user mode driver to build machine-specific buffers and avoid this translation step. The catch is that IHV drivers MUST ensure that these user-mode machine-specific cmd buffers do not contain operations that can compromise the security or robustness of the overall system (e.g., DMA access to arbitrary system memory). It remains to be seen whether OpenGL drivers ever provided that level of security, but it is a fundamental requirement for Vista to improve stability.

Read the WinHEC slides on the driver model, it has been publicly described for at least 3 years now.