The Death of DirectX and OpenGL

[ish718]

The more general purpose GPUs become, graphics APIs will become less relevant, correct? O_O
Like being able to code directly to the GPU using C++. AMD is bringing c++ support with southern islands and Nvidia will bring improved c++ support with Kepler.

APIs are holding back GPUs, that's why PC games running on GPUs that are like 10x more powerful than the GPUs in console don't look nearly 10x better than console games.

I know APIs bring lots of leverage to developers with compatibility across a wide range of platforms and optimizing for one hardware configuration is a no no in PC gaming right now.

What if in the future where all GPUs fully support C++, this would allow a lot more low level access to the hardware for developers and they wouldn't have to worry too much about compatibility issues since all GPUs would support C++.

lol, I realize this will complicate PC game development( hell, learning DX11 ain't easy either) and probably skyrocket development cost but it would bring more sales. There are already tons of graphics libraries for C++. I can't wait until all GPUs fully support C++.

What is your take on this?

[codedivine]

The more general purpose GPUs become, graphics APIs will become less relevant, correct? O_O
Like being able to code directly to the GPU using C++. AMD is bringing c++ support with southern islands and Nvidia will bring improved c++ support with Kepler.

APIs are holding back GPUs, that's why PC games running on GPUs that are like 10x more powerful than the GPUs in console don't look nearly 10x better than console games.

I know APIs bring lots of leverage to developers with compatibility across a wide range of platforms and optimizing for one hardware configuration is a no no in PC gaming right now.

What if in the future where all GPUs fully support C++, this would allow a lot more low level access to the hardware for developers and they wouldn't have to worry too much about compatibility issues since all GPUs would support C++.

lol, I realize this will complicate PC game development( hell, learning DX11 ain't easy either) and probably skyrocket development cost but it would bring more sales.

What is your take on this?

Well, first a clarification. None of the current GPUs supports C++ directly. They support dialects of C++ sure, but you don't take your existing C++ program and just recompile. You have to write GPU-specific code, ensure your programs are highly threaded, ensure that it uses the memory hierarchy of the GPU well, manage the data transfers and the address space is not truly unified. This will all become easier in time but right now it is not that easy.
Second, for costs, it is not just a matter of programming costs. Art budgets often meet or exceed the programming budget these days. And games have become really costly and time consuming to develop so I do not think anyone wants even bigger budgets.
Finally, it is not clear whether improving the visual quality is worth the effort and money. We are frankly at the point where increases in visual quality are going to give decreasing returns.

So overall, I am not too optimistic. Sure technology will move on and sure APIs like OpenGL or DirectX will become less relevant, but the value (both economic and game experience) of this are questionable. Money is probably better spent on things like polishing gameplay mechanics, level design, game content etc.

[UberGerbil]

The more general purpose GPUs become, graphics APIs will become less relevant, correct? O_O

Not necessarily. APIs can provide both convenient abstractions and useful libraries of functionality. Even if you're coding to nVidia's or AMD's variant of C++, you're coding to a graphics API. And those variants differ from each other...and will continue to do so (unless you think AMD and nVidia will agree to get together and support each other's feature extensions even when it gives the other side an advantage). The virtue of both DX and OGL is that they're not vendor-controlled or hardware-specific (MS may control DX but it's hw-agnostic). Other libraries can provide that abstraction also, but a splintering of development into dozens of graphics libraries might actually be detrimental overall, since it means a lot of reinventing of wheels and folks having to learn new libraries whenever they switch jobs or projects. You want some competition to drive innovation of course, and two dominant standards may be a little low for that, but first-mover and installed base (and mindshare) count for a lot: I doubt either will fade away simply because they work, a lot of people are already comfortable with them, and they continue to get strong support from their backers.

APIs are holding back GPUs, that's why PC games running on GPUs that are like 10x more powerful than the GPUs in console don't look nearly 10x better than console games.

Do you have some basis for this claim? Why would it be the APIs, and not the code that is written to the lowest-common denominator? Not to mention I have no idea how you'd even specify something looking "10x better" than something else. (And of course this entire argument completely misses the point that enjoyable gameplay often has no connection to power of the underlying hardware or the virtue of whatever APIs it might be using)

[Glorious]

The more general purpose GPUs become, graphics APIs will become less relevant, correct? O_O
Like being able to code directly to the GPU using C++. AMD is bringing c++ support with southern islands and Nvidia will bring improved c++ support with Kepler.

Err, the more general purpose GPUs become, the less "GPUs" will be relevant.

If they were fully general purpose, they'd just be CPUs. As codedivine says, GPUs still have plenty of constraints you have to write your code within. This can't really change, because those constraints are actually the reason GPUs can do what they do faster than a CPU can.

What a lot of people, including you, seem to think is that a GPU is magically faster than a CPU, except for a few limitations that GPU-makers are gradually overcoming. This is wrong. GPUs are not are magically faster, and those limitations aren't exceptions to that speed, they're why GPUs have that speed.

APIs are holding back GPUs, that's why PC games running on GPUs that are like 10x more powerful than the GPUs in console don't look nearly 10x better than console games.

This assumes a linear relationship between processing power and the accuracy/verisimilitude of a simulation/representation. That's almost certainly not the case.

I know APIs bring lots of leverage to developers with compatibility across a wide range of platforms and optimizing for one hardware configuration is a no no in PC gaming right now.

It is? Why?

More than a few games have come out with features only usable by one GPU-maker or the other, so why would it be a no-no to try and optimize the code path for one architecture?

What if in the future where all GPUs fully support C++, this would allow a lot more low level access to the hardware for developers and they wouldn't have to worry too much about compatibility issues since all GPUs would support C++.

They'd only have to worry about the whole performance thing...

lol, I realize this will complicate PC game development( hell, learning DX11 ain't easy either) and probably skyrocket development cost but it would bring more sales. There are already tons of graphics libraries for C++. I can't wait until all GPUs fully support C++.

Well, there is no sense in waiting for what won't actually happen.

[chuckula]

What a lot of people, including you, seem to think is that a GPU is magically faster than a CPU, except for a few limitations that GPU-makers are gradually overcoming. This is wrong. GPUs are not are magically faster, and those limitations aren't exceptions to that speed, they're why GPUs have that speed.

That is one of the best summaries of the CPU vs. GPU debate I have ever read.

[just brew it!]

To the OP: You've got it backwards. The reason GPU vendors are incorporating more CPU-like features isn't so that we can eliminate graphics APIs. It is so that GPUs can be used for things which traditionally required CPUs.

Graphics rendering is inherently a highly parallel task. APIs like Direct3D and OpenGL are designed to allow the developer to exploit that parallelism easily for a very specific task (rendering 3D images in real time), by taking full advantage of the many pixel pipelines on a modern GPU.

General-purpose procedural languages like C++ are actually not very good for coding real-time graphics rendering, or parallel applications in general. But there are some types of applications (e.g. scientific/engineering simulations) where you really want the flexibility of a general-purpose programming language, and are willing to put up with the pain of writing multi-threaded code because the potential performance gains make it worthwhile.

[PixelArmy]

Duplicate post.

'It's funny,' says AMD's worldwide developer relations manager of its GPU division, Richard Huddy. 'We often have at least ten times as much horsepower as an Xbox 360 or a PS3 in a high-end graphics card, yet it's very clear that the games don't look ten times as good. To a significant extent, that's because, one way or another, for good reasons and bad - mostly good, DirectX is getting in the way.' Huddy says that one of the most common requests he gets from game developers is: 'Make the API go away.'

[Glorious]

http://www.crn.com/news/components-peri ... j01?pgno=1

Huddy's comments were, by his own statement, "taken out of context and exaggerated."

[just brew it!]

Coding games "direct to the metal" is not practical for PCs, since you would need to re-code the game engine for every different GPU. You could probably do it for consoles, since the hardware environemnt is more predictable; but you'd still be setting yourself up for a world of hurt if you ever want to do a PC port (or even a port to a different console).

By using an API like Direct3D or OpenGL, you make dealing with the hardware differences the GPU vendor's responsibility. All the code that is specific to each GPU is pushed down into the video driver, and only needs to be developed once (by the GPU vendor), instead of hundreds of times (by each game developer).

[Waco]

What a lot of people, including you, seem to think is that a GPU is magically faster than a CPU, except for a few limitations that GPU-makers are gradually overcoming. This is wrong. GPUs are not are magically faster, and those limitations aren't exceptions to that speed, they're why GPUs have that speed.

That is one of the best summaries of the CPU vs. GPU debate I have ever read.

This. I couldn't have summed it up better myself.


OP - writing code for the "bare metal" layer of hardware (a certain GPU, for example) can get you GREAT things...with a very, very specific piece of hardware. Change that hardware and all of your work making it run as fast as possible becomes essentially useless and that work would be grueling and difficult even with an API to make things easier.

[Flatland_Spider]

OpenGL and DX aren't going away. The abstraction the libraries provide is too useful.

Programming directly for the hardware was what game devs used to do in the DOS days before OpenGL. While it would be nice to have to option, loading libraries and calling functions will satisfy most devs who just want their program to work.

[destroy.all.monsters]

I am not a coder but I can't see how not having an API magically makes things better.
If the hardware itself doesn't change - or has a hardware fallback mode - then it might make sense (Amigas had all the multimedia built in so a coder could do this very thing. Also see consoles). But otherwise you have to write everything from scratch each time a new hardware revision comes out (as I understand it). That seems to me an enormous waste of resources.

[r00t61]

Instead of "coding to the metal," I'm surprised that the GPU vendors haven't yet come together to create a GPU Instruction Set Architecture. Name it x86-G or whatever. Then they could get out of the business of having to write graphics drivers, and it would be a matter of developing a good compiler - easier said than done, I know, but in the aggregate I'd think it'd still be less work than having to maintain drivers.

And this thread title needs to be changed. It's not even remotely descriptive or accurate.

[PrecambrianRabbit]

Instead of "coding to the metal," I'm surprised that the GPU vendors haven't yet come together to create a GPU Instruction Set Architecture. Name it x86-G or whatever. Then they could get out of the business of having to write graphics drivers, and it would be a matter of developing a good compiler - easier said than done, I know, but in the aggregate I'd think it'd still be less work than having to maintain drivers.

A graphics driver is basically a JIT compiler. It receives commands in some form of pseudo-assembly language and converts them in real-time to the underlying GPU ISA. The rationale is that the exposed pseudo-assembly language can be more abstract than the native ISA, allowing for good performance across generations of hardware.

[just brew it!]

Instead of "coding to the metal," I'm surprised that the GPU vendors haven't yet come together to create a GPU Instruction Set Architecture. Name it x86-G or whatever. Then they could get out of the business of having to write graphics drivers, and it would be a matter of developing a good compiler - easier said than done, I know, but in the aggregate I'd think it'd still be less work than having to maintain drivers.

A graphics driver is basically a JIT compiler. It receives commands in some form of pseudo-assembly language and converts them in real-time to the underlying GPU ISA. The rationale is that the exposed pseudo-assembly language can be more abstract than the native ISA, allowing for good performance across generations of hardware.

Yeah, I pretty much agree with this. Microsoft and the OpenGL folks have effectively already created GPU instruction sets -- they're called graphics APIs and shader languages. The graphics drivers are effectively the compilers.

I don't think you would ever be able to get the GPU vendors to agree on a single architecture at the hardware level. There's no single "correct" way to do it, and nobody with the market clout of Intel in the x86 space to ram a single proprietary GPU architecture down everyone else's throats.

[End User]

OpenGL is kicking ass in the mobile space (Android/iOS). I don't see that changing in the foreseeable future.

[just brew it!]

OpenGL is kicking ass in the mobile space (Android/iOS). I don't see that changing in the foreseeable future.

It's also kicking ass in the military/avionics space, though this sector is lower volume (and less visible to the general public). That won't change anytime soon either, as most of these systems don't run Windows, and it is rather unlikely that Direct3D would be able to pass FAA civilian avionics safety certifications (or the military equivalents thereof) for critical systems.

[michael_d]

Absence of an API and ability to have direct access to the hardware is a double edged sword. It will give developers more control and they will be able to take full advantage of the hardware's features which will lead to more diverse and unique applications. On the other hand it will elongate development time and raise costs of development. Plus, having more control requires more responsibility applications will have to be polished more than they are now.