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.