# D3D9 vs D3D10: Constant buffers

This topic is 3411 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

##### Share on other sites
You should do it in your interfaces like D3D10 does it. And emulate constant buffer functionality on D3D9.

##### Share on other sites
Personally (but that's D3D11 and OGL, don't remember how it worked in D3D9) I keep the data "locally" in the constant buffer (that is, in a buffer that doesn't have anything to do with the GPU) and flag the buffer as dirty.

Then when I start using a technique, I check which buffers are needed and if they're dirty, "reload" them (that is, rewrite all the data).

Anyway if you target D3D9 and 10 (and nothing else), wouldn't it be simpler to just use the fx files support provided by D3DX9 and D3D10?

##### Share on other sites
You just mimick D3D10 behavior in D3D9, it's trivial.

##### Share on other sites
I think you're approaching the problem in a fundamentally wrong way, actually :)

Rather than write a thin, rather brittle wrapper around a rendering API, go for the proverbial jugular and do things at a *really* high level, i.e. have a RenderScene functionality that takes a custom container with all the objects you want to draw. This solves several problems very elegantly:

-Since you're dynamically loading your renderer, you avoid the overhead associated with calling functions in an external library. (similar to lots of virtual function calls; by itself it isn't too bad, but if you call it thousands of times per frame it has an impact)

-Semantic problems like the one you're describing vanish. If you make a few classes for materials, geometry containers and bone transforms, the renderer itself can decide what do do with them.

-Rendering approaches are no longer a problem. Want to make a deferred renderer? Easy! Just goof with your renderer class to output g-buffers and do the required postprocessing. No app-side changes required!

-Culling is automatically abstracted away. You can just build a visible set in your update function, put that list in the container, ship it off and forget about it. Some more advanced stuff, like occlusion culling, could conceivably be done inside the renderer; that being said a simple boolean value or flag could be set to enable/disable this feature.

-Fixes/debugging are much simpler, too. You don't have to track down every single instance of a renderer call in order to update it. Everything you need is (metaphorically) right there in front of you.

So, granted, resource management can be a bit more involved, (i.e. how do we tell our renderer where to look for geometry/texture info, etc.) but with some creative thinking it's not much more difficult. Again, abstraction is key, and calling a CreateResource()-esque function that returns an index into an internal array is pretty simple to integrate.

##### Share on other sites
Rewdew's approach seems quite reasonable to me.

Also, have a look at the FX9/FX10 API's as they don't explicitly mention registers (D3D9) or constand buffers (D3D10) and are quite intuitive from a coding perspective.

It should be fairly trivial to implement the common interface that allows access to individual parameters/types, and to set them on the device should be reasonably straight forward as well.

D3D9
foreach(constant in _constants)   switch(type)      case FLOAT: device.SetFloatConstant(constant)      case INT: device.SetIntConstant(constant)      ...

D3D10
struct cbuffer { float fVal; int iVal; };cbuffer cb = { your_float, your_int };Buffer.Map();memcpy(buffer, cb)Buffer.UnMap();Device.??SetConstants(cb)

Just remember that D3D9 can be quite performance-sensitive to this sort of operation, so a naive/trivial implementation like my one above may work fine for D3D10 but suck for D3D9. Be sure to profile it.

hth
Jack

##### Share on other sites
For DX9 it’s better to write all constants to a memory block and then set them with a single call instead of using multiple calls. The reason for this is quite simple. There is a constant overhead per SetConstant call and an additional overhead depending on the amount of constants.

While the reducing the draw calls rule is well know there is a second one that tolds you to use as less other Direct3D calls per draw call as possible.

While Direct3D 10 is not that critical on the CPU side you need to be very carefully with the size of a constant buffer. Using large general buffers that contains many elements that are not used by a shader can easily kill your performances. There is some kind of constant buffer transfer limit that can easily become your bottleneck.

1. 1
Rutin
25
2. 2
3. 3
4. 4
JoeJ
18
5. 5

• 14
• 14
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631757
• Total Posts
3002131
×