Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Reply
 
Thread Tools
Old 07-21-09, 12:09 PM   #1
bwheaton
Registered User
 
Join Date: Nov 2008
Location: California
Posts: 59
Send a message via AIM to bwheaton
Default glxGetVideoSync fix in 190.16

I have an app which does some fairly heavy home-rolled SLI - I send all my video data to two GPUs, and render in 4 screens at once. On each X-Screen, I'm using glxGetVideoSync and glzWaitVideoSync to start my rendering for the next frame. This is the bug mentioned:

Fixed a bug that caused glXGetVideoSyncSGI, glXWaitVideoSyncSGI, and glXGetRefreshRateSGI to operate on the wrong screen when there are multiple X screens.

I'm seeing quite a bit of contention when I'm rendering on both X-Screens. I've isolated 'most' of my threading, and there's a good chance that the driver is involved. With two GPUs, if one of them is slower (8500 or so, as opposed to 8800 - with GTX 275 as the main GPU) then the effect is far more pronounced.

The problem manifests as lot of skipped frames, and my background threads (that transfer frames) being stalled quite often. Is this something this bug could be causing? Is it an off by one error or some-such, where GPU 1 uses GPU 0 sync info? Can I presume that would artificially make a sync-point between them, stalling the driver?

Bruce
bwheaton is offline   Reply With Quote
Old 07-21-09, 12:21 PM   #2
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default Re: glxGetVideoSync fix in 190.16

Yes, that could cause contention similar to that. The main problem I saw was that both threads would wake up at the same time (since they were both waiting for GPU 0), causing them to run in lockstep.

However, the real question is, why do you need glXWaitVideoSyncSGI? You should be able to use glXSetSwapInterval(1) and then just use glXSwapBuffers, which performs the wait for vblank on the GPU instead of the CPU, freeing up the CPU to process other work.
AaronP is offline   Reply With Quote
Old 07-21-09, 12:35 PM   #3
bwheaton
Registered User
 
Join Date: Nov 2008
Location: California
Posts: 59
Send a message via AIM to bwheaton
Default Re: glxGetVideoSync fix in 190.16

Thanks Aaron, that's good news in a weird way - potentially at least.

I do use swapbuffers, but then I wait for the sync (which doesn't seem to waste CPU?) and then I start rendering the next frame. I'm using it to get regular opportunities to draw. Each display has it's own thread and context, btw.

I was hoping, and this has fallen over recently, to quickly grab the time when I wait for sync releases and get a semi-accurate idea of where the VBI is. That used to give me a very close approximation, but got worse a while ago.

I also use the retrace count as a hardware frame counter so I get a good idea if frames were skipped.

Would you recommend a different way to do my regular drawing? In an ideal world, I would only start to draw with 'just enough' time to finish and get the frame presented at the next VBI, but rendering at the start of the frame before is fine too.

Bruce
bwheaton is offline   Reply With Quote
Old 07-21-09, 02:29 PM   #4
AaronP
NVIDIA Corporation
 
AaronP's Avatar
 
Join Date: Mar 2005
Posts: 2,487
Default Re: glxGetVideoSync fix in 190.16

Correct, WaitVideoSync will put the process to sleep until vblank. However, that time spent sleeping is time the process could spend working on something else, like the next frame. That why it's almost always better to just have your app draw the frame and then swap and not have any CPU-GPU synchronization barriers like WaitVideoSync.

The driver has code in it to prevent SwapBuffers from getting more than one frame ahead, so you shouldn't need to worry too much about latency.
AaronP is offline   Reply With Quote
Old 07-21-09, 03:08 PM   #5
bwheaton
Registered User
 
Join Date: Nov 2008
Location: California
Posts: 59
Send a message via AIM to bwheaton
Default Re: glxGetVideoSync fix in 190.16

I think you replied to what you thought I might say

I do this:

wait for sync
draw
swap (async, swap interval is 1)
twiddle thumbs until next frame

I understand that the process, (well, thread, right?) will sleep, in a hopefully non-CPU using way until the next VBI. I'm fine with that - my other threads are doing a lot of work in the interim, including a lot of OpenGL stuff in other contexts, unless I'm way off base.

What's the alternative though, to get a guaranteed 'visit' per frame? I want to render after the last frame has been swapped, but in plenty of time that the frame I now draw will be ready for the next draw. Is polling myself (on a finish object, say) really any better? That's the only job that thread has, and I really don't want it to do any pre-pre-work on the next frame, since things may change (like a new texture arriving on another thread) before the VBI.

Am I really 'stopping' something in the driver or CPU, or just putting that one thread into a waiting state?

Thanks for this help, BTW.

Bruce
bwheaton is offline   Reply With Quote
Reply


Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 09:42 AM.


Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.