Hey people,

I am in the (pre)process of making a 3D engine/framework to fool around in. This is mainly a learning thing for me at the moment, but I do want to keep an eye on the future. Most likely this thread will be more of a "rubber ducking" thing rather than a "Help me choose" thread, but I value good argumented opinions.

Now one of the bigger choices I am facing is whether to use OpenGL or DirectX, but I am not entirely sure which one would be the best pick with the future in mind together with learning new stuff.

The thing is. I made a couple of 3D frameworks for smaller assignments and I used ("modern") OpenGL for that, giving me an advantage over the fact that I already know a good deal about it, but in terms of using the graphics API in itself, there is less to learn in contrast to DirectX, which I only really was able to scratch the surface of in the past with D3D9.

One of the things that I am wondering about however is the future of both of these APIs.

From sources I am not sure I am allowed to mention, I heard that NVidia is experimenting with ditching the graphics APIs as a whole and instead lets us program the graphics card directly. I am also not sure how valid this is, it can also be something misinterpreted.

I also noticed that some companies (like valve) started switching to OpenGL for the sake of multiplatform compatibility and I don't really see DirectX going multiplatform anytime soon (if ever).

Also with the exception of the xbox consoles, I think most of the consoles use OpenGL or something more similar to OpenGL.

What do you think the future has in store for us? I did google a bit, but I can't really find any nice articles of the direction of graphics APIs for the (near) future.

What would you choose to do if you are chasing a career in graphics programming? Expand your knowledge to a broader spectrum, or go more in depth with what you already know?

The APIs are getting closer and closer to how the hardware works so there is not much space for differences at the API level. This means they will expose rougly the same functionality, just with different names for certain concepts and how you use them.

That leaves pretty much two things to consider:

-Support across different platforms

-Architecture (ease of use)

The first is plus for OpenGL, the second for DirectX since the state machine approach of openGL is apparently broken and makes some things not as nice as with directX. Im not sure if that is going to a better direction (likely is) but for that reason you might want to at least try directX to see how things are implemented there.

There are also things like GPGPU computing, which you might want to use alongside the graphics API. There might be differences in how the graphics API interfaces with whatever GPGPU API between directX and openGL.

From sources I am not sure I am allowed to mention, I heard that NVidia is experimenting with ditching the graphics APIs as a whole and instead lets us program the graphics card directly. I am also not sure how valid this is, it can also be something misinterpreted.

This was the state of affairs before Glide/GL/DX/etc arrived on the scene. It was a nightmare for developers.
Sure, we'd all love to pare back GL/D3D a bit these days so they're a thinner abstraction, but going back to a driver free-for-all would be terrible.

Interpreting this statement another way though, your source could be implying that with the arrival of OpenCL/CUDA/DirectCompute, the GPU hardware is becoming more and more open to how it is used, rather than forcing us to follow the traditional pipeline specified by GL/D3D. That sentiment is definitely true -- GPU's have certainly become "GPGPU's" or "compute devices", that are extremely flexible.

I also noticed that some companies (like valve) started switching to OpenGL for the sake of multiplatform compatibility and I don't really see DirectX going multiplatform anytime soon (if ever).

IMHO GL's "portability" is a poisoned chalice. Every different driver contains a different OpenGL implementation. Even on a single OS, like Windows7, you've got half a dozen (or more) different OpenGL implementations that you will need to test your game on, and possibly have to make changes for. Khronos makes the spec, but they don't actively enforce 100% compliance with it.

Doing professional QA for a GL engine on Windows/Linux (or any engine on Mobile/Web) is a complete nightmare. You need a tonne of different devices/GPUs and a lot of time.

I made a personal decision (other opinions will vary!) to simply choose D3D on Windows because I found the maintenance costs to be lower, due to it's behaviour being dictated (and tested/validated/enforced) by Microsoft.
On MacOS, the situation is similar with Apple being a benevolent dictator ruling over GL, ensuring it's implemented properly, so GL isn't as flaky there.
On Linux, there is no benevolent dictator. D3D9 can be mostly emulated in Wine, and GL support is entirely up to the driver.
On mobile, GLES support varies wildly from device to device. You'll really want to test your code on every single different device...
On web, your user's browser might have WebGL in some capacity, or flash, probably, maybe. But web has always been a compatibility/porting nightmare.
On consoles, you've probably only got the choice of using some proprietary API that's different to all of the above.
So personally, I choose to use multiple APIs -- the most natural/stable one for each platform, D3D9, D3D11, GL3, GLES2, etc...

Also with the exception of the xbox consoles, I think most of the consoles use OpenGL or something more similar to OpenGL.

No, unless by "similar to OpenGL" you mean that they have a plain-C interface, or unless you'd also say that D3D is similar to OpenGL (which is kinda is)
The exception is the PS3, which provides it's own native graphics API (which everyone should be using), and also provides a crappy wrapper around it called PSGL, which makes it look similar to GL.

What would you choose to do if you are chasing a career in graphics programming? Expand your knowledge to a broader spectrum, or go more in depth with what you already know?

Both
I jumped back and forth between D3D and GL at different points in time, and the more you do it, the more they both feel the same. Graphics programming should eventually be about what you make with the APIs, not the irrelevant details of how you use them. I'd much prefer to hire a graphics programmer who can implement different types of lighting systems (forward/deferred/tiled/clustered/etc), post-processing effects, materials, special effects, and so on, on any single API at all, rather than someone that knows all APIs inside out, but can't demonstrate practical use of them.
The knowledge of how to achieve some effect on top of an API is portable to all APIs of the same class (e.g. D3D9 vs GL2, D3D11 vs GL4, etc), and it is a much broader and deeper skill set. Learning the nuts and bolts of a particular API's interface is more rigid, structured learning, which any graphics programmer can do in time. Once you've learned one API, picking up another is pretty straightforward.

The first is plus for OpenGL, the second for DirectX since the state machine approach of openGL is apparently broken and makes some things not as nice as with directX. Im not sure if that is going to a better direction (likely is) but for that reason you might want to at least try directX to see how things are implemented there.

I heard counter arguments though, that OpenGL in its current state is more robust. Can you clarify?

No, unless by "similar to OpenGL" you mean that they have a plain-C interface, or unless you'd also say that D3D is similar to OpenGL (which is kinda is)
The exception is the PS3, which provides it's own native graphics API (which everyone should be using), and also provides a crappy wrapper around it called PSGL, which makes it look similar to GL.

Well. I actually only programmed on the PSP and PS3 and in general it just felt pretty much the same as OpenGL, that's actually what I meant :)

Interpreting this statement another way though, your source could be implying that with the arrival of OpenCL/CUDA/DirectCompute, the GPU hardware is becoming more and more open to how it is used, rather than forcing us to follow the traditional pipeline specified by GL/D3D. That sentiment is definitely true -- GPU's have certainly become "GPGPU's" or "compute devices", that are extremely flexible.

I think that is most likely the case indeed. I'm not from the age of driver free programming, but I can imagine that there will always be a layer between or else there will most likely be a commercial entity that will make it.

Both major APIs are converging towards the hardware, and the hardware from competing vendors is converging towards similar logical programming models, if not physical architecture. Beyond that, I think the trend will be to push programmability down into more stages of the pipeline -- truly programmable tessellation seems a shoe-in at some point, lots of smart people have said programmable texture sampling would be nice (although that gets rather hard to implement in hardware). Currently, the most modern GPUs are very optimized for compute, but still clearly graphics-first; I think in the future GPUs will flip this around and compute will really be the first-class citizen, but they'll maintain the necessary fixed-function components (texture sampling, ROPs, etc) to maintain leading graphics performance.

The only really divergent thing we know that's going to happen, is that nVidia is going to start putting ARM CPU cores in their GPUs. That'll probably have a lot of interesting applications that people are yet to think of.

Up to a year ago I would have unreservedly recommended D3D - it's a cleaner API, drivers are more robust, better tools and support, and more consistent behaviour on different hardware/driver combos. Nowadays - I'm not so sure. I would have hoped that MS had learned their lesson from Vista - locking D3D versions to Windows versions is not a good idea - but it seems that they haven't. None of that takes away from the fact that D3D9 and 11 are still the best-in-class of their generations, and even with the new XBox being 11.2 it's a safe bet that the majority of titles will still target vanilla 11 in the PC space for at least the next few years.

OpenGL's portability is not as big a deal as it's often made out to be. Even if you don't give a damn about portability, you can still hit ~95% of the PC target market (assuming that the latest Steam survey is representative). Unless you're going for a very specific, very specialized target audience where you know for a fact that the figures are different - don't even bother worrying about it.

The really big deal with OpenGL is that it does allow new hardware features to be accessed without also requiring an OS upgrade. You can also drop in handling for them without having to also rewrite the rest of your renderer. That of course needs to be balanced against the driver situation (a safe bet is to just copy whatever id Software titles do as you can be certain that at least is well supported) and the mess of vendor-specific extensions (which can be seriously detrimental to hardware portability).

Longer term it is always most beneficial to know both, of course.

firstly, that's not a rant, but my point of view :)