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.
Yeah, the R600 apparently has a bug in its fast clear path, and likely
requires software-quad-fillrate-eating workaround for clears...
Funny that your path would be FASTER, though...
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.
I mean: when you render every frame, are all of the pixels refreshed,
or do you keep some region(s) intact from frame to frame?
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.
OK, so it sounds like you'd like to keep regions intact, but are stuck
at refreshing everything because of the bug.
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)
Well, just as a reminder: full-screen blits are still taxing on high-
end cards... You can reach up to a few dozens full-screen overdraws
per frame, but definitely not 100s (not at your resolution and rate,
at least).
[now, from your other reply]
First of all I'm wondering if anyway a copy on swap should be a rather
long operation. I guess that it is. The swap front/back buffer should
be virtually free in this regard.
Not sure what you mean by "virtually free", but let me offer two quick
notes, at the risk of being off-topic:
- I believe page flipping is only possible in fullscreen
- My understanding of how Quartz composes things is that every Mac
window ends up being some sort of implicit copy on swap
The problem with the back/front swap, is that I must operate my
invalidation/
render of the last displayed frame. When back/front are swapped,
what I get,
if the invalidation rectangle were different is not the last frame,
but
the frame before the last frame.
Indeed, your usage of the back buffer seem slightly suboptimal.
Having all this in mind, and avoiding scissor in the back buffer I
can :
have an FBO to do the invalidation render. The FBO would be allocated
to the full screen size, but the rendering would be limited to a
rectangle
starting at 0 and covering the invalidation rectangle.
Once the render is done, the FBO is valid into the invalidation
rectangle.
Then I can emulate a clip operator by giving particular texture
coordinates
that would match only the invalidation rectangle.
Before I draw to the back buffer, I suppose that the back buffer and
front
buffer are identical.
I then copy the portion of the FBO to the back buffer. Using texture
coordinate
this should be fast as it limits the fill rate to just what I need.
Then I swap the back and front buffer
Finally I copy the portion of the FBO in the same way to the old
front buffer
which is now the back buffer. (and back and front buffer are now
identical)
As far as I can imagine, this would be effective as long as the
invalidation
rectangle is not bigger than half of the screen.
Is this what you were thinking of ? Somehow using texture
coordinates to
emulate scissors ?
I wouldn't push my insight so far (I still don't grasp what region you
render and scissor ;-), but you do bring a very interesting idea.
Sounds like you don't even need to use scissoring, and that will save
you (marginally) on the state change.
But I'm not sure assuming/forcing back and front buffers to be
identical is the best avenue.
Here are some alternatives that might work...
For one thing, since you are rendering to a texture, why not always
reuse the same texture as the current destination?
That way, you know you are always working on the previous frame...
Once you are done, simply blit that texture into your back buffer
(fullscreen copy)
The idea here, is that you probably don't even need to clear any FBO
ever:
- Your working texture always needs to keep the previous frame (OK,
the very first time, you likely need to clear it)
- Your back buffer gets all pixels renewed (and would single buffering
work?...)
That said, there might be another option which prevents full-screen
blits completely (might not be possible depending of how your
compositing works, but here it goes, in case it can work):
- Create a double-buffered framebuffer
- Keep track of the last frame updated regions
The idea here is that if you can compute your update regions at time 't
+1' compared to 't', maybe you can compute them at time 't+2' compared
to 't', and 't+3' compare to 't+1', and 't+4' compared to 't+2', and
so on...
Even if you can only get the regions between consecutive frames, just
store them for the previous frame, and you should be able to "this
frame updates these regions, oh, and I need to merge in the previous
frame's regions too".
If such an approach is indeed possible, then I believe you could
theoretically get away with no clears at all, and minimal updates in
place in your current back buffer.
Of course, I'm talking through my hat, here... I'm assuming you can
only blit new regions through rendering rectangles, and I might very
well miss an important detail (I usually do ;-).
Anyways, hope it helps...
And if you want to give me more details on your pipeline, maybe I can
offer you some better help (for one thing, I don't even know if you
need depth for your compositing of not).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
