PDA

View Full Version : Quad buffered stereo : how fast is changing draw buffers?



knackered
01-20-2003, 02:19 AM
How quick is it to change draw buffers?
I'm implementing quad buffered stereo in my renderer, and it occurred to me that it might be quicker to change draw buffers and separation transforms per mesh draw rather than per scene render. This would reduce the aggragate state changes I'd need to do....(a particular shader might change states quite a bit between mesh drawing passes).
Or is this a mad idea?
Target Card: Quadro 4

I should benchmark it, I suppose...

Bob
01-20-2003, 03:24 AM
I should benchmark it, I suppose...

Yes, thats the only way to get a usable answer.

knackered
01-20-2003, 03:45 AM
Originally posted by Bob:

Yes, thats the only way to get a usable answer.

Mmm, yes, unless someone's already benchmarked it, in which case it would be quicker to ask...which is what I'm doing.

NVidia care to comment?

Bob
01-20-2003, 03:56 AM
Two important factors is the amount of buffer changes required per frame, and what kind of performance you expect. You haven't mentioned any of them.

knackered
01-20-2003, 04:02 AM
Bob, do you have any idea how to answer my question, or are you just riding my back while you think of what next to do in your own stuff?
It's a simple question: essentially is changing draw buffers free?
If I change the draw buffer every single mesh in a frame, will it impact performance?

Bob
01-20-2003, 04:10 AM
The problem is that you asked a question that does not have a definite answer, and almost requires benchmarking to get a usable answer. You get different result for different situations.

Sorry, I don't have any real answers, but I would guess depending on the amound of state changes needed per shader, it may be faster. Sorry if I my answers above was rude or anything, not my intention. Anyway, I'm off to class now.

knackered
01-20-2003, 05:18 AM
It does have a definite answer. How expensive is a draw buffer swap on the quadro4. Is it free (beyond the api call) or does it involve some kind of hardware stall/flush.
Simple question.
No offense Bob, but I'm puzzled as to why you posted an answer to me when your answer was 'I don't know'. Not only did you not give me an answer, but you also proceeded to cast doubt on the validity of my question - why would you want to do that?

[This message has been edited by knackered (edited 01-20-2003).]

MZ
01-20-2003, 05:24 AM
front, back, left, right buffers share single depth buffer, so switching left/right per mesh shouldn't work.

Bob
01-20-2003, 06:40 AM
If it's not free, and you get an answer it's fast, what does that mean? Knowing that it's fast does not mean it's faster than the other way, and I'm sure that's what you want to know. Whether it's faster or not depends on many things, and does not have a definite answer. A benchmark with a real scene will tell you what's best for that particular scene.

knackered
01-20-2003, 10:05 AM
You're babbling Bob. My question was simple, it's you who is reading too much into it. I didn't ask you to benchmark my application, only to save me the trouble of benchmarking the speed of a draw buffer change on a quadro4.

Mz, are you sure that they share a depth buffer?
If that's true, I needn't clear the depth buffer in my second glClear.... http://www.opengl.org/discussion_boards/ubb/wink.gif

Coriolis
01-20-2003, 10:26 AM
I'm sure that all the front / back / etc buffers share a single depth buffer.

Also, I expect that changing destination buffers would require flushing the pipeline on most hardware, which is a very bad thing to do for performance... but I couldn't be completely sure without profiling. The easy implementation would require the flush, but I can envision an only slightly more complex implementation that wouldn't, and I don't know if the hardware / driver people cared about this case enough to make it fast, since very few people would ever want to constantly switch buffers.

knackered
01-20-2003, 12:28 PM
Cheers, shalln't bother then.