• Advertisement
Sign in to follow this  

SetStreamSource() twice

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

If I call SetStreamSource() twice and bind the same vb. If the second call just be ignored and cost no CPU ?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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):


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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement