Odd... Our engine uses scissoring on FBOs, and I don't recall any
issues with it.
Then again, we do a fullscreen clear, and turn scissoring after that
to limit the rendering.
That's why I'm not completely sure there is not a bug on my side.
I'll need to make a short snippet to try to track down the problem.
From what I recall, some GPUs can't be full speed on scissored
clears, and driver needs to use the old (and fillrate intensive)
rendering of a clearing quad trick (the ancestor to fast clears).
Actually I've made some sampling today, and I came with rather
weird results. Basically I made a sampling test that would
set an opaque color to a rectangle using either a quad or
clearing bits.
The results are as follow, there are expressed as the maximum
MPx for drawing a frame, drawing 60 frame per seconds :
ATI Radeon HD 2600
quad : 45.5 MPx/frame @ 60fps
clear : 41.8 MPx/frame @ 60fps
So it seems, and as far as my sampling is done correctly, that
the actual method may vary.
What do you use scissoring for, on your side?
I'm making a 2D composition engine. So the scissoring
is here for two things :
- having the possibility to draw with respect to a clip rect
- limit the rendering to a rectangular region into the back
buffer, to ensure that the whole frame is always consistent
(using a copy on swap semantic, invalidation based mechanism)
Do you render some rectangular regions at a different rate?
I'm afraid I don't understand your question.
The rectangular (invalid) regions are rendered in a thread which
is synchronized to the frame rate of the screen (using CV display
links). But I'm not sure I'm really replying to your question here.
If not, you might be able to avoid the issue in another way which
might actually be slightly faster... (maybe...)
Well for now, and because of this bug, rather than drawing to the back
buffer
(using scissor) and using copy on swap, I do the following :
I maintain an FBO that has the role of the back buffer in a copy on swap
semantic. When the render is over, I draw the *whole* FBO to the back
buffer
(since using scissor in the back buffer seems to generate problems) and
after that I swap back and front buffer.
This solution is really not ideal, since I'm consuming the fill rate to
make this big copy. My sampling today told me that for the Intel GMA
950,
at 60 fps, I can make the equivalent of 3.9 copy for a surface
equivalent
to 1280x1024 (17"), so I'm consuming almost a quarter of the whole power
I have to render a frame @ 60fps... and almost a third of the whole
power
@ 75fps...
(while I spotted that problem on the X1600)
What was the technic you were thinking of that may avoid my issue ?
Thanks again a lot,
(I've CCed this reply on Mac OpenGL List, I hope you were OK with it)
Raphael
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
