DirectX 'Getting In the Way' of PC Game Graphics, Says AMD 323
Bit-tech recently spoke with Richard Huddy, worldwide developer relations manager of AMD's GPU division, about the lack of a great disparity between PC game graphics and console game graphics, despite the hardware gap. Quoting:
"'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.'"
Unification? (Score:5, Insightful)
Isn't DirectX and OpenGL there so that developer can write application using DirectX 10 and have it working with any card capable of DirectX and having enough memory? Are we gonna have "Works best in Internet Explorer 6" again for graphic cards? I still remember that whole 3dfx thing and I didn't like it.
Credit (Score:3, Insightful)
Re:Unification? (Score:5, Insightful)
The whole 3dfx era was horrific, and as someone has already pointed out below DirectX made a huge positive impact in PC gaming. The article describes a real problem though: if I want to hit 50fps then my rendering needs to execute in under 20ms. Performing 5k system calls to draw chunks of geometry means that each syscall needs to be less than 4us, or about 12000 cycles on a 3Ghz processor. That is not a lot of time to do all of the internal housekeeping that the API requires and talk to the hardware as well.
The solution is not to throw away the API. The interface does need to change drastically, but not to raw hardware access. More of the geometry management needs to move onto the card and that probably means that devs will need to write in some shader language. It's not really lower-level / rawer access to the hardware. It is more that shader languages are becoming standardised as a compilation target and the API is moving on to this new target.
Re:Yeah right (Score:5, Insightful)
There is no DirectX on Linux and just look at how laughtable the situation is. Yeah theres nethack and some clone of Civilization 2 with worse graphics, but it's far from both console games and PC games that gamers play. It's a joke.
Don't blame the lack of DirectX for the lack of games on Linux. OpenGL works just fine on it, as it does on Windows.
And Mac, much to the delight of the four people who want to play games under OS X.
As far as getting rid of graphics APIs, yeah, that's exactly what we need: to go back in time fifteen years, and make devs write their games for every piece of graphics hardware under the sun. There's a damn good reason the industry started using them, and its still as relevant today as it was back then.
Linux? (Score:2, Insightful)
Alright AMD. Make a game for Linux. That will give you the lower level access you want. Impress me :)
Re:Funny, John Carmack thinks just the opposite (Score:4, Insightful)
Re:Yeah right (Score:2, Insightful)
As someone who has tried and got pissed off multiple times at the API's, yes the API's need to be much thinner.
Let's do a quick comparision of how stupidly inefficient game development is...
1. Xbox/Xbox350 - DirectX,Managed C#
2. Wii/Gamecube - OpenGL,C/C++
3. PS2/PS3 - OpenGL, C/C++
4. PC - DirectX, Managed and Unmanaged C,C++, C#, OpenGL
5. Max - OpenGL, C/C++,ObjC
6. Linux - OpenGL, C/C++
7. Android - OpenGL, Java/Native C/C++ maybe.
8 iOS - OpenGL, C/C++/ObjC
9 Windows Phone 7- DirectX, Managed C#
10, All the other mobile phones and devices- Not DirectX
So the conventional wisdom is that having two different API's (DirectX, and OpenGL) complicates things much as writing libraries in C and C++ .
Both of the API's were written after-the-fact to replace existing proprietary 2D API's where everything was done on the CPU and the graphics card simply acted as a display buffer.
If we were to throw -everything- away and start from scratch, everyone should standardize on a unified C-like base that allows this close to metal application, and instead of having million-line long Make files to determine if the system libraries required are installed during compile, have one unified compiler that can do the compilation of the C-like language into the intermediate language+security/signing to verify it hasn't been altered. Then on the target system, the system compiler will verify the code hasn't been altered, compile and cache it into native binary's that use the hardware close to metal, no intermediate api's, libraries, or other overhead. The entire process would be quick, and as you upgrade your devices, the new system can make better use of new hardware, or the application can run in it's original profile (to avoid the type of problem we have with old software not working when the old shared libraries no longer exist, and the new hardware is too fast.)
Re:Yeah right (Score:5, Insightful)
Don't blame the lack of DirectX for the lack of games on Linux. OpenGL works just fine on it, as it does on Windows.
And Mac, much to the delight of the four people who want to play games under OS X.
Don't forget iOS ! Pretty popular gaming platform these days and it supports OpenGL ES 2.0.
Re:Yeah right (Score:4, Insightful)
As a game developer you can bitch all you want (in fact I'm gonna bitch about you in a minute) but I sure as hell don't trust your coding skills which means letting you have "bare metal access" so you can make my PC as crashy as Win9x is a big DO NOT WANT.
There is a difference between exposing lower level instructions on a GPU to the programmer and doing away with protected mode and virtual memory.