DirectX sucks. OpenGL sucks. What do us graphics programmers need?

Here is an interesting read on that subject.

http://arstechnica.com/gaming/news/2008/09/gpu-sweeney-interview.ars

Thanks for the link! I'll check it out right now!

Writing the same back-end for half a dozen different bits of hardware is just a fact of life for a low-level graphics programmer, I'm afraid.

Quote:

Original post by xXShadowAsasNXx -Constant development & updates like DirectX. -No cost. -Cross-Platform support like OpenGL.

How do you fund constant development without cost? Microsoft gets away with it because locking people in to their platform counts as income to them ;)

Quote:

-Not having to write up vendor-specific hacks(OpenGL).

Any good DirectX engine will have lots of vendor-specific hacks too. Things like doing efficient PCF differ quite a bit between vendors, and don't get me started on D3D "extensions", like R2VB:
SetRenderState(D3DRS_POINTSIZE, r2vbGlbEnable_Set(TRUE));
I'd much prefer GL's vendor extensions than hacks like that!

However, if new hardware is always coming out with new capabilities, how would your perfect library expose the new functionality without vendor-specific code paths?

Quote:

-Both a procedural AND object oriented interface like Leadwerks game engine.

You can make your own wrappers to proceduralify D3D, or OOify GL...

Quote:

-No driver problems

I'm pretty sure that "no bugs" is on every software developer's wish list.

Quote:

-As much programmability as possible.

This is really down to what the hardware gives you, not the library (unless you want to sacrifice speed).

Quote:

-Support for adding new functionality.

How does this work?

Quote:

P.S. Maybe we just need the CPU and GPU to merge, and one programming language for both

Have you tried OpenCL?

Very interesting... I wonder how far away this technology could be. It is a bummer Larrabee(as a graphics card) got canceled.

IDK how to do quotes, so... yeah. Anyways.

How do you fund constant development without cost? Microsoft gets away with it because locking people in to their platform counts as income to them ;)

True, true.

Any good DirectX engine will have lots of vendor-specific hacks too. Things like doing efficient PCF differ quite a bit between vendors, and don't get me started on D3D "extensions", like R2VB:
SetRenderState(D3DRS_POINTSIZE, r2vbGlbEnable_Set(TRUE));
I'd much prefer GL's vendor extensions than hacks like that!

Not so much in DirectX 10/11.

You can make your own wrappers to proceduralify D3D, or OOify GL...

I know, I am just not up to the task.

I'm pretty sure that "no bugs" is on every software developer's wish list.

Lol, I know. OpenGL has too many driver bugs than it should have, though.

This is really down to what the hardware gives you, not the library (unless you want to sacrifice speed).

True.

How does this work?

I didn't exactly think that through, lol.

Have you tried OpenCL?

No, but I have heard of it. I don't think it's quite ready to be adopted by graphics programmers making mainstream games yet though.

I find it an interesting concept to consider and cool in so many levels. I mean it was just around 14 years ago when I bought the 3DFX Monster3D and was floored by how great it looked and that was in Quake (which by today's standards looks like Pong). I could never imagine "software" rendering ever coming close to that kind of speed and visual quality. Today's games are doing things I never thought I would see and there are many advances which can still be made. Interesting times ahead.

@Lothlor

Indeed. There are so many possibilities for the future...

Quote:

Original post by Lothlor I find it an interesting concept to consider and cool in so many levels. I mean it was just around 14 years ago when I bought the 3DFX Monster3D and was floored by how great it looked and that was in Quake (which by today's standards looks like Pong). I could never imagine "software" rendering ever coming close to that kind of speed and visual quality. Today's games are doing things I never thought I would see and there are many advances which can still be made. Interesting times ahead.

I found it interesting, reading the slides from a recent Unreal Engine presentation, that we're heading back to software rendering, and how much faster it potentially will be. Makes pretty good sense, especially with the future of general purpose mega-multi-core processors. Getting data to the graphics card has always been a big bottleneck.

Why not use some middleware that supports multiple platforms? Something like Ogre or Unity support whatever you want it to. If you are looking for something more advanced, you would likely have to go with a software solution. Are you looking to do custom graphics programming, or just build a game on several platforms? If it is the latter, then just use some middleware to do what you want.

Quote:

-Cross-Platform support like OpenGL.

A typical misbelief.
If we are talking about the major gaming plattforms DirectX is more cross plattform than OpenGL.

But DirectX and OpenGL are both low level system APIs. You should use middleware if you want to build a game. If you want to write your own cross plattform engine, create an abstract layer (it's not really difficult). If you just want to experiment, forget about cross plattform.

Amen, brother. You said it. Both OpenGL and DirectX suck. I'm amazed by how many people are caught up on those 'API wars' when the difference between them and the impact they have on a project is so tiny. They talk about Direct3D this and OpenGL that, as it has any significance. The only ones that care are the driver developers, that have to support both APIs.

Beyond that, for game developers, it's just a matter of abstracting your renderer and just have a handful of files for each API, which both expose the exact same functionality. There isn't much of a difference at all. For example, the 'nightmare' of multiple code paths for OpenGL just isn't an issue anymore, *for applications developers*. Go check . You won't find the ancient cruft like immediate mode or display lists in there. Driver developers have to maintain support for them, and that's unfortunate, but app developers creating modern games could not care less(given that they don't care about running their game in GeForce 2). Most games are ported to many different platforms, PC(DX/OpenGL), PS3(libCGM), XBox360(DX9-like),Wii(proprietary) and then there's other platforms you can't ignore, like iPhone,or handhelds, the list never ends.

Do serious developers lost their sleep over this? The API calls are like 5% of your rendering code, which is like 5% of your total engine code. If the choice of a rendering API is a big fuss for you, you're doing it wrong or you're a fanboy. Once you have defined your target hardware, and your renderer design, the rest is just unimportant(or, as a certain someone would put it, IMPLEMENTATION DETAILS :P ). Their pipeline is exactly the same, as Sweeney points out, you just feed the card with triangle data, they go through transformation, same rasterization process, programmable shaders, blending equations and that's that. There's no real difference to speak of. Sweeny pointed out that DX9 was the last API that 'mattered', and I have to say that judging from the fact that developers aren't really dying to get their hands on DX10 and DX11(and when they do, the difference in quality is very small), he seems to be right. He says the next 'revolution' will come when more of the core functionality of the GPU will become programmable, and again, that seems the logical thing to assume.

The three things OpenGL really sucks in is its abysmal documentation (especially when it comes to extensions), lack of transparency (usually coming with bull like "you don't need to know anyway" and "why not let the user choose?"), and strange, incomprehensible strategies about implementing new things (think of buffers, render targets, blend modes).

Other than that, OpenGL is pretty straightforward, and while there might admittedly be some things to polish here and there, it's a quite nice and easy overall API (if one doesn't absolutely want an object oriented API).

I don't see the extension model as a bad thing, by the way. Actually this is the best way you can support the widest range of hardware in a compatible way. The problem is that it's sometimes done in a way that is non-obvious, sometimes ambiguous, and sometimes wrong by design.

Quote:

Original post by CV Quote: -Cross-Platform support like OpenGL. A typical misbelief. If we are talking about the major gaming plattforms DirectX is more cross plattform than OpenGL.

For a start, you should be comparing GL to D3D and not DX. Secondly, can you count? :p

Direct3D: Windows, Xbox 360 (with extensions). The original Xbox does *not* count.
OpenGL: Mac + linux + windows.
OpenGL ES: Blackberry, iPhone, Nokia, PSP*, PS3*, Wii*, windows smartphone, Symbian, Sony Erricson, and so on and so on....

That's 2 for D3D, and lots and lots for GL.... Arguably by far the biggest gaming platforms out there right now are mobile phones. There are hundreds of millions of mobile phones out there, compared to just a few tens of millions of games consoles.... OpenGL has more platform support than D3D, and it also has the highest percentage of users....

(* GL ES is available, but generally people use the lower level graphics API's for the hardware)

Quote:

-Not having to write up vendor-specific hacks(OpenGL).

Well that one was maybe true as of 2002, but you know, we're in 2010.. i doubt you have a lot of vendor specific hacks to do anymore nowadays.. the ARB did a good job, really. :)

And well.. about the topic.. I'd rather say that anyway the world is gonna DISAPPEAR in 2012 anyways so we don't care! ;) :D

Now I have a question...

Say we come to the point where the GPUs will be 100% programmable...you think that big companies like Epic or Id will write their own renderer? It seems to me like quite a bit of work to write a high-performance parallelized software renderer from scatch in a general-purpose language...there are a lot of tricks used under the hood currently to get the best performance and you must know about the card architecture(does that mean you'll have differently tuned renderers for different cards?); a naively implemented rasterizer will be much worse than the current DX or OpenGL ones. Of course those guys wrote renderers back in the 90's so I don't think it's gonna be a huge problem for them, but it's still some work. Or do you think we will still use something like DirectX built on top of it all, and that's what most will still use, unless they want to make a radically different renderer?

A prediction

Nobody will write their own 100% software triangle rasterizer while hardware is still rasterizing triangles, you simply won't beat the hardware version for the same number of transitors (transitors = cost) This is why Larabee got canned, the difficulty in competing with dedicated hardware is immense, hats off to Intel for trying. The truth is, Larabee was an idea ahead of it's time, the lessons from Larabee remain however hugely valid. Rasterization doesn't scale to massive data sets as well as ray tracing (which is why everyones getting excited about ray tracing) We're simply not ready for the switch yet and so Larabee got canned.

I don't see raytracing / other techniques replacing rasterization in the short to medium term but rather complimenting it, i.e. we will see hybrid renderers way before a wholesale switch is made. CUDA will shortly become more relevant than ever.

One problem with 100% programmable graphics chip is that 90% of programmers will not want to deal with all the concurrency / pipelining issues. Most companies would sacrifices 5% performance for a 95% gain in ease of programming because:
1. Ease of programming = cheaper
2. Good programmers are hard to hire
That is, even if you could roll your own 100% software solution, most people will continue to use DX / OGL. A few companies would brave writing their own solutions and indeed why reinvent the wheel?

Now we hit upon another problem with not using DX / OGL, what standard would there be for writing a 100% in house solution? Some degree of abstraction is actually very healthy if your code is to be portable / future proof. Ok, on a console we could write directly and specifically for the hardware, but unless you're developing for only one consoles, most companies would prefer to use some abstracted API to save them time, hassle, cost.

There is yet one more problem, it is possible / probably that IHV's would never want you writing 100% custom solutions, they have their intellectual property to protect after all.

I really like DX, these days it's one of the best API's about. (I have to use both DX and an OGL variant in my job) I accept that DX is harder to learn but when you're there, its nice!

Quote:

Original post by mikeman Say we come to the point where the GPUs will be 100% programmable...you think that big companies like Epic or Id will write their own renderer?

Maybe, but I very much doubt that someone may want to throw away the hardware abstraction layer that is D3D/GL. It could happen on a games console where the hardware specs are well defined, but even then that's highly unlikely....

Quote:

Original post by xXShadowAsasNXx Well, I have been programming graphics demos lately in Direct3D. I really like the DirectX API and all, but the constant version changes, inability to add your own functionality,

I build my project in MSDirectX9SDKOctober2006. I have a full programable GPU pipeline through HLSL and can target any pixel shader compiler, max I have tried is 3.0ps,3.0vs. I am gonna look right now wheather 4 and 5 too.

functions of classes IDirect3D9Effect, IDirect3D9Device and classes those use are enough for you to render images that looks like static prerenders from 3dsmax.

I think the GPU call is only dx runtime linked, since dx runtime is supposed to translate your instruction.

GPU calls I use are:
for device:
-SetStreamSource
-SetIndicies
-SetVertexDeclaration
-DrawIndexedPrimitive
-BegineScene
-EndScene
-CreateVertexBuffer
-CreateIndexBuffer
-CreateTexture
-Present
-Clear

for effect:
-Begin
-End
-SetTexture
-SetUniformVariable
-BeginePass
-EndPass
-CommitChanges

So if you successfuly create device on an another OS, you are set up for multiplatform. You would have to try to somehow get context of a window to present your render target on. But you can render offscreen and present your picture in an arbitrary way.

Quote:

Original post by xXShadowAsasNXx but the constant version changes,

Frankly this isn't really true; DX9 stuck around for a little under 4 years before DX10 came along. While the DX10 to DX11 transition has been faster it was somewhat a non-issue due to lack of uptake and the closeness between DX10 and 11 in terms of the API.

While 'stability' is nice from time to time you need to bite the bullet and change things because your original abstraction is no longer fit for what you are trying to abstract. OpenGL suffered the same problem, it has been improved upon post GL3.0 but the API is still somewhat archic to work with in the face of something like D3D11.

As for "developers aren't really dying to get their hands on DX10 and DX11"; well maybe not DX10 however DX11 has had a faster uptake into games then DX9 ever did; it took months before the first DX9 game hit, the first game with a DX11 renderer was out within weeks (and older games patched to use it) and does look (and I'm told feel) better in DX11 more. You'll still see DX9 games appearing because of market weight, but that'll shift as Win7 takes over from XP, which unlike the Vista shift IS happening. There will also be some simply because consoles are still DX9 level (although, in theory, MS could push D3D11's API onto the 360 and have it run in D3D9 caps mode, which if their next console is going have an API anything like DX11 would make a degree of sense), but the shift to D3D11 is on and moving forward.

On the subject of 100% programmable GPUs..well, we are basically there. Very few areas of the GPU remain untouched by shaders now; triangle setup, input assembler (although that is mildly programmable in D3D11) and the blending/ROP stage are the 3 which spring to mind, and of those 3 only blending stands out as a good candidate for making programmable, and even that has lost its urgency with compute shaders as you can use them to do things such order independant transparency.

I'm willing to bet that the guys who make the GPU are going to be better placed to handle the stuff which is needed to run them better than someone who is coming in cold to the hardware. The amount of effort required to do it optimally for even ONE class of GPU is going to be mind bendingly hard... now, consider how many types of GPU could be common at any given time and with different archs... yeah.

Personally I'm fine with GL and D3D; with all the shader options open to me I don't fine myself thinking 'man, if only I could add X' and there has yet to be a good idea put forward as to what 'own functionality' you would want to add to this magical API anyway.