Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
AMD Graphics PC Games (Games) Games

DirectX 'Getting In the Way' of PC Game Graphics, Says AMD 323

Posted by Soulskill from the stairs-in-the-way-of-getting-to-the-basement dept.
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.'"
This discussion has been archived. No new comments can be posted.

DirectX 'Getting In the Way' of PC Game Graphics, Says AMD More

DirectX 'Getting In the Way' of PC Game Graphics, Says AMD

Comments Filter:

  • Yeah right (Score:5, Interesting)

    by ggramm ( 2021034 ) on Saturday March 19, 2011 @07:02AM (#35541046)
    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.

    • Re: (Score:3, Informative)

      by bmo ( 77928 )

      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

    • Re: (Score:2)

      by Whiteox ( 919863 )

      You are right. But don't forget that DOS was just an OS and it was the exe file, often assembly coded with huge tables for graphics, collision detectors etc that did all the work.

    • Re:Yeah right (Score:5, Insightful)

      by SCPRedMage ( 838040 ) on Saturday March 19, 2011 @07:19AM (#35541110)

      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.

      • Re:Yeah right (Score:5, Informative)

        by perpenso ( 1613749 ) on Saturday March 19, 2011 @08:57AM (#35541450)

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

      • Re:Yeah right (Score:5, Insightful)

        by CharlyFoxtrot ( 1607527 ) on Saturday March 19, 2011 @09:41AM (#35541608)

        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: (Score:2)

        by tepples ( 727027 )

        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.

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

        • Re:Yeah right (Score:4, Informative)

          by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Saturday March 19, 2011 @11:01AM (#35542028) Homepage Journal

          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 [mozilla.org] 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.

        • Re: (Score:2, Informative)

          by Anonymous Coward

          The NVidia one is feature complete with the windows one. Runs beautifully. only thing it doesn't have is hybrid SLI/ Optimus. and that could be possibly fixed when wayland comes out.

          NVvidia has been putting alot of love into linux even if it is tough love like not giving us open source drivers or following standards like KMS.

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

        I completely agree! I have World of Goo, Braid, Osmos, Penumbra, Nexuiz/Xonotic, NetHack (of course), Scorched 3D, Battle for Wesnoth (get it, it's awesome), emulators for pretty much every console on the planet except the really powerful ones, and also a ton of games in Wine (Civilization IV with no DRM, pretty much every one of Telltale's adventure games, Baldur's Gate, Psychonauts, Portal/HL2) and they all work perfectly (in fact, sometimes better than on my Windows XP partition). OpenGL is more than wha

      • Re:Yeah right (Score:4, Informative)

        by qubezz ( 520511 ) on Saturday March 19, 2011 @06:05PM (#35544604)

        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é [wikipedia.org], 3dFX Voodoo [wikipedia.org], S3 Virge [wikipedia.org], 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.

    • Re: (Score:2)

      by Dunbal ( 464142 ) *

      Microprose was an awesome company and I had all of their games from Silent Service up to and including Falcon 4.0. It's too bad that the company got swallowed whole and recycled so many times.

      I agree that developer laziness is behind many development problems and it's not just limited to DirectX. Look at that steaming pile of horseshit called Bink, which was very popular at one point despite being a festering abscess of sloppy code. Look at some current (cough Miles cough) sound drivers that cause popular

      • I agree with some of your points but disagree with a few:

        MS was largely successful with DirectX, and the goal of allowing developers to largely ignore the graphics hardware while concentrating on a standard API was successful. For ill or good, it's driven game design on the dominant platform for years, and arguably kept OpenGL on the defensive.
        MS may provider driver support with their OS because it is to their benefit to have out of the box support, but they have never been best in driver support. They leav

        • I think a large part of the lack of perceived difference between consoles and PC's these days have a bit to do with the least common denominator, which unfortunately also happens to be an aging dedicated gaming console

          As I understand it, the lowest common denominator console for "grown-up" consoles (Xbox 360) is far more powerful graphically than the lowest common denominator PC (any PC with integrated video). Half a GB of RAM and an AMD Radeon X1900 beat 2 GB of RAM and an Intel "Graphics My Ass".

      • Re: (Score:3)

        by drsmithy ( 35869 )

        Microsoft failed to deliver - suddenly when the OS was shipped, it was no longer a priority to keep drivers up to date - this now became the responsibility of the hardware OEM.

        It's always been the responsibility of the hardware OEM. Outside of the Linux world, OSes have stable kernel ABIs that allow hardware vendors to write drivers without having to worry about next week's minor kernel patch breaking them.

        Do not project the unusual and disadvantageous situation with Linux onto every other platform.

    • Am I the only one who remembers the demo scene? Pure DOS. No DirectX.

      Stars, Wonders of the World (1995) [youtube.com] - (Contains brief cartoon nudity near start).

      • Addendum, for those too pressed for time to watch the entire 6:20 demo, the intro finishes at 1:11. Highlights include the face-through-the-wall at 3:13 and the hula-hoop scene at 4:35.

      • Re: (Score:3)

        by jedrek ( 79264 )

        I remember the demo scene. I remember having to use QEMM to get enough ram for the demos to run, then having them crash. I remember some demos working on my gfx card and not my friends', I remember having drivers for specific sound cards, etc.

        • Re: (Score:2)

          by sosume ( 680416 )

          No AI. Color cycling. Fractals. What you saw in the demo scene in the eighties, is now available as a visualisation plugin for Media player or Winamp. it looked impressive back then, but it were mere hacks pushing the metal to its fullest. Still they all used the same similar tricks. I watched a few of those again some time ago and was not impressed anymore.

    • Re:Yeah right (Score:5, Interesting)

      by CastrTroy ( 595695 ) on Saturday March 19, 2011 @10:07AM (#35541750)
      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.

  • Unification? (Score:5, Insightful)

    by paziek ( 1329929 ) on Saturday March 19, 2011 @07:09AM (#35541070)

    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.

    • Re:Unification? (Score:5, Insightful)

      by smallfries ( 601545 ) on Saturday March 19, 2011 @07:18AM (#35541106) Homepage

      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.

      • Mod parent +1 Has a Fucking Clue.

      • Re:Unification? (Score:4, Interesting)

        by JackDW ( 904211 ) on Saturday March 19, 2011 @07:44AM (#35541192) Homepage

        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 [microsoft.com]). 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 [wikipedia.org].

        • 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

          Superb idea! Why do something quickly in hardware, when you can do it slowly in software?

          We already see hints of this happening, for instance the use of LLVM bit code in Apple's OpenGL stack

          You realise that Apple only uses LLVM in the painfully slow case (i.e. when it has to execute shaders on the CPU, rather than the GPU), right? And that shaders are already JIT compiled for the target hardware on all OpenGL / Direct3D implementations? And that JIT compilation doesn't require managed code, nor does it require a VM?

          • Re: (Score:2)

            by JackDW ( 904211 )

            Superb idea! Why do something quickly in hardware, when you can do it slowly in software?

            I don't think you understand what I am getting at. I am not saying that memory protection and privilege levels should be enforced by software - that is not what Singularity does. The whole point of managed code is that memory protection does not need to be enforced at all. The result is that you can run everything in ring 0, in the same memory space. No matter how fast your hardware already is, removing these overheads makes it faster.

            • The whole point of managed code is that memory protection does not need to be enforced at all. The result is that you can run everything in ring 0, in the same memory space.

              Yes, I understand, I've read the papers related to Singularity, and it remains a stupid idea. You're replacing a mechanism that the CPU can do in hardware, basically for free, with a software implementation. By running everything in ring 0, you make any VM bug into a a kernel-level hole. Still think this is a good idea? Pick your favourite VM from the JVM, Flash VM, and .NET VM. Now go and look at the number of exploitable bugs that have allowed code to break free of the sandboxing. For the JVM, the

              • Re: (Score:2)

                by JackDW ( 904211 )

                Thanks for clarifying.

                The argument here is not about security, but performance. The possibility of being able to "optimise out" an entire API, even across the system call barrier, is (I think) an interesting one, and that's what I was commenting on.

                The thing is that hardware security does not actually come for free - there is a time cost, and the implication of the article we're commenting on here is that the time cost is significant.

                You are of course right that VMs have not always been particularly secu

              • Re: (Score:3)

                by drsmithy ( 35869 )

                When someone says 'we can improve security by adding this layer of complexity,' what they mean is 'I am an idiot, disregard everything that I say.'

                I think your brush might be a little broad, there. File permissions (even simple UNIX ones) are an additional layer of complexity, but clearly improve security. Similarly for privilege escalation facilities like sudo or UAC. A firewall (or even /etc/hosts.[allow|deny]) is more complexity, but also delivers clear security benefits. Etc.

        • It's a shame that you are being lambasted by posters who didn't understand your point. Yes - lifting the code to a higher level of abstraction would definitely enable specialisation. Managed code is one way to go, certification would be another. In either case eliminating direct memory access, or proving that it is safe woud allow the removal of the barrier between hardware access and user-land code. That is precisely what is needed in this case.

      • Since you seem knowledgeable:

        How is this handled on the consoles? Do the programmers go direct to the hardware, as they did in the days of the N64 and PS1, or do the modern PowerPC-based consoles also have a DirectX-style interface?

        • Re: (Score:2)

          by tepples ( 727027 )

          The Xbox 360 is most often* programmed in C# using the XNA API, which is very much a managed counterpart to DirectX.

          * I can explain what I mean by this.

      • Re: (Score:2)

        by Twinbee ( 767046 )

        I just wish they gave us an easier way to access the gfx card's pixel buffer - you know what ultimately comes out on the monitor. It's ridiculous the amount of code that's needed to write a simple pixel to a screen or window, especially if animation/video is involved.

        • Only pirates want that kind of direct access these days if you believe the FUD.

        • Re: (Score:2)

          by tepples ( 727027 )
          They did. It was called DirectDraw. But if your game is running in a window, direct access to the frame buffer can violate the user's privacy. Microsoft deprecated DirectDraw in favor of Direct3D and later Direct2D because even an Intel GMA is substantially faster than software rendering. As for video, why can't you generate that into a texture and draw it as a quad?

          • Re:Unification? (Score:4, Interesting)

            by Rockoon ( 1252108 ) on Saturday March 19, 2011 @11:04AM (#35542058)

            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?

            • We're not quite there yet, but you are right that it should be close. Take a GTX-580 for example. It can sustain 800GFlops on certain code sequences. If we assume that real-time means 50fps and 1080p is the target resolution then if we could average out the workload we'd hit 8000Flops per pixel per frame. That's certainly enough to do something interesting.

              Sadly it doesn't work like that. We hit that huge performance number on a SIMD array with a really deep pipeline and partially manual cache management. A

  • Credit (Score:3, Insightful)

    by calzakk ( 1455889 ) on Saturday March 19, 2011 @07:11AM (#35541080) Journal
    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.

    • Aw come on, the DOS4GW era was great!

    • But isn't asking to have "more direct, low level access" to the hardware EXACTLY like asking for the DOS days again, in a way? That was the first thing I thought. In reality, it would allow for faster game experience and better utilization of the hardware. Of course, this makes programming games a freaking nightmare as there are a million possible combinations, which would mean fewer games in that mode.

      I always thought a "dedicated game mode" for the OS would be interesting, where all other services are

    • You're ignoring the fact that we already had OpenGL and that it had been in development and use for many, many years before MS decided to fragment the market. The real question is whether or not it's better than what was the status quo of OpenGL prior to all those stupid specialized APIs for the various graphics accelerators.

  • 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?

  • Hardware needs to change DX is obsolete. (Score:5, Interesting)

    by goruka ( 1721094 ) on Saturday March 19, 2011 @07:31AM (#35541158)
    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.

    • Re: (Score:2)

      by Twinbee ( 767046 )

      I'm not so sure that it's not the direction GPUs are heading. For example, NVidia's future Maxwell chip that combines a CPU and GPU into one will have true multitasking, and maybe take the pressure off the CPU completely. Perhaps AMD's Fusion already supports that kind of thing? You're right though, it would be great to have DMA to the GPU.

    • Re:Hardware needs to change DX is obsolete. (Score:4, Interesting)

      by Zevensoft ( 1784070 ) on Saturday March 19, 2011 @09:35AM (#35541584)
      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.

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

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

      It makes perfect sense if you are trying to sell new generations of GPUs and have code which targeted the old generation of GPUs work on the new one. You're asking them to create a situation which continually breaks backwards compatibility or which requires them to go to great lengths to emulate old hardware to preserve it, which will necessitate added silicon. For a games console it makes sense to give you that kind of access to the hardware but only insofar as it does not make development more complicated

  • 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 de

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Nope. Right now the GPU-CPU situation looks like my boss dictating an email to his secretary - it probably wouldn't take as long if he just told her to inform the recipient he's going to be late. The developers want all possible API ops moved to the GPU where the CPU doesn't get in the way. They still want a standard API and most certainly don't want to develop straight for the metal.

  • Linux? (Score:2, Insightful)

    by Anonymous Coward

    Alright AMD. Make a game for Linux. That will give you the lower level access you want. Impress me :)

  • Console APIs vs PC APIs - an explanation (Score:5, Interesting)

    by LordHavoc ( 1394093 ) * on Saturday March 19, 2011 @09:01AM (#35541474) Homepage

    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.

  • Easy workaround (Score:3)

    by WegianWarrior ( 649800 ) on Saturday March 19, 2011 @10:16AM (#35541794) Journal

    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.

  • 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

  • 'Oh hey! Let's start coding the graphics engines for our multi-million dollar games in a basic low-level chip-specific language! That'll let us squeeze the most out of that 5 year old GPU we have to use!'

  • That's what the Cell was, didn't work (Score:3)

    by loufoque ( 1400831 ) on Saturday March 19, 2011 @11:48AM (#35542252)

    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.

  • APIs exist for a reason. They abstract out reusable functionality, which frees developers from the need to reinvent the wheel and/or maintain separate code for different types of hardware. There's always some cost in performance, but a well-designed API should minimize that cost. Take DirectX and OpenGL out of the equation and you'd see fewer games developed at a higher cost-per-game.

  • Nothing is optimized fully for DX11/GL4 yet (Score:4, Interesting)

    by rasmusneckelmann ( 840111 ) on Saturday March 19, 2011 @02:28PM (#35543240)
    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).

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close