Slashdot Mirror
DirectX 'Getting In the Way' of PC Game Graphics, Says AMD
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.'"
I worked for Microprose in the 90's. Back then we had direct access to hardware, but the technology was limited. GFX power increased and new tricks came. Now a days it wouldn't be possible to do all that.
DirectX is the sole reason we have good games and graphics on PC. No one wants to reinvent the whole wheel and Microsoft works a lot with GPU manufacturers to come out with new technology.
DirectX is not the reason, it's the lazy developers who just port the game from consoles to PC. They don't spend the time to make a PC version that uses DirectX and newest graphics cards to their fullest capability, so why on earth they would do that if you remove DirectX.
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.
Microsoft has supported PC gaming to great lengths. We all should thank Microsoft that the situation is even so good. Who we should bitch at are the lazy developers and AMD, who also has been lagging behind. NVIDIA and Microsoft is basically doing all the innovation, and their hardware is miles ahead of AMD's. Microsoft, Intel and NVIDIA. All great companies with great products that are truly working for PC games.
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.
Before Windows 95 and DirectX there was MS-DOS. Let's at least give credit where credit's due; DirectX has had a huge positive influence on Windows and Xbox gaming.
I RTFA and i still didnt understand why the API is bottlenecking, why the draw calls are one third of the draw calls possible on the consoles and why going direct to metal gives you orders of magnitude performance boost after considering both hardwares. Does directX reject the stream processors? or what exactly?
Discaimer: I am a pro game developer, wrote a few engines for commercial games, etc. I know what this guy means and ill try to explain it a bit better. The biggest problem with the DX model (which was inherited from GL) is the high dependency on the CPU to instruct it what to do.
State changes and draw commands are all sent from the CPU, buffered and then processed in the GPU. While this speeds up rendering considerably (the GPU is always a frame ore two behind the CPU) it makes it limiting, to get feedback from the GPU about the rendering state, and since the all the DX/GL commands are buffered, retrieving state or data means flushing/sync.
From modern algorithms related to occlusion estimation, or global illumination to overall reduction of state changes, it would benefit greatly if, for most tasks, the GPU could act by itself by running an user-made kernel that instructs it what to do (commands and state changes) instead of relying on DX, but for some reason this is not the direction GPUs are heading to, and it really doesnt make sense. Maybe Microsoft has something to do with it, but since Directx9 became the standard for game development, the API only became easier to program in versions 10 and 11, but didn't have major changes.
So are they implying that they'd rather develop a game for a very specific set of hardware? Seems like an awful business model to me. Two of the reasons console games look good with lower specs on their hardware is because they are designed solely for gaming, and their specs do not change throughout the life cycle of the device so there is no need to develop for a broad base of hardware types. On the other hand, PC hardware is constantly evolving and multitasking is always going on. Scrap the API and develop directly for hardware, and see what it gets you. A lot of angry customers once they upgrade their card and it doesn't work anymore.
Alright AMD. Make a game for Linux. That will give you the lower level access you want. Impress me :)
The two issues under discussion are different. TFA says that DirectX is holding back PC gaming, while Carmack says DirectX is better than OpenGL. Those two are not mutually exclusive.
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
Console graphics can't really rival PC graphics. Take a look at this comparison of PC vs Xbox vs PS3 in GTA4 [gamespot.com].
I took a look. Totally underwhelmed at the differences. The problem is we have reached diminishing returns in graphics quality per hardware improvement.
I remember the jumps in each generation of PC and console graphics before 2000, and each one was huge and made the earlier generation look dated. When the PS3 and 360 came out, they were clearly better, but they weren't *that* much better. The same goes for today's PC graphics vs the aging consoles.
I don't see this situation changing until realtime ray tracing with realistic looking people (even the best today look like mannequins) comes about. That is, when you can't tell at a glance that you're looking at a game.
That's not true.
If you're going to pretend to be knowledgeable, then it's a good idea to at least read the article.
Carmack's talkng about OpenGL vs DirectX. Arguably... DirectX is now a better API for writing games than OpenGL. I say arguably because I don't think it's a settled question - it is, however, one that is up for discussion - comparing Apples and Apples.
This article though... that's about the model used by both DX and OpenGL. Which basically means the CPU tells the GPU to draw each polygon (ok... it's a little more high level than that.. shaders, VBOs etc but essentially this is correct). On a console, the standard architecture means the developers hit the hardware directly and make their own in essence make their own API that makes the most of the balance of power between the CPU and the GPU.
On the PC - despite the fact that PC GPU hardware (even the cheap stuff) is massively more powerful... the CPU is still making system calls to DirectX very low level commands (effectively) to draw polygons. System calls are expensive and this is seriously limiting the ability of PCs to make use of the humongous power of these GPUs to draw real-time scenes.
The article is calling for a different model from the one used by DX and OpenGL - one that solves this problem. See also: scene graphs.
The way things work on consoles is approximately similar to Windows/Linux/Mac, except for these important distinctions:
1. the hardware is a known target, as such the shader compilers and other components are carefully optimized only for this hardware, they do not produce intermediate bytecode formats or make basic assumptions of all hardware.
2. the APIs allow injecting raw command buffers, which means that you do not have to use the API to deliver geometry in any way shape or form, the overhead goes away but the burden of producing a good command buffer falls on the application when they use these direct-to-hardware API calls.
3. the APIs have much lower overhead as they are not a middle-man on the way to the hardware, but an API implemented (if not designed) specifically for the hardware. For example Microsoft had the legendary Michael Abrash working on their console drivers.
4. the hardware memory layout and access bandwidth is known to the developers, and certain optimization techniques become possible, for example rendering to a framebuffer in system memory for software processing (on Xbox 360 this is done for certain effects, on PS3 it is heavily utilized for deferred shading, motion blur and other techniques that run faster on the Cell SPE units), in some cases this has other special implications, like storage of sound effects in video memory on PS3 because the Cell SPE units have a separate memory path to video memory and thus can tap into this otherwise "unused" bandwidth for their purposes of sound mixing.
5. 3D stereo rendering is basic functionality on consoles.
The article is making the argument that we should be able to produce command buffers directly and insert them into the rendering stream (akin to OpenGL display-lists but new ones produced every frame instead of statically stored).
It is also making the argument that we should have explicit control over where our buffers are stored in memory (for instance rendering to system memory for software analysis techniques, like id Software Megatexture technology, which analyzes each frame which parts of the virtual texture need to be loaded).
There are more subtle aspects, such as knowing the exact hardware capabilities and designing for them, which are less of a "No API!" argument and more of a case of "Please optimize specifically for our cards!", which is a tough sell in the game industry.
AMD has already published much of the information that studios will need to make use of such functionality, for example the Radeon HD 6000 series shader microcode reference manual is public already.
Intel also has a track record of hardware specifications being public.
However NVIDIA is likely to require a non-disclosure agreement with each studio to unlock this kind of functionality, which prevents open discussion of techniques specific to their hardware.
Overall this may give AMD and Intel a substantial edge in the PC hardware market - because open discussion of graphics techniques is the backbone of the game industry.
On the fifth point it is worth noting that NVIDIA Geforce drivers offer stereo rendering in Direct3D but not OpenGL (despite it having a stereo rendering API from the beginning), they reserve this feature only for their Quadro series cards for purely marketing reasons, and this restriction prevents use of stereo rendering in many OpenGL-based indie games, another case of consoles besting PC in functionality for ridiculous reasons.
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
Those of us who are old enough to remember a time before the GUI was the only show in town surely remember that "big" games almost always came with their own boot disk. Would it be so hard to go back to that, if the benefits were worth it? A DVD, or a flash drive, with a small Linux kernel, a library of drivers for the wide range of hardware out there and the game files - optimized for speed, with no loss of performance because a huge, bloated GUIed OS gets in your way. If the game developer uses an off-beat file system, it'll also prevent piracy!
Granted it'll also bring back the bad old days of cursing up a storm because the latest game didn't support your Gravis Ultrasound, but only the crappy SoundBlaster... and off course the game would have to include it's own TCP/IP stack if you want multiplayer... and a few gigs of drivers for the various motherboards, graphics adapters and so on and so forth that the casual gamer may or may not have - but at least you don't have to worry about a system put in place to simplify all that stuff getting in your way.
Everything in the world is controlled by a small, evil group to which, unfortunately, no one you know belongs.
By giving you access to the hardware at the very low level, you give games developers a chance to innovate
I am ready!
MOV DX, 03D4h
MOV AX, 06B00h
OUT DX, AX
Ubuntu is an African word meaning 'I can't configure Debian'
And there's a very good reason behind Carmack's exclusive use of OpenGL for the past decade. When he first tried giving Quake a hardware accelerated video backend, he chose Rendition Verite's proprietary API (google for "vquake"). After VQuake's release, it turned out that Verite cards are horribly broken with no chance of being fixed in the near future so the entire project was a huge waste of time and money. So Carmack made the right decision to give up on proprietary API crap and stick with vendor-neutral open standards. If somebody wants to go down this road again, they'll simply discover all over again that Carmack was right 15 years ago.
Console game developers should realize that once they switch over to PCs, they no longer have the luxury of writing code for single unified combination of hardware. That's why they need some kind of abstract API.
The Cell is a mini vector processor cluster which is not completely unlike graphics cards and was, at the time it was released, more powerful than them.
You had the usual C/C++ toolchain available, and it was a fairly simple architecture to use compared to a GPU (and even compared to an x86 -- SIMD is simpler on the Cell than on x86).
Yet it was a failure, because game developers were completely unable to use it. Game development is a quick and dirty process, and they need to be multi-platform to sell more. There is no time to learn the specifics of a platform and designing your game to exploit it.
That's why they prefer having one API to rule them all (DirectX).
Even within the whole of the Ubisoft studios, there are only a couple of people capable of getting near 80% of the Cell processing power.
I don't think many (if any) game developers are using either OpenGL 4 or DirectX 11 at their full potentials yet. Especially DirectX 11 is designed to allow a lot of multithreading and decoupling the GPU pipeline from the CPU. If you implement a naive rendering engine with OpenGL or DirectX, sure, you'll find that most of the time you're just sitting around waiting for synchronization and buffers flushing. But if you design your software around multithreading and the new API features, you can squeeze a lot more juice out of the system. Also, I'm sure there's a lot of geometry shader pipeline tricks waiting to be discovered, which will further decouple the GPU from the CPU. I wouldn't be surprised if we "soon" see the merging of the vertex and geometry shader pipelines, might even together with compute shaders. When that happens, the differences between OpenGL and DX is propably going to be very minor (and very, very close to the hardware layer).
Graphics are not the problem with games nowadays. Content is, or rather: lack of content. I don't care to be able to count the number of leaves on a tree of seeing or not the shadows of these leaves. I want to be able to interact with the tree. It's the corridor syndrom, I don't care the graphics of a corridor, it's still a corridor and it's only designed to be walked trough. How fun... Tell me why minecraft has so much success ? The funky design of the cubes maybe ?