SetStreamSource() twice
Author
If I call SetStreamSource() twice and bind the same vb. If the second call just be ignored and cost no CPU ?
I can't say for certain, but I highly doubt it since it'd be really slow to compare the buffers, if not impossible. May I ask why you would be calling it twice with the same vertexbuffer?
Author
because I let my MODEL class render itself, but it does not know if previous MODEL use the same vb. like this :
mymodel::render ()
{
...
SetStreamSource( this.vb );
...
DrawPrimitive();
}
main ()
{
...
model1.render();
model2.render();
}
I know I can render one vb then another. I just wonder if it is possible. if it is , I will use my current design.if not, then I will change my design.
mymodel::render ()
{
...
SetStreamSource( this.vb );
...
DrawPrimitive();
}
main ()
{
...
model1.render();
model2.render();
}
I know I can render one vb then another. I just wonder if it is possible. if it is , I will use my current design.if not, then I will change my design.
Unless you're rendering a bunch of models, I'd be surprised if rendundantly setting a stream source would be much of a bottleneck.
If it is, a simple abstraction could let you deal with this without the model code needing to know the details (C++-ish code, but this could apply to any language):
This code is horrible for a plethora of reasons, but it demonstrates the basic idea: The model just has a resource that it needs to bind to the hardware. The resource itself knows how to deal with the actual binding, plus any optimization issues involved in doing so.
[Edited by - JasonBlochowiak on June 27, 2006 10:39:51 PM]
If it is, a simple abstraction could let you deal with this without the model code needing to know the details (C++-ish code, but this could apply to any language):
class MyVertexBuffer{public: void Bind(void) { if (currentlyBoundVB != this) { currentlyBoundVB = this; d3dDevice->SetStreamSource(&d3dVertexBuffer); }private: D3DThing &d3dVertexBuffer; static MyVertexBuffer *currentlyBoundVB;};class MyRenderableThing{public: void Render(void) { myVB.Bind(); // Do draw calls here }private: MyVertexBuffer &myVB;};This code is horrible for a plethora of reasons, but it demonstrates the basic idea: The model just has a resource that it needs to bind to the hardware. The resource itself knows how to deal with the actual binding, plus any optimization issues involved in doing so.
[Edited by - JasonBlochowiak on June 27, 2006 10:39:51 PM]
I don't think that these calls are ignored. My reason for thinking so is that there are no debug warning about it (whereas there are about renderstates, sampler states, and texturestage states). The easiest way to find out: just repeat the same call like 100 times and compare the speed against your single call version. Seeing how SetStreamSource() is quite expensive, it could add up pretty fast.
Quote:Original post by circlesoft
I don't think that these calls are ignored. My reason for thinking so is that there are no debug warning about it (whereas there are about renderstates, sampler states, and texturestage states). The easiest way to find out: just repeat the same call like 100 times and compare the speed against your single call version. Seeing how SetStreamSource() is quite expensive, it could add up pretty fast.
Well, that would tell you if it's fast or not on a particular version of a particular driver on a particular machine.
You'd probably be really surprised at how much fudging PC drivers do behind the scenes to cover for suboptimal application programming. Not that I'm recommending that you target suboptimal programming, but considering how many layers of code there are between you and the hardware, it'd be a bit of a shock for this to be a significant overall performance issue for any app that isn't throwing a ton of models at the graphics card.
However, if it is an issue, the solution I provided would take care of it, in a way that the model code could remain oblivious. Encapsulation of optimization related hacks is always preferable.
Author
thank your for the replies. I got some useful information. I never thought about the driver. I think it is reliable to add test code above you gave.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
