Le 17/07/2012 23:46, chris clepper a écrit :
On Tue, Jul 17, 2012 at 5:09 PM, Jack <jack@rybn.org mailto:jack@rybn.org> wrote:
If you have Gem at 100 fps and you screen at 60 fps, you should encounter a problem of sync at a certain moment, no ? If not, can you explain more ? Maybe the best is when you have Gem fps as a multiple of your screen fps ? Thanx for the rest of explanation. ++The GPU has at least two buffers for drawing to screen. The back buffer is where all of the rendering is done and the front (or display) buffer just gets a copy of the back buffer at a specified interval. The idea is that rendering can take a long time while a copy cant be done quickly (GPU VRAM copies are insanely fast now), so you can take almost all of the render time to draw the frame then swap buffers at the last instant and then go back to rendering.
I initially set the OSX version of GEM to VBL sync to remove the 'tearing' artifacts that horribly plagued other software (Nato advertised it as a feature). I wanted smooth HD video regardless of GEM render rate and used VBL sync and async texturing to do it (this also ended up in the VLC GL rendering code on OSX that I advised on a long time ago).
Using VBL sync will only flip the back buffer to the front at 60 fps. It should be possible to feed GL and the GPU more data than the 60 FPS you need but it might not be displayed. Or maybe the results will be indeterminate? It could be back to the tearing issue if the back buffer is partially filled at swap time.
oh, on linux you can't render faster than the screen. i supposed that it was the same on osX, but i'm may be wrong. if you can render faster than the screen, then the proposed solution will not work, and i have no other solution, and no explanation for the problem. c
I used to know all of the guys who wrote the Mac drivers and made the ATI chips, but we have all gone on to other things, so I can't get a definitive answer right now.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev