Hi, me and a friend of mine do a lot of live audio-video performance, professionally, all using pd/gem as an environment. We both use Macbook Pros (different models), and for the last couple of years we've been having a serious problem which we now suspect is something to do with GEM/PD, rather than, for example, the graphics cards or drivers.
The problem occurs when running at higher frame rates - it is highly preferable for us to run at 60 frames per second, because (1) it syncs with the refresh rates of most projectors and seems to produce much smoother/more regular movement, and (2) often we are using very precise, high frequency flashing, for optical effects, that we need to be able to sync exactly with screen refreshes. We are generally running the gem window in a second screen (such as a monitor or projector), but it happens when running on one screen too.
As soon as we run at 60 frames per second (or near it), glitching starts to occur frequently in the audio, and the audio goes out of sync with GEM. While the glitching is occurring, processes in PD and GEM jerk along, pausing frequently. To resolve it (temporarily), the audio has to be reset in PD (by reselecting the audio device). The glitching then goes away and everything runs smoothly, but it returns spontaneously after a short time. The glitching is also exacerbated by moving windows around on the screen. It might be worth noting that the same patch running on the very same machine in Windows XP (using bootcamp) does not have this problem.
We have different GPUs, mine is a Nvidia 9600m GT, and his was an ATI of some sort. We are using very simple, geometric graphics, and are not approaching the processing limits of the GPUs at all (if I do push the graphics card very hard, I notice that frames are skipped rather than glitching occurring). I also note that it happens equally when there is low CPU activity, so it's not related to that.
My friend has just purchased a new Macbook Pro, yesterday with a 60% more powerful Nvidia GPU, and unfortunately the glitching is still occurring. It occurs in OS X Lion, and also was happening in Snow Leopard. We've tried disabling power management on the GPU, and this doesn't help either.
I've looked through the gem code in an attempt to try and understand what is happening, but I am afraid it is beyond me!
Does anyone have any idea at all what the problem could be? It would make such a huge difference to us if we could resolve it. Thanks very much for any help in advance (and for developing GEM in the first place)
All the best, Theo
Le 16/07/2012 19:31, Theo Burt a écrit :
Hi, me and a friend of mine do a lot of live audio-video performance, professionally, all using pd/gem as an environment. We both use Macbook Pros (different models), and for the last couple of years we've been having a serious problem which we now suspect is something to do with GEM/PD, rather than, for example, the graphics cards or drivers.
The problem occurs when running at higher frame rates - it is highly preferable for us to run at 60 frames per second, because (1) it syncs with the refresh rates of most projectors and seems to produce much smoother/more regular movement, and (2) often we are using very precise, high frequency flashing, for optical effects, that we need to be able to sync exactly with screen refreshes. We are generally running the gem window in a second screen (such as a monitor or projector), but it happens when running on one screen too.
As soon as we run at 60 frames per second (or near it), glitching starts to occur frequently in the audio, and the audio goes out of sync with GEM. While the glitching is occurring, processes in PD and GEM jerk along, pausing frequently. To resolve it (temporarily), the audio has to be reset in PD (by reselecting the audio device). The glitching then goes away and everything runs smoothly, but it returns spontaneously after a short time. The glitching is also exacerbated by moving windows around on the screen. It might be worth noting that the same patch running on the very same machine in Windows XP (using bootcamp) does not have this problem.
We have different GPUs, mine is a Nvidia 9600m GT, and his was an ATI of some sort. We are using very simple, geometric graphics, and are not approaching the processing limits of the GPUs at all (if I do push the graphics card very hard, I notice that frames are skipped rather than glitching occurring). I also note that it happens equally when there is low CPU activity, so it's not related to that.
My friend has just purchased a new Macbook Pro, yesterday with a 60% more powerful Nvidia GPU, and unfortunately the glitching is still occurring. It occurs in OS X Lion, and also was happening in Snow Leopard. We've tried disabling power management on the GPU, and this doesn't help either.
I've looked through the gem code in an attempt to try and understand what is happening, but I am afraid it is beyond me!
Does anyone have any idea at all what the problem could be? It would make such a huge difference to us if we could resolve it. Thanks very much for any help in advance (and for developing GEM in the first place)
All the best, Theo
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hello,
Can you provide a small exemple patch with this trouble ? When you use Gem and sound, it is a good practice to separate these two process on different cores to avoid glitch. You have 2 solutions to achieve this : - use [pd~] (see the help patch) - use 2 instances of Pd, one for Gem, the other for the sound, and send data between these two instances with [netsend]/[netreceive] (the system should manage these two instances on different cores). ++
Jack
hello,
osX synchronize openGL rendering to the screen. i.e if your external screen is at 59.9 fps, Gem will not be able to render more than 59.9 fps. since Gem rendering is connected to pd timing, it is connected to audio processing. i;e : if gem is only able to compute 59.9 fps when 60 is asked, then pd time will not be synchronize with real world time. so you have click on the sound.
(desincronize openGL render to screen is usually not an option, since result are ugly with fast moving images)
moreover, Gem rendering are computed during pd data processing, i.e. between every audio block. by default, pd use 64 sample buffer. so pd compute audio buffer every 1.5ms. You have to expect a bit of jitter on the 16.666ms needed between 2 images rendered, accentuating previous effect. (if gem image is rendered 17ms after the previous, one have to wait an extra 16 ms...)
Using faster computer will not solve this problem. using faster screen will offer a solution, but that's not a good solution for me, and probably not for you.
If you really need frame accurate render, easiest solution is to desynchronizes sound and image processing. pd~ is not an option since the 2 process will have the same timer. So, you have to use 2 pd, one for the sound, one for the image, synchronised using netsend / netreceive (on localhost). The best is probably to ask 100fps to Gem, so that it will sync to the screen frequency, whatever the screen is). Then, you should use the screen frequency as the time base of your performance.
using this solution is not to hard to have sound synchronize on screen rendering. hope that help, don't hesitate to ask more precision if i'm not clear.
Cyrille
Le 16/07/2012 19:31, Theo Burt a écrit :
Hi, me and a friend of mine do a lot of live audio-video performance, professionally, all using pd/gem as an environment. We both use Macbook Pros (different models), and for the last couple of years we've been having a serious problem which we now suspect is something to do with GEM/PD, rather than, for example, the graphics cards or drivers.
The problem occurs when running at higher frame rates - it is highly preferable for us to run at 60 frames per second, because (1) it syncs with the refresh rates of most projectors and seems to produce much smoother/more regular movement, and (2) often we are using very precise, high frequency flashing, for optical effects, that we need to be able to sync exactly with screen refreshes. We are generally running the gem window in a second screen (such as a monitor or projector), but it happens when running on one screen too.
As soon as we run at 60 frames per second (or near it), glitching starts to occur frequently in the audio, and the audio goes out of sync with GEM. While the glitching is occurring, processes in PD and GEM jerk along, pausing frequently. To resolve it (temporarily), the audio has to be reset in PD (by reselecting the audio device). The glitching then goes away and everything runs smoothly, but it returns spontaneously after a short time. The glitching is also exacerbated by moving windows around on the screen. It might be worth noting that the same patch running on the very same machine in Windows XP (using bootcamp) does not have this problem.
We have different GPUs, mine is a Nvidia 9600m GT, and his was an ATI of some sort. We are using very simple, geometric graphics, and are not approaching the processing limits of the GPUs at all (if I do push the graphics card very hard, I notice that frames are skipped rather than glitching occurring). I also note that it happens equally when there is low CPU activity, so it's not related to that.
My friend has just purchased a new Macbook Pro, yesterday with a 60% more powerful Nvidia GPU, and unfortunately the glitching is still occurring. It occurs in OS X Lion, and also was happening in Snow Leopard. We've tried disabling power management on the GPU, and this doesn't help either.
I've looked through the gem code in an attempt to try and understand what is happening, but I am afraid it is beyond me!
Does anyone have any idea at all what the problem could be? It would make such a huge difference to us if we could resolve it. Thanks very much for any help in advance (and for developing GEM in the first place)
All the best, Theo
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Le 17/07/2012 21:36, Cyrille Henry a écrit :
hello,
osX synchronize openGL rendering to the screen. i.e if your external screen is at 59.9 fps, Gem will not be able to render more than 59.9 fps. since Gem rendering is connected to pd timing, it is connected to audio processing. i;e : if gem is only able to compute 59.9 fps when 60 is asked, then pd time will not be synchronize with real world time. so you have click on the sound.
(desincronize openGL render to screen is usually not an option, since result are ugly with fast moving images)
moreover, Gem rendering are computed during pd data processing, i.e. between every audio block. by default, pd use 64 sample buffer. so pd compute audio buffer every 1.5ms. You have to expect a bit of jitter on the 16.666ms needed between 2 images rendered, accentuating previous effect. (if gem image is rendered 17ms after the previous, one have to wait an extra 16 ms...)
Using faster computer will not solve this problem. using faster screen will offer a solution, but that's not a good solution for me, and probably not for you.
If you really need frame accurate render, easiest solution is to desynchronizes sound and image processing. pd~ is not an option since the 2 process will have the same timer. So, you have to use 2 pd, one for the sound, one for the image, synchronised using netsend / netreceive (on localhost). The best is probably to ask 100fps to Gem, so that it will sync to the screen frequency, whatever the screen is). Then, you should use the screen frequency as the time base of your performance.
Hello Cyrille,
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. ++
Jack
using this solution is not to hard to have sound synchronize on screen rendering. hope that help, don't hesitate to ask more precision if i'm not clear.
Cyrille
Le 16/07/2012 19:31, Theo Burt a écrit :
Hi, me and a friend of mine do a lot of live audio-video performance, professionally, all using pd/gem as an environment. We both use Macbook Pros (different models), and for the last couple of years we've been having a serious problem which we now suspect is something to do with GEM/PD, rather than, for example, the graphics cards or drivers.
The problem occurs when running at higher frame rates - it is highly preferable for us to run at 60 frames per second, because (1) it syncs with the refresh rates of most projectors and seems to produce much smoother/more regular movement, and (2) often we are using very precise, high frequency flashing, for optical effects, that we need to be able to sync exactly with screen refreshes. We are generally running the gem window in a second screen (such as a monitor or projector), but it happens when running on one screen too.
As soon as we run at 60 frames per second (or near it), glitching starts to occur frequently in the audio, and the audio goes out of sync with GEM. While the glitching is occurring, processes in PD and GEM jerk along, pausing frequently. To resolve it (temporarily), the audio has to be reset in PD (by reselecting the audio device). The glitching then goes away and everything runs smoothly, but it returns spontaneously after a short time. The glitching is also exacerbated by moving windows around on the screen. It might be worth noting that the same patch running on the very same machine in Windows XP (using bootcamp) does not have this problem.
We have different GPUs, mine is a Nvidia 9600m GT, and his was an ATI of some sort. We are using very simple, geometric graphics, and are not approaching the processing limits of the GPUs at all (if I do push the graphics card very hard, I notice that frames are skipped rather than glitching occurring). I also note that it happens equally when there is low CPU activity, so it's not related to that.
My friend has just purchased a new Macbook Pro, yesterday with a 60% more powerful Nvidia GPU, and unfortunately the glitching is still occurring. It occurs in OS X Lion, and also was happening in Snow Leopard. We've tried disabling power management on the GPU, and this doesn't help either.
I've looked through the gem code in an attempt to try and understand what is happening, but I am afraid it is beyond me!
Does anyone have any idea at all what the problem could be? It would make such a huge difference to us if we could resolve it. Thanks very much for any help in advance (and for developing GEM in the first place)
All the best, Theo
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Le 17/07/2012 23:09, Jack a écrit :
Le 17/07/2012 21:36, Cyrille Henry a écrit :
hello,
osX synchronize openGL rendering to the screen. i.e if your external screen is at 59.9 fps, Gem will not be able to render more than 59.9 fps. since Gem rendering is connected to pd timing, it is connected to audio processing. i;e : if gem is only able to compute 59.9 fps when 60 is asked, then pd time will not be synchronize with real world time. so you have click on the sound.
(desincronize openGL render to screen is usually not an option, since result are ugly with fast moving images)
moreover, Gem rendering are computed during pd data processing, i.e. between every audio block. by default, pd use 64 sample buffer. so pd compute audio buffer every 1.5ms. You have to expect a bit of jitter on the 16.666ms needed between 2 images rendered, accentuating previous effect. (if gem image is rendered 17ms after the previous, one have to wait an extra 16 ms...)
Using faster computer will not solve this problem. using faster screen will offer a solution, but that's not a good solution for me, and probably not for you.
If you really need frame accurate render, easiest solution is to desynchronizes sound and image processing. pd~ is not an option since the 2 process will have the same timer. So, you have to use 2 pd, one for the sound, one for the image, synchronised using netsend / netreceive (on localhost). The best is probably to ask 100fps to Gem, so that it will sync to the screen frequency, whatever the screen is). Then, you should use the screen frequency as the time base of your performance.
Hello Cyrille,
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 ?
if you ask Gem to render at 100Fps, you'll have a new image 10ms after last render. if your screen is rendering at 60fps, it ask for 16.6 ms between 2 images. so, after having render a frame, gem will wait for the scren 6.6ms on average. everything will be hang during this 6ms. pd time will desincronize from real time. that's why the clock from this pd can not be used to compute audio. but since pd timing is more than 6ms acurate, you can be certain that every computed frame will be rendered for 16.6ms So this result on using a timing based on the screen. you can use this pd the send bang to an other pd that compute the sound.
Maybe the best is when you have Gem fps as a multiple of your screen fps ?
in theory, if all clock are perfect and syncronized. that's what theo was tring with gem at 60fps and screen at 60 fps.
using gem at 30fps give good result exept that : - 30 fps is to slow - since there is few jitter on gem (that can be reduce using pd -noaudio), and since diferents clock are not syncronized, every image will be display on the screen for 32ms on average, but some will be for 16ms other for 48.
++ c
Thanx for the rest of explanation. ++
Jack
using this solution is not to hard to have sound synchronize on screen rendering. hope that help, don't hesitate to ask more precision if i'm not clear.
Cyrille
Le 16/07/2012 19:31, Theo Burt a écrit :
Hi, me and a friend of mine do a lot of live audio-video performance, professionally, all using pd/gem as an environment. We both use Macbook Pros (different models), and for the last couple of years we've been having a serious problem which we now suspect is something to do with GEM/PD, rather than, for example, the graphics cards or drivers.
The problem occurs when running at higher frame rates - it is highly preferable for us to run at 60 frames per second, because (1) it syncs with the refresh rates of most projectors and seems to produce much smoother/more regular movement, and (2) often we are using very precise, high frequency flashing, for optical effects, that we need to be able to sync exactly with screen refreshes. We are generally running the gem window in a second screen (such as a monitor or projector), but it happens when running on one screen too.
As soon as we run at 60 frames per second (or near it), glitching starts to occur frequently in the audio, and the audio goes out of sync with GEM. While the glitching is occurring, processes in PD and GEM jerk along, pausing frequently. To resolve it (temporarily), the audio has to be reset in PD (by reselecting the audio device). The glitching then goes away and everything runs smoothly, but it returns spontaneously after a short time. The glitching is also exacerbated by moving windows around on the screen. It might be worth noting that the same patch running on the very same machine in Windows XP (using bootcamp) does not have this problem.
We have different GPUs, mine is a Nvidia 9600m GT, and his was an ATI of some sort. We are using very simple, geometric graphics, and are not approaching the processing limits of the GPUs at all (if I do push the graphics card very hard, I notice that frames are skipped rather than glitching occurring). I also note that it happens equally when there is low CPU activity, so it's not related to that.
My friend has just purchased a new Macbook Pro, yesterday with a 60% more powerful Nvidia GPU, and unfortunately the glitching is still occurring. It occurs in OS X Lion, and also was happening in Snow Leopard. We've tried disabling power management on the GPU, and this doesn't help either.
I've looked through the gem code in an attempt to try and understand what is happening, but I am afraid it is beyond me!
Does anyone have any idea at all what the problem could be? It would make such a huge difference to us if we could resolve it. Thanks very much for any help in advance (and for developing GEM in the first place)
All the best, Theo
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Tue, Jul 17, 2012 at 5:35 PM, Cyrille Henry ch@chnry.net wrote:
if you ask Gem to render at 100Fps, you'll have a new image 10ms after last render. if your screen is rendering at 60fps, it ask for 16.6 ms between 2 images. so, after having render a frame, gem will wait for the scren 6.6ms on average. everything will be hang during this 6ms. pd time will desincronize from real time. that's why the clock from this pd can not be used to compute audio. but since pd timing is more than 6ms acurate, you can be certain that every computed frame will be rendered for 16.6ms So this result on using a timing based on the screen. you can use this pd the send bang to an other pd that compute the sound.
There could be locks on the back buffer when using VBL sync that would prevent anything more frequent than 1/VBLrate to actually render into it. So you might have a situation like this:
render 10ms wait 6.6ms render 3.4ms render 10ms wait 3.3ms to get two frames. As I wrote previously, I used to know who to ask to get the actual answer to this, which was great because the GPU people are really secretive about their black boxes.
On Tue, Jul 17, 2012 at 5:09 PM, Jack 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.
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.
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
On Tue, Jul 17, 2012 at 5:59 PM, Cyrille Henry ch@chnry.net wrote:
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.
GEM is certainly sending the GL commands at whatever rate you set, but I honestly don't know for sure what happens in the GL driver and on the GPU when setting the GEM frame rate higher than VBL sync. Maybe the extra rendering commands are ignored or maybe not.
Thanks everyone for all their suggestions. Unfortunately, I can't run the graphics on a different thread, as they are so tightly integrated with data from the audio thread.
Does anyone know how the vsync works on OSX? I mean how does GEM wait for the vsync, to flip the buffer? Does it block the process at any point? Is the process blocked by any part of GEM at any point, on a per frame basis?
For example, after the all the opengl has been executed, I'm presuming a system call is made to actually render the screen? What is this call, and could it simply be that something, perhaps operating system related, is causing it to take too long to return? That would tie in with moving windows around the desktop making the problem worse...
OR, (and this may sound strange), there's no possibility for a denormal to creep in anywhere is there? It's just what happens to the system (the whole of PD seems to slow down to about 50% while the glitches are going on) is particularly reminiscent of denormal issues I've had in the past...
On 17/07/2012 23:15, chris clepper wrote:
On Tue, Jul 17, 2012 at 5:59 PM, Cyrille Henry <ch@chnry.net mailto:ch@chnry.net> wrote:
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.GEM is certainly sending the GL commands at whatever rate you set, but I honestly don't know for sure what happens in the GL driver and on the GPU when setting the GEM frame rate higher than VBL sync. Maybe the extra rendering commands are ignored or maybe not.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello,
Le 19/07/2012 12:14, Theo Burt a écrit :
Thanks everyone for all their suggestions. Unfortunately, I can't run the graphics on a different thread, as they are so tightly integrated with data from the audio thread.
i understand that separating audio and video can be very complex, but i think that's the only solution to be very accurate. don't forget that netsend/netreceive work very well on localhost...
Does anyone know how the vsync works on OSX? I mean how does GEM wait for the vsync, to flip the buffer? Does it block the process at any point? Is the process blocked by any part of GEM at any point, on a per frame basis?
the best is to make tests and report result in this list. by example, you can open an empty gem window rendering at 120fps, using a vsync to a 60fps screen. then, use a simple osc~ to produce sound and record the result with an other software. i supect that you'll have on average 8ms of sinusoid, then 8ms of silence. this would indicate that pd process is completely stop during vsync wait. well, things can be a bit more complex as chris explain, but that's a good staring point to understand how things work. a metronome should also be 2 time slower that what it should. I don't use osX, so i can't make this test for you.
you can also try to remove vsync, in order to check that you'll have no more sound problem. unfortunately, this usually result in horrible visual artefact. i don't know how to do that on osx.
working on single buffer should not have this sync, but you'll not be frame accurate, and you'll still have visual artefact, but you can use this mode for tests.
For example, after the all the opengl has been executed, I'm presuming a system call is made to actually render the screen? What is this call, and could it simply be that something, perhaps operating system related, is causing it to take too long to return?
i suspect that the return of the call is made only when the flip is made.
That would tie in with moving windows around the desktop making the problem worse...
OR, (and this may sound strange), there's no possibility for a denormal to creep in anywhere is there? It's just what happens to the system (the whole of PD seems to slow down to about 50% while the glitches are going on) is particularly reminiscent of denormal issues I've had in the past...
denormal problem cause CPU to increase. if pd wait for vsync, then cpu decrease.
cheers c
On 17/07/2012 23:15, chris clepper wrote:
On Tue, Jul 17, 2012 at 5:59 PM, Cyrille Henry <ch@chnry.net mailto:ch@chnry.net> wrote:
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.GEM is certainly sending the GL commands at whatever rate you set, but I honestly don't know for sure what happens in the GL driver and on the GPU when setting the GEM frame rate higher than VBL sync. Maybe the extra rendering commands are ignored or maybe not.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Thu, Jul 19, 2012 at 6:14 AM, Theo Burt tb504@york.ac.uk wrote:
Does anyone know how the vsync works on OSX? I mean how does GEM wait for the vsync, to flip the buffer? Does it block the process at any point? Is the process blocked by any part of GEM at any point, on a per frame basis?
VBL sync is a single line of code that turns it on/off. GEM's render engine doesn't do anything different based on that state.
For example, after the all the opengl has been executed, I'm presuming a system call is made to actually render the screen? What is this call, and could it simply be that something, perhaps operating system related, is causing it to take too long to return? That would tie in with moving windows around the desktop making the problem worse...
The last call in any GL chain is glFinish() which flushes all of the commands to the card via the driver. The driver can block the uploading of commands to the card for various reasons most of which are not documented anywhere. Apple has OpenGL profiling tools that can show where time is being spent in the driver.
Chris and Cyrille, thank you both for this very useful information and ideas for testing etc. I will investigate some more and post results when I get some.
Thanks to all Theo
On 19/07/2012 13:49, chris clepper wrote:
On Thu, Jul 19, 2012 at 6:14 AM, Theo Burt <tb504@york.ac.uk mailto:tb504@york.ac.uk> wrote:
Does anyone know how the vsync works on OSX? I mean how does GEM wait for the vsync, to flip the buffer? Does it block the process at any point? Is the process blocked by any part of GEM at any point, on a per frame basis?VBL sync is a single line of code that turns it on/off. GEM's render engine doesn't do anything different based on that state.
For example, after the all the opengl has been executed, I'm presuming a system call is made to actually render the screen? What is this call, and could it simply be that something, perhaps operating system related, is causing it to take too long to return? That would tie in with moving windows around the desktop making the problem worse...The last call in any GL chain is glFinish() which flushes all of the commands to the card via the driver. The driver can block the uploading of commands to the card for various reasons most of which are not documented anywhere. Apple has OpenGL profiling tools that can show where time is being spent in the driver.
-
chris clepper -
Cyrille Henry -
Jack -
Theo Burt