Farewell to DirectX?
Despite what delusional forum chimps might tell you, we all know that the graphics hardware inside today's consoles looks like a meek albino gerbil compared with the healthy tiger you can get in a PC. Compare the GeForce GTX 580's count of 512 stream processors with the weedy 48 units found in the Xbox 360's Xenos GPU, not to mention the ageing GeForce 7-series architecture found inside the PS3.
It seems pretty amazing, then, that while PC games often look better than their console equivalents, they still don't beat console graphics into the ground. A part of this is undoubtedly down to the fact that many games are primarily developed for consoles and then ported over to the PC. However, according to AMD, this could potentially change if PC games developers were able to program PC hardware directly at a low-level, rather than having to go through an API, such as DirectX.
The Xbox 360's Xenos GPU has a less then a tenth of the processing power of a top-end PC GPU, so why don't PC games look ten times better?
'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.'
'I certainly hear this in my conversations with games developers,' he says, 'and I guess it was actually the primary appeal of Larrabee to developers – not the hardware, which was hot and slow and unimpressive, but the software – being able to have total control over the machine, which is what the very best games developers want. By giving you access to the hardware at the very low level, you give games developers a chance to innovate, and that's going to put pressure on Microsoft – no doubt at all.'
Of course, there are many definite pros to using a standard 3D API. It's likely that your game will run on a wide range of hardware, and you'll get easy access to the latest shader technologies without having to muck around with scary low-level code. However, the performance overhead of DirectX, particularly on the PC architecture, is apparently becoming a frustrating concern for games developers speaking to AMD.
AMD's head of GPU developer relations, Richard Huddy, says games developers are asking AMD to 'make the API go away'
'Wrapping it up in a software layer gives you safety and security,' says Huddy, 'but it unfortunately tends to rob you of quite a lot of the performance, and most importantly it robs you of the opportunity to innovate.'
Hold on, you might be thinking, weren't shaders supposed to enable developers to be more innovative with their graphics anyway? Indeed they were, and the ability to run programs directly on the graphics hardware certainly enables some flexibility, particularly once we got past the fixed-function shaders of DirectX 8. However, with the exception of a few quirky-looking indie titles, there's no denying that many PC games look very much like one another.
'The funny thing about introducing shaders into games in 2002,' says Huddy, 'was that we expected that to create more visual variety in games, but actually people typically used shaders in the most obvious way. That means that they've used shaders to converge visually, and lots of games have the same kind of look and feel to them these days on the PC. If we drop the API, then people really can render everything they can imagine, not what they can see – and we'll probably see more visual innovation in that kind of situation.'
The DirectX Performance Overhead
So what sort of performance-overhead are we talking about here? Is DirectX really that big a barrier to high-speed PC gaming? This, of course, depends on the nature of the game you're developing.
'It can vary from almost nothing at all to a huge overhead,' says Huddy. 'If you're just rendering a screen full of pixels which are not terribly complicated, then typically a PC will do just as good a job as a console. These days we have so much horsepower on PCs that on high-resolutions you see some pretty extraordinary-looking PC games, but one of the things that you don't see in PC gaming inside the software architecture is the kind of stuff that we see on consoles all the time.
On consoles, you can draw maybe 10,000 or 20,000 chunks of geometry in a frame, and you can do that at 30-60fps. On a PC, you can't typically draw more than 2-3,000 without getting into trouble with performance, and that's quite surprising - the PC can actually show you only a tenth of the performance if you need a separate batch for each draw call.
DirectX supports instancing, meaning that several trees can be drawn as easily as a single tree. However, Huddy says this isn't still enough to compete with the number of draw calls possible on consoles
Now the PC software architecture – DirectX – has been kind of bent into shape to try to accommodate more and more of the batch calls in a sneaky kind of way. There are the multi-threaded display lists, which come up in DirectX 11 – that helps, but unsurprisingly it only gives you a factor of two at the very best, from what we've seen. And we also support instancing, which means that if you're going to draw a crate, you can actually draw ten crates just as fast as far as DirectX is concerned.
But it's still very hard to throw tremendous variety into a PC game. If you want each of your draw calls to be a bit different, then you can't get over about 2-3,000 draw calls typically - and certainly a maximum amount of 5,000. Games developers definitely have a need for that. Console games often use 10-20,000 draw calls per frame, and that's an easier way to let the artist's vision shine through.'
Of course, the ability to program direct-to-metal (directly to the hardware, rather than going through a standardised software API) is a no-brainer when it comes to consoles, particularly when they're nearing the end of their lifespan. When a console is first launched, you'll want an API so that you can develop good-looking and stable games quickly, but it makes sense to go direct-to-metal towards the end of the console's life, when you're looking to squeeze out as much performance as possible.
Programming direct-to-metal would require more in the way of optimising for different GPU architectures, such as Nvidia's GF100 scalar architecture
Consoles also have a major bonus over PCs here, which is their fixed architecture. If you program direct-to-metal on the PlayStation 3's GPU, then you know your code will work on every PS3. The same can't be said on the PC, where we have numerous different GPU architectures from different manufacturers that work in different ways.
For example, developers may ideally need to vectorise their code for it to run optimally on an AMD GPU's stream processor clusters, or maybe tell the GPU's stream processor clusters to split up their units into combinations of vector and scalar units. Conversely, developers will ideally need to program for a scalar architecture on Nvidia GPUs. Once you remove the API software layer, you suddenly have to really start thinking about the differences between GPU architectures.
Problems with Multiple GPU Architectures
Basically, if you're bypassing the API and programming directly-to-metal, then you'll also need to do a fair amount of QA testing and optimisations for different GPU architectures. Isn't this going to make life harder for developers?
'Absolutely, yes, it would,' says Huddy. 'The problem with the PC is that you ideally want a PC that doesn't crash too much, and if a games developer is over-enthusiastic about the way they program direct to the metal, they can produce all sorts of difficulties for us as a hardware company trying to keep the PC stable.
The idea of going direct-to-metal is probably more appealing to cutting edge game developers, rather than indie developers such as Introversion - the company behind Multiwinia
'So there are difficulties there in terms of making sure that the access to the hardware is kind of virtualised, I guess, to make sure that a PC developer can get the same kind of capabilities as a console developer. But in terms of doing the very best for the platform, that's how they would actually achieve that.'
Of course, programming direct-to-metal isn't for every games developer. We mentioned the possibility to Introversion's lead designer and developer Chris Delay, for example, who simply said: 'I don't want anything to do with that, but presumably it depends on what you're developing. If you're making Crysis 3 or something like that, then it may be exactly what you want.'
Indeed, Crytek's R&D technical director, Michael Glueck, said 'yes, that would appeal to us,' when he heard about Huddy's claims. However, he also seemed surprised, pointing out that 'AMD is the biggest force driving the OpenCL standard; it even released drivers to run OpenCL on SSE2 and that's kind of a way to remove low-level hardware access for simple compute tasks.'
Glueck also points out that 'some years ago, all CPU performance critical tasks were done by the programmer, from low-level assembly optimisations to high-level thread and memory management. Now that the "compute world" merges CPUs and GPUs, you waste a lot of time, by using higher level API-layers such as OpenCL, CUDA or Direct Compute, to execute less smart algorithms on GPUs, because they still run faster than on CPUs.
'Having direct access to hardware would mean no drivers magically translating your byte code once again, and also having low-level memory management available, which you have to some degree with CUDA, and also your own thread scheduler would be really enjoyable. It definitely makes sense to have a standardised, vendor-independent API as an abstraction layer over the hardware, but we would also prefer this API to be really thin and allow more low-level access to the hardware. This will not only improve performance, but it will also allow better use of the available hardware features.'
Could Crysis have run more efficiently if Crytek had bypassed Direct3D and programmed direct-to-metal instead?
Either way, Glueck agrees that APIs are likely to become less important to game developers in the future, especially as GPUs start to behave more like general purpose units than fixed function graphics hardware.
APIs are currently 'made to suit a special hardware design,' explains Glueck, 'but as more and more GPUs become general purpose, I doubt there will be more fixed function units added. Even nowadays, rasterisation and tessellation in software on OpenCL can work quite nicely. It won't match the speed of the fixed hardware, but just like alpha-test, perspective interpolation and dedicated vertex- and fragment-units; it will be done by GPGPU units at some point.'
Whether this actually happens remains to be seen, but Huddy certainly seems convinced that the idea of having no API at all is going to put pressure on Microsoft in the future. By getting low-level access to the hardware, games developers could potentially make many more draw calls, and push PCs way ahead of consoles in terms of graphics, which is where they should be, given the hardware we've got. However, this could also come at a cost in terms of stability and compatibility.
Either way, it looks as though DirectX's future as the primary gateway to PC graphics hardware is no longer 100 per cent assured, especially when it comes to cutting edge graphics.
Despite what delusional forum chimps might tell you, we all know that the graphics hardware inside today's consoles looks like a meek albino gerbil compared with the healthy tiger you can get in a PC. Compare the GeForce GTX 580's count of 512 stream processors with the weedy 48 units found in the Xbox 360's Xenos GPU, not to mention the ageing GeForce 7-series architecture found inside the PS3.
It seems pretty amazing, then, that while PC games often look better than their console equivalents, they still don't beat console graphics into the ground. A part of this is undoubtedly down to the fact that many games are primarily developed for consoles and then ported over to the PC. However, according to AMD, this could potentially change if PC games developers were able to program PC hardware directly at a low-level, rather than having to go through an API, such as DirectX.
The Xbox 360's Xenos GPU has a less then a tenth of the processing power of a top-end PC GPU, so why don't PC games look ten times better?
'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.'
'I certainly hear this in my conversations with games developers,' he says, 'and I guess it was actually the primary appeal of Larrabee to developers – not the hardware, which was hot and slow and unimpressive, but the software – being able to have total control over the machine, which is what the very best games developers want. By giving you access to the hardware at the very low level, you give games developers a chance to innovate, and that's going to put pressure on Microsoft – no doubt at all.'
Of course, there are many definite pros to using a standard 3D API. It's likely that your game will run on a wide range of hardware, and you'll get easy access to the latest shader technologies without having to muck around with scary low-level code. However, the performance overhead of DirectX, particularly on the PC architecture, is apparently becoming a frustrating concern for games developers speaking to AMD.
AMD's head of GPU developer relations, Richard Huddy, says games developers are asking AMD to 'make the API go away'
'Wrapping it up in a software layer gives you safety and security,' says Huddy, 'but it unfortunately tends to rob you of quite a lot of the performance, and most importantly it robs you of the opportunity to innovate.'
Hold on, you might be thinking, weren't shaders supposed to enable developers to be more innovative with their graphics anyway? Indeed they were, and the ability to run programs directly on the graphics hardware certainly enables some flexibility, particularly once we got past the fixed-function shaders of DirectX 8. However, with the exception of a few quirky-looking indie titles, there's no denying that many PC games look very much like one another.
'The funny thing about introducing shaders into games in 2002,' says Huddy, 'was that we expected that to create more visual variety in games, but actually people typically used shaders in the most obvious way. That means that they've used shaders to converge visually, and lots of games have the same kind of look and feel to them these days on the PC. If we drop the API, then people really can render everything they can imagine, not what they can see – and we'll probably see more visual innovation in that kind of situation.'
The DirectX Performance Overhead
So what sort of performance-overhead are we talking about here? Is DirectX really that big a barrier to high-speed PC gaming? This, of course, depends on the nature of the game you're developing.
'It can vary from almost nothing at all to a huge overhead,' says Huddy. 'If you're just rendering a screen full of pixels which are not terribly complicated, then typically a PC will do just as good a job as a console. These days we have so much horsepower on PCs that on high-resolutions you see some pretty extraordinary-looking PC games, but one of the things that you don't see in PC gaming inside the software architecture is the kind of stuff that we see on consoles all the time.
On consoles, you can draw maybe 10,000 or 20,000 chunks of geometry in a frame, and you can do that at 30-60fps. On a PC, you can't typically draw more than 2-3,000 without getting into trouble with performance, and that's quite surprising - the PC can actually show you only a tenth of the performance if you need a separate batch for each draw call.
DirectX supports instancing, meaning that several trees can be drawn as easily as a single tree. However, Huddy says this isn't still enough to compete with the number of draw calls possible on consoles
Now the PC software architecture – DirectX – has been kind of bent into shape to try to accommodate more and more of the batch calls in a sneaky kind of way. There are the multi-threaded display lists, which come up in DirectX 11 – that helps, but unsurprisingly it only gives you a factor of two at the very best, from what we've seen. And we also support instancing, which means that if you're going to draw a crate, you can actually draw ten crates just as fast as far as DirectX is concerned.
But it's still very hard to throw tremendous variety into a PC game. If you want each of your draw calls to be a bit different, then you can't get over about 2-3,000 draw calls typically - and certainly a maximum amount of 5,000. Games developers definitely have a need for that. Console games often use 10-20,000 draw calls per frame, and that's an easier way to let the artist's vision shine through.'
Of course, the ability to program direct-to-metal (directly to the hardware, rather than going through a standardised software API) is a no-brainer when it comes to consoles, particularly when they're nearing the end of their lifespan. When a console is first launched, you'll want an API so that you can develop good-looking and stable games quickly, but it makes sense to go direct-to-metal towards the end of the console's life, when you're looking to squeeze out as much performance as possible.
Programming direct-to-metal would require more in the way of optimising for different GPU architectures, such as Nvidia's GF100 scalar architecture
Consoles also have a major bonus over PCs here, which is their fixed architecture. If you program direct-to-metal on the PlayStation 3's GPU, then you know your code will work on every PS3. The same can't be said on the PC, where we have numerous different GPU architectures from different manufacturers that work in different ways.
For example, developers may ideally need to vectorise their code for it to run optimally on an AMD GPU's stream processor clusters, or maybe tell the GPU's stream processor clusters to split up their units into combinations of vector and scalar units. Conversely, developers will ideally need to program for a scalar architecture on Nvidia GPUs. Once you remove the API software layer, you suddenly have to really start thinking about the differences between GPU architectures.
Problems with Multiple GPU Architectures
Basically, if you're bypassing the API and programming directly-to-metal, then you'll also need to do a fair amount of QA testing and optimisations for different GPU architectures. Isn't this going to make life harder for developers?
'Absolutely, yes, it would,' says Huddy. 'The problem with the PC is that you ideally want a PC that doesn't crash too much, and if a games developer is over-enthusiastic about the way they program direct to the metal, they can produce all sorts of difficulties for us as a hardware company trying to keep the PC stable.
The idea of going direct-to-metal is probably more appealing to cutting edge game developers, rather than indie developers such as Introversion - the company behind Multiwinia
'So there are difficulties there in terms of making sure that the access to the hardware is kind of virtualised, I guess, to make sure that a PC developer can get the same kind of capabilities as a console developer. But in terms of doing the very best for the platform, that's how they would actually achieve that.'
Of course, programming direct-to-metal isn't for every games developer. We mentioned the possibility to Introversion's lead designer and developer Chris Delay, for example, who simply said: 'I don't want anything to do with that, but presumably it depends on what you're developing. If you're making Crysis 3 or something like that, then it may be exactly what you want.'
Indeed, Crytek's R&D technical director, Michael Glueck, said 'yes, that would appeal to us,' when he heard about Huddy's claims. However, he also seemed surprised, pointing out that 'AMD is the biggest force driving the OpenCL standard; it even released drivers to run OpenCL on SSE2 and that's kind of a way to remove low-level hardware access for simple compute tasks.'
Glueck also points out that 'some years ago, all CPU performance critical tasks were done by the programmer, from low-level assembly optimisations to high-level thread and memory management. Now that the "compute world" merges CPUs and GPUs, you waste a lot of time, by using higher level API-layers such as OpenCL, CUDA or Direct Compute, to execute less smart algorithms on GPUs, because they still run faster than on CPUs.
'Having direct access to hardware would mean no drivers magically translating your byte code once again, and also having low-level memory management available, which you have to some degree with CUDA, and also your own thread scheduler would be really enjoyable. It definitely makes sense to have a standardised, vendor-independent API as an abstraction layer over the hardware, but we would also prefer this API to be really thin and allow more low-level access to the hardware. This will not only improve performance, but it will also allow better use of the available hardware features.'
Could Crysis have run more efficiently if Crytek had bypassed Direct3D and programmed direct-to-metal instead?
Either way, Glueck agrees that APIs are likely to become less important to game developers in the future, especially as GPUs start to behave more like general purpose units than fixed function graphics hardware.
APIs are currently 'made to suit a special hardware design,' explains Glueck, 'but as more and more GPUs become general purpose, I doubt there will be more fixed function units added. Even nowadays, rasterisation and tessellation in software on OpenCL can work quite nicely. It won't match the speed of the fixed hardware, but just like alpha-test, perspective interpolation and dedicated vertex- and fragment-units; it will be done by GPGPU units at some point.'
Whether this actually happens remains to be seen, but Huddy certainly seems convinced that the idea of having no API at all is going to put pressure on Microsoft in the future. By getting low-level access to the hardware, games developers could potentially make many more draw calls, and push PCs way ahead of consoles in terms of graphics, which is where they should be, given the hardware we've got. However, this could also come at a cost in terms of stability and compatibility.
Either way, it looks as though DirectX's future as the primary gateway to PC graphics hardware is no longer 100 per cent assured, especially when it comes to cutting edge graphics.
Last edited:
