Richard Huddy talks nonsense again

I read this interview recently. And really… what the heck is he on about? Make the API go away? Only an idiot would make such a request (newbies who haven’t  programmed in the DOS era, and don’t understand what DirectX is for). The API is a hardware abstraction layer. Without hardware abstraction, a developer will have to implement separate code paths for all common hardware. The biggest reason why you wouldn’t want that, is because you will force hardware to become backwards compatible. This brings us back to the lowest-common-denominator culture that we had in the DOS era, with sound cards for example.

Sound cards had to be compatible with a SoundBlaster, since that was the most popular card. You could buy an alternative card, but most games would simply use it as a SoundBlaster, and not use the extra features that your card may offer. This made the hardware more expensive as well, since they had to have a Yamaha synthesizer chip to be compatible with a SoundBlaster (which also generated noise. I always muted my FM chip whenever I didn’t use it, because it was the sole source of hiss. The wavetable synth and DACs had over 90 db SNR, so they were about as quiet as a CD player).

Thanks to DirectX, SoundBlaster compatibility was no longer required, and the quality of sound cards, and the features offered, were greatly improved, now that they were freed of the hardware-level compatibility.

The x86 CPU suffers from the same problem: every new CPU has to support all the previous x86 instructions and modes, no matter how irrelevant they might be to modern software. As a result, every x86 CPU comes with a very complex x86 decoder, which translates the legacy code to an internal format (as I also explained in an earlier blog).

Currently we are at the point where we could FINALLY live without any kind of VGA compatibility on our videocards, so the last bit of legacy crud can finally be removed. And then people want to go back to hardcoding software to the hardware? Bad idea, VERY bad! I especially don’t understand why something like this would come from a hardware manufacturer. Especially GPU designers should realize that the freedom they have in designing their architecture comes from the fact that the hardware will only be used via hardware abstraction layers, and as such, you can completely throw your architecture and instructionset around every few years. For example, although a DX10 card can run DX8 and DX9 code, the architecture is entirely different. A DX10 card has unified shaders which are fully floating-point. The compiler will translate the legacy DX8/9 shaders to floating point unified shaders, without the actual hardware having to support any specific instructions from DX8/9. There is no need for complex decoding and translation hardware to ensure that legacy software will still work. The driver will take care of the translation at the compiling stage.

Sure, it’s not perfect, but neither is the console solution. Although Xbox360 and PS3 may be more efficient than a PC, their hardware cannot be updated. As a result, consoles have a relatively long life, with no hardware developments. With a PC, you don’t have to wait for 5-6 years until a new generation of hardware comes out. Newer, more powerful CPUs and GPUs are released all the time, and you can use them as soon as they are released. New consoles are not even guaranteed to run older console games.

I also don’t understand the complaints about the API inefficiency in general. Microsoft has changed the driver model fundamentally with DirectX 10, to make state management a lot more efficient. In DX10+, you also need to program nearly everything in shaders, where they were available through renderstates/fixed function in DirectX 9 earlier. So DX10+ already feels a lot like writing everything yourself (although unlike eg OpenCL, you can still make use of specific fixedfunction hardware in the pipeline, for maximum efficiency). If anything, these complaints are a few years too late. They apply more to DirectX 9 (and OpenGL) than to DX10+. Although, ironically the DX9 drivers are so optimized that they tend to run better than any other API. Perhaps AMD should spend some more time optimizing their DX10+ drivers first?

This entry was posted in Direct3D, Hardware news, OpenGL, Software development, Software news, Uncategorized. Bookmark the permalink.

10 Responses to Richard Huddy talks nonsense again

  1. I read that interview too and i think it was not Huddy who said the API should go away, but rather developers talking to him. And I take it that they meant, that after initial experience with any API evolution, the restrictions which are imposed for good reasons some of which you explained in your blog post are getting in their way of creatively using all the possibilities of the hardware.

    Actually this sounds quite a bit like console developers who are accustomed to only programming one (or two at most) code paths for their games: Xenos and Cell/RSX. After the first couple of game generations on those two, they direly need to go deeper into the bowels of the hardware in order to tap the potential to the utmost extent.

    • Scali says:

      Well, it was Huddy who brought up the issue in an interview, even though perhaps he was not the originator. If developers would come to me with such requests, I would tell them it’s not going to happen for a number of very good reasons, rather than pushing the topic in interviews on websites.

      If it’s console developers, then they need to educate themselves on the history of the PC platform, and why direct hardware interfacing was replaced with hardware-abstraction APIs. Although I’m not a console developer myself, I learnt programming on home computers such as the C64 and Amiga, where we used the hardware directly as well. My first PC experiences were also with direct interfacing of VGA cards and Sound Blasters. That approach was basically the same as console development today. But I adapted to new developments on the PC platform, and so should they.

      “Creatively using all the possibilities of the hardware” is outdated, as I already tried to explain in my blog. GPUs are designed after the API these days. It has been that way since the DX9 era (which is the generation that the latest consoles belong to). There aren’t any possibilities in the hardware that aren’t covered by the API (with the exception of some GPGPU functionality, but you can access that at a very low level with Cuda or Stream).

  2. v says:

    I disagree. Some of what you are arguing about the down-side of dispatching with the API is speculation. Yes, there were issues of reverse compatibility with DOS, but if we learn from history we know we needn’t go back to doing it the old way simply because we’re proposing a change in how we do things today.

    Yes, with PCs you get more opportunity to update your hardware, but one of the counter-arguments is that these updates do not bring substantial benefits since modern PC conversions do not look substantially different from their console counterparts. As one commentator has already said “A PC console is about ten times as fast as a console, but the games are only slightly better”. A lot of these problems are down to two things: Having to target programs for the kind of PC most people can actually afford, having to account for wildly different PC platforms and limits to DirectX, operating system layering, multi-tasking, switching back and forth through CPU security rings to run the graphic driver and having to rely on controllers that are more apt to word-processors than games. As is said “PC games development and DirectX are no longer a priority”.

    You speak as if you have the answers for us all but it is, after all, game production houses who are the ones objecting to DirectX who also write console games and know what it’s like to write without DirectX, so we’re in a very good position to decide for ourselves how we’d like to continue.

    • Scali says:

      It’s a lot less speculation than you think. We already HAVE an environment with no API on the PC: the x86 processor. This is programmed directly on the hardware. As a result, all PC CPUs have to be compatible with x86, and as such the hardware is more complex than required for a given performance level, and they are more powerhungry than similarly performing CPUs with different, more modern architectures (see my blog here).

      If you do away with the API for GPUs, then you are also freezing the instructionset in time, just like what happened with x86. One of the biggest reasons why GPU technology has evolved so quickly is that the instructionset is not predefined. A DX9 card has a completely different architecture than a DX10 card. At the hardware level, they have ZERO compatibility, they are not even remotely similar. For example, you couldn’t easily have gone from the separate vertex shader and pixel shader models in DX9 hardware to the unified shader model in DX10+ hardware. In DX9, vertex shaders and pixel shaders were physically different processing units, each with their own instructionset.
      The reason why DX10+ hardware with unified shaders can still run DX9 and earlier code is simple: the API abstracted the instructionset. The driver simply translates the different vertex and pixel shader instructions to the same internal unified instructions for the underlying unified architecture.

      Clearly we don’t want to go down the same road with GPUs as with x86, especially since GPU development is still very much in a state of flux.
      The only way that would work is with the console model: only have hardware updates every few years, and little or no backwards compatibility with earlier hardware. But why would you want to turn PCs into consoles? We already have consoles, and PCs currently have their unique advantages. One of them being that new hardware can be developed and released at any time, and be compatible with all earlier software.

      As for the lack of “substantial benefits”… Well, partly it’s diminishing returns. Another part is benefits that people simply ignore, such as the fact that PCs run games (even the straightest of console ports) at higher framerates than consoles, with higher resolutions, better AA, and better texture filtering. It may not be all that ‘substantial’ to most, but if you understand about performance scaling, you’ll know just how much extra processing power you need just to run the same game at higher quality and framerates.

      And even if you were to make the hardware ‘fixed’, like with consoles, you’d probably still need to account for wildly different PC platforms and limits, because there will probably still be multiple manufacturers of GPUs, and multiple price/performance levels for the GPUs, and multiple generations of GPUs in use by the target audience at the same time. Removing the API will make none of that go away, it just makes it much harder to cater for it.

      Likewise, removing the API will not remove all those other thing you mention, such as multithreading, ring switching etc… since they are not part of DirectX, but of the underlying Windows OS itself. Any driver and library will have to be well-behaved on a multitasking desktop system. The only way to avoid it is to make each game contain its own mini-OS and make it self-booting, just like consoles (which is even harder than just programming the GPU directly, since you now also need to support the CPUs, chipsets, game controllers etc yourself).
      It only works on a console because it has fixed hardware. A PC doesn’t, so you can’t treat it as such.

      If you really don’t like the PC model, then just stick to developing for consoles only. Trying to change the PC into a console model doesn’t make sense (especially since the videocards in PCs are used for more than just gaming. It’s silly to try and limit videocards to console-game level only… let gamers use consoles, and let professional users use PC videocards as we know them today. It sounds a lot like tunnel vision on behalf of the console developers).
      It’s a fool’s errand, I can’t make anything else of it.

      And yes, apparently I have a lot more answers than you. I come with facts and argumentations. You come with nothing.

  3. Richard Huddy says:

    In the words of repi “Huddy gets it”. BTW repi is Johann Anderson of DICE, the lead graphics architect on BF3.

    • Scali says:

      Well, I think you misinterpreted what he was trying to say. I think he will agree with the arguments I presented here, for keeping some kind of API (just as I agree with him that having leaner-and-meaner APIs and more low-level control would be a good thing).
      But only Johan Andersson can decide this matter for us. Without his input, it is useless to continue.

  4. Pingback: Richard Huddy comments on my blog | Scali's blog

  5. Pingback: SteamOS and Mantle | Scali's OpenBlog™

  6. Pingback: DirectX 12: A first quick look | Scali's OpenBlog™

  7. Pingback: Dahakon, of: laffe personen die mij denken te kennen | Scali's OpenBlog™

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s