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.'"

24 of 323 comments (clear)

  1. Yeah right by ggramm · · Score: 5, Interesting

    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.

    1. Re:Yeah right by bmo · · Score: 3, Informative

      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

      Funny, Steam games run just fine.

      --
      BMO

    2. Re:Yeah right by SCPRedMage · · 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.

      --
      My sig can beat up your sig.
    3. Re:Yeah right by Tapewolf · · Score: 3, Interesting

      Amen, mod parent up. Troll? wtf? what shill modded troll?

      Well, I suspect the reason it is considered a troll is because it rewrites history and ignores the facts in order to support its conclusion.
      Stuff like ignoring the thriving DOS games market prior to 1998 or so when Windows finally took over. Brushing OpenGL and SDL under the carpet. I imagine that picking things like nethack and freeciv as a snapshot of linux gaming when you had Wolfenstein 3D, Sauerbraten and various other 3D-accelerated games was what pushed the moderators over the edge. I certainly wouldn't pick Solitaire as an example of what windows gaming looked like, and I loathe Windows.

    4. Re:Yeah right by perpenso · · Score: 4, Informative

      And Mac, much to the delight of the four people who want to play games under OS X.

      Last I heard you are about 5 orders of magnitude off with respect to Mac users playing World of Warcraft. :-)

    5. Re:Yeah right by digitig · · Score: 5, Funny

      0.00004 people?

      --
      Quidnam Latine loqui modo coepi?
    6. Re:Yeah right by CharlyFoxtrot · · Score: 4, 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.

      --
      If all else fails, immortality can always be assured by spectacular error.
    7. Re:Yeah right by CastrTroy · · Score: 5, Interesting

      Yes, things were so much better back in the day when you had to have a very specific graphics card, or audio card, or joystick, otherwise the game wouldn't work. Developers had to code for each piece of hardware individually. If you bought a 3dfx voodoo card, there was a bunch of game you could play, and a bunch you couldn't. If you bought the gravis ultrasound, you were very much out of luck because most stuff was coded for the soundblaster, and a lot of stuff lacked support for your third party sound card. Joystick support was a complete mess. Also, games don't look 10 times as good, because then they could only run on 1% of the machines, and that is not a big enough market. Sure faster computers exist, but the computers that most people own are probably about as powerful as a console, especially if you look at the graphics chip.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    8. Re:Yeah right by drinkypoo · · Score: 3, Informative

      Really? I've been told that the proprietary OpenGL drivers on Linux aren't that good quality, especially AMD's.

      You might use Mozilla's list of Blocklisted Graphics Drivers as your guideline to the reliability of drivers in general at this time since they are currently going through it. They assert (in other sources as well) that only nVidia has a working OpenGL pipeline on Linux.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    9. Re:Yeah right by UnknownSoldier · · Score: 4, Informative

      > Let's do a quick comparison of how stupidly inefficient game development is...
      > 2. Wii/Gamecube - OpenGL,C/C++
      > 3. PS2/PS3 - OpenGL, C/C++

      Your facts are wrong. I've _shipped_ games on Wii, PS2, amongst other consoles. Currently, I do compiler support on the PS3 and am familiar with the rendering APIs that drive the RSX.

      * The Wii does NOT use OpenGL. I personally know because I wrote an OpenGL implementation over _top_ of the native GX calls. While the GX*() API _is_ strongly _based_ on OpenGL, it is NOT OpenGL.

      * The PS2 does NOT have OpenGL. You either
        a) manually build a packet to set the GS registers,
        b) use the sce*() calls, or
        c) write your own API.
      At one job, where I wrote the Wii-OpenGL, we had an in-house implementation of OpenGL running on the PS2, but that was, again, over _top_ of the native GS registers.

      * There are 2 rendering APIs on the PS3. CGM and OpenGL. I could probably count on one hand the total number developers that have shipped their game with OpenGL. Almost no one ships OpenGL it because it is SLOWER and LESS EFFICIENT then CGM.

      Please get your facts straight before looking like an ignorant fool.

      Cheers

    10. Re:Yeah right by hairyfeet · · Score: 3, Interesting

      Can I say something AC? 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.

      People seem to forget we've already been down this road and it was called DOS. Sure games ran crazy fast, and frankly could pull off graphics that you weren't able to imagine the hardware was capable of. The problem was one buggy game could bring it falling down and things like rebooting or even having to yank the power cord to get control of your PC after the game went FUBAR was SOP of the day. Do we REALLY want to go back to that, when games are already so drool worthy on PCs you can spend 30 minutes dying on a new game because you're too busy admiring the purty to play the thing?

      Now for the ragging part: game developers suck I'm sorry but its true, you guys really really REALLY suck. You want us to trust you with bare metal when every damned game that comes out nowadays needs damned near the size of the game in fricking patches because your shit is so buggy? And for every ONE developer that puts out a TRUE PC PORT, you know, one actually designed to take advantage of the PC platform with decent controls and will upgrade and degrade gracefully depending on GPU we have two dozen shitball console ports that frankly all the "bare metal" in the world won't help since your code is designed for a different arch than what it is running on. That would be like the guys at SheepShaver bitching because OS9 doesn't run with native speed and control on Intel OSX. Well duh! One is for a PPC and the other x86!

      So frankly IMHO both you and the AMD guy are so full of shit your eyes are brown. There is not a damned thing wrong with DirectX and these designers that are bitching about "bare metal" are most likely putting out shitty unoptimized console ports and then having the brass balls to bitch because their sloppy code doesn't run fast. Frankly do us both a favor and just don't bother, as I'd rather have no game at all than your shitty unoptimized console twaddle. When my quad core with an HD4850 struggles because of your crap console code it ain't the fault of DirectX, it is your fault for putting out lame console shit without bothering to optimize for the platform. So make the world a better place, either do the job right or don't do it at all. Me and the other PC gamers will thank you for it.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    11. Re:Yeah right by Anthony+Mouse · · Score: 3, 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.

    12. Re:Yeah right by qubezz · · Score: 3, Informative

      Yup, been there. I recently tossed out 'direct to metal' CD versions of Descent, Tomb Raider, Motocross Madness, and many others, that were chipset-specific, made for architectures like the Rendition Vérité, 3dFX Voodoo, S3 Virge, etc. Not because they aren't great games, or because I couldn't run them on a DOS virtual machine or boot to a DOS environment, but because I don't have the video card they were written for, or even a slot to plug one into. However, the majority of Windows DirectX 3 games from ~1996 are install-and-play on even Windows 7. ATI (nee AMD) and NVidia were the graphics chipset makers that rode on DirectX instead of a native hardware API, and are the winners. It's too bad that a cross-platform and cross-vendor platform like OpenGL didn't come out ahead also.

      BTW, I worked for Diamond Multimedia (there's a Diamond card in each Wikipedia reference above) during the graphics good times of six-month upgrade cycles, and got to play with bleeding-edge 3D hardware while the public was still looking at a replica card in a CES glass box.

  2. Unification? by paziek · · 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.

    1. Re:Unification? by smallfries · · 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.

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
    2. Re:Unification? by JackDW · · Score: 3, Interesting

      This is a very good point, the overhead of API calls can be a significant bottleneck.

      I'd suggest that a good solution is to move applications to entirely managed code (e.g. C#), so that there is no need for any hardware-enforced barrier between the kernel and the applications (c.f. Singularity). In the best case, you may end up with a situation in which a JIT compiler inlines parts of the kernel's graphics driver directly into the application code, effectively run-time specialising the application for the available hardware. We already see hints of this happening, for instance the use of LLVM bit code in Apple's OpenGL stack.

      --
      You're an immobile computer, remember?
    3. Re:Unification? by Rockoon · · Score: 3, Interesting

      As for video, why can't you generate that into a texture and draw it as a quad?

      Textures arent any different than frame buffers when you get right down to it. You still need to lock its buffer/etc.

      But in all honesty, the bus is so slow that you never want to write individual pixels over it anyways.... once you have settled on shuttling millions of bytes at a time over the bus for efficiency reasons, then it really doesnt matter what the boiler plate is surrounding that operation is... aggregated over all those pixels the overhead can only be minimal.

      I think AMD's point tho is that something like DirectX enforces the rasterization paradigm when the hardware could be so much more if it wasnt forced to offer good performance for that specific API.

      We are at the point now where the number of computations per second performed by todays GPU hardware should be enough to handle realtime raytracing.. nothing spectacular yet in the secondary ray department.. maybe just a few secondary rays per pixel.. interesting/unique stuff. But the hardware simply doesnt expose the functionality in a way that allows the leveraging of its horsepower in that way effectively, and that could in fact be blamed on DirectX bring the only API that matters. What if the hardware could be designed differently so that fill rate (as an example.. lots of triangles leading to lots of overdraw requires lots of fill rate) wasnt as important?

      --
      "His name was James Damore."
  3. Credit by calzakk · · Score: 3, Insightful

    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.

  4. Hardware needs to change DX is obsolete. by goruka · · Score: 5, Interesting

    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.

    1. Re:Hardware needs to change DX is obsolete. by Zevensoft · · Score: 4, Interesting

      I've programmed DS game engines as well as high performance industrial OpenGL, and the frustrating thing about OpenGL (or DX, they're both just wrappers around NV or AMD) is the inability to send data in the other direction, ie. from the GPU to the CPU without killing performance. The DS didn't have that problem because the vertex processor was decoupled from the pixel processor, and even still you could redirect outputs wherever you like, as well as having full access to the 4 channel DMA controller! We would do occlusion culling on the vertex processor before animation, and also reducing polygon counts for the rasteriser.

    2. Re:Hardware needs to change DX is obsolete. by NewWorldDan · · Score: 3, Interesting

      I suspect one of the reasons for this is that Microsoft has taken the view, in the last 6-7 years, that the GPU can be used for accellerating and enhancing the desktop experiance (Aero, IE9). Their other goal, to a certain extent, is cross platform compatibility. Making it possible to write casual games from Windows, phone, and xbox.

      Disclaimer: I wrote a game way back in 1994, directly interfacing the VGA card. In straight x86 assembly. I was total bare metal 17 years ago. I haven't really kept up on game development much since then. However, I wrote a clone of it in XNA recently. It took me about 4 hours to replicate 9 months of work from 1994. That includes the time to download, install, and learn XNA. My, how things have changed.

  5. Re:Funny, John Carmack thinks just the opposite by bigstrat2003 · · Score: 3, Insightful

    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
  6. Console APIs vs PC APIs - an explanation by LordHavoc · · Score: 5, Interesting

    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
  7. Nothing is optimized fully for DX11/GL4 yet by rasmusneckelmann · · Score: 4, Interesting

    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).