HL2 and driver back-doors :)

[speedy1]

RPS: You chose to not use DX10 for the new games. Why was that?

DS: For this set of products we decided to use some DX10 features, but not through the API itself. It’s because we didn’t want to be Vista only. We didn’t feel there was an enough of an install base for the Orange Box launch. I’m sure we will use it - it’s pretty much inevitable. But this time, things like the hardware face morphing is implemented via a back-door API.

RPS: DX9 can do what DX10 offers then?

DS: Yeah, but through driver-back doors. And I’m sure we’ll rethink it at some point. For this roll out it was fine to do it as we did.


Huh, any guesses what limitation is he back-dooring? (OpenGL user here)

 

[Dave Baumann]

R2VB.

 

[AlNom]

[SIZE=-1]Here[/SIZE]'s a SIGGRAPH 2006 pdf on it.

 

[sreeja]

Does DX9 can only be used?

 

[Fox5]

Ha, that's pretty interesting that they can use pixel shaders to accomplish vertex shader effects. I figured the backdoor would have something to do with the general programmability offered even by dx9 level shaders.
What about it makes it a driver back door though? A driver back door to me sounds like something supported only through vendor specific function calls, not doing something with directx outside of its intended function.

I didn't realize that the orange box did anything new with graphics that wasn't already done in episode 1, unless you count team fortress 2's toon shading.

 

[JHoxley]

What about it makes it a driver back door though? A driver back door to me sounds like something supported only through vendor specific function calls, not doing something with directx outside of its intended function.

Undocumented functionality, or functionality counter to what the documentation states.

It's not uncommon for IHV's to hook into specific values passed from an application via Direct3D to the driver. The FOURCC texture formats are a good example, albeit mostly used as legitimate extensions (e.g. SM formats). I forget the details, but some illegal combinations become legal once the driver picks up on them - ISTR Nvidia's drivers allow this for sampling shadow maps and this falls apart when you run your app with the D3D debug runtimes (which detects them as illegal parameters).

Jack

 

[sebbbi]

PCF, ATI1/ATI2 textures, fetch4, render2vb, etc are all hacks in DX9. To use these features you have to either pass custom data as render state changes (undefined values by the DX9 spec) or use custom fourcc formats to access the texture and render target formats. Normally these values have no meaning by the official DX9 specifications, but if the driver supports the backdoor and doesn't return any error code, these illegal values provide no error (and turn on the feature requested).

 

[Colourless]

PCF, ATI1/ATI2 textures, fetch4, render2vb, etc are all hacks in DX9. To use these features you have to either pass custom data as render state changes (undefined values by the DX9 spec) or use custom fourcc formats to access the texture and render target formats. Normally these values have no meaning by the official DX9 specifications, but if the driver supports the backdoor and doesn't return any error code, these illegal values provide no error (and turn on the feature requested).

Using custom FourCC formats is within spec to add extra format types. It's not a hack in that case. The Debug runtime should allow those.

PCF, fetch4, R2VB and ATIs instancing on SM2.0 cards, are hacks that do things to Direct3D that causes 'undocumented' behaviour.