RadeonPro Discussion Forum

Full Version: Dynamic Vsync control and global settings on startup
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Maybe I am the only person out there that has these problems. As I see no other thread on the internet which discusses this. Dont take this post in the wrong way I really adore this product and think its a great tool for die-hard game-tweakers.

Anyway when I select dynamic vsync in a profile triple buffering gets forced on and the checkbox becomes grey and unclickable. Which is weird since when you only edit the global profile you have the option to either turn it on or off although this also defaults to on. I have not done any testing on this but if it is indeed the case that triple buffering is still on. If it were on it makes the whole purpose of dynamic vsync worthless. With normal vsync+triplebuffering you wouldnt get tearing at the cost of a larger videomemory footprint and an extra frame of lag. Now with this you get tearing and the above disadvantages of triple buffering.

As for the other problem when you boot up your pc for the first time global settings do not apply with any game. Unless you edit something in radeonpro and then try an application. (Yes I have checked the start with windows and api monitoring etc).

Actually I came across a lot more nitpicky things like the texture filtering quality option which is essentialy catalyst AI looking at the description. And overdrive not working on a global level(yes i know MSI afterburner exists its just less troublesome to have just 1 program for everything I actually only use one setting in there(always use highest performance clocks) to kill the throttling of the card while playing games)

These problems occured on a 5870(latest drivers) and windows7 64 bit in both the 32bit and 32/64bit mode of radeonpro.

Thank you for this great product once again hope it evolves into something even more awesome.
Constructive criticism is always welcome.

Triple-buffering is needed for DVC because if a game is using double-buffering then framerate will drop from 60 to 30 with no frames in between that range. The purpose of DVC is limit framerate and eliminate screen tearing when sustained fps is high enough and avoid stuttering when framerate drops below vsync rate, its purpose has nothing to do with lag.

The first time run bug is new to me, will try to reproduce it.

Texture Filtering Quality and Surface Format Replacement features replaced Catalyst AI.

Overdrive is not supposed to work in Global profile, it's that way by design.
Then what is the purpose at all of Dynamic Vsync. Triple buffering does the same but without the tearing I dont get the benefit at all then. I thought Dynamic vsync worked like this taking 100 fps as an example as it divides easily to ms. The first frame is done rendering gets in the backbuffer it gets copied to the front buffer as it is done. The display is scanning it and once its done its sends the vsync signal to say its done. Meanwhile of course the gpu is busy working at the previous frame. Suppose its done with in 10 ms the driver says go ahead copy to the front buffer the vsync just came in. So it gets switched to the front buffer while the monitor is doing is scanning his vertical blanked pixels and the next image will be scanned out of the buffer when it starts its new scan. This obviously results in zero tearing well maybe if your gpu cant copy the frame fast enough into the front buffer. But what if it took longer then 10 ms then is it not the driver/api/whatever that tells it to not wait for the next sync but just copy it to the front buffer when its done pronto. So basicly you see only part of the next frame as the old frame is still on top as it was not synced which results in a horrible tear Sad. What purpose does triple buffering fill in there it does not look like any benefit to me. I thought I got the purpose and it seemed like a good idea to me but with triple buffering included then just keep normal vsync on right?
Also in your second statement you say it has nothing to do with lag... Isnt this the whole point of DVC reducing lag by allowing an unsynced frame so you dont get 30 fps(as in the classic 60 fps case) but like 50 fps or 40 fps. A higher fps means less lag as more images (well half/quarter images in the case with tearing) get scanned out by the screen so you see more images in a certain timeframe. Which reduces lag obviously.
Anyway the lag with triple buffering if enabled is obvious as the frame in the middle buffer is older then the one in the back buffer. So in a 60 fps example that frame would be 16.67ms old(implying the gpu is fast enough of course) resulting in well that amount of lag.

Im a novice programmer and just started to learn to program in opengl so I dont have any insight on the actual technique just quesses.

btw why is overdrive not supposed to work that way I absolutly dont get that choice ati's solution in CCC features overdrive over the whole range as well actually it is the only way. I like the freedom over many profiles, but I dont see any reason not to include a global setting as it is rather nifty to have a one fits all overclock or a setting you could just apply once. And then just let the profiles overwrite that when called.

Thanks for your quick response and sorry for this long story.
If DVC reduces lag then it's a collateral effect but not its primary purpose, which is keep vsync on when possible and turn vsync off when frame rate is lower than display refresh rate to alleviate stuttering. Assuming you have a 60Hz display, with vsync on and without triple-buffering then frame rate won't never drop from 60 FPS to anything else than 30 FPS. DVC keeps vsync on until frame rate drops to a certain threshold below the display's refresh rate.
I still dont understand it if the card gets the vsync signal from the monitor and the GPU knows it is still rendering in the back buffer on a new frame. Then is not obvious to just say you know what just send the frame when its ready better late then never. Or in this case dont wait until the next vsync before sending it something like a missed deadline. That way part of the old frame will be displayed but the new frame will also be partly displayed resulting in a tear.
RadeonPro doesn't control vsync signal per se, it just tells the API (D3D9, DXGI etc.) to output a frame with or without waiting for next vsync signal depending on current sustained frame rate.
I never mentioned that radeonpro was controlling it (well not in the previous post, maybe in the big one before). I am just stating that I dont understand why radeonpro forces the triple buffering checkbox to on when you click the DVC option. What it does underwater with that I dont know but yeah I can guess those are API calls. But now I still dont know why it forces triple buffering on you say you cant get framerates in between 60 and 30 but why not. If vsync is off I can get framrates inbetween 60 and 30 with double buffering why cant I do that in this case. Why do you need triple buffering for it? Isnt that the magic of DVC less memory and a frame less of lag. In comparision to triple buffering with vsync.
With vsync on and without triple-buffering the frame rate drops from 60 to 30 with no in between value in that interval. You understand that, right? Vsync can't be disabled whenever 60 FPS cannot be maintained because it causes a lot of stutter. Long story short, triple-buffering is needed in order to make DVC work.
Sorry I am really sorry but no I cannot understand why it cant be disabled if I cant mantain 60 fps. The gpu just misses the vsync signal it sees that it reports that it sets a flag. It knows the frame is not ready because it is still rendering it. So instead it does not wait for the next one but it just sends it right away when its done not waiting for the next vsync. Here is some "pseudocode" what I mean. The alphabetical letters mean the steps happen at the same time in parralel.

classic vsync
1. if rendering is completed -> render.flag=1 and stop the rendering
1a. scan for the vsync signal if it is reported -> vsync.flag=1 and stop scanning for the next signal until the vblank has passed then set vsync.flag=0
2. if and only if (vsync.flag=1 and render.flag=1) -> copy the frame to the front buffer for scanout
3. set the render.flag=0 again so the gpu can start rendering again

my interpertation of DVC or adaptive vsync which both seem to solve the same purpose
1. if rendering is completed -> render.flag=1
1a. scan for the vsync signal while vsync.flag=0 if it is reported -> vsync.flag=1 and stop scanning for vsync signal (this is the magical part no reset to 0 it just stays on 1)
2. if and only if (vsync.flag=1 and render.flag=1) -> copy the frame to the front buffer for scanout (it only waits for the first vsync not the second as the flag will stay 1 forever after the first signal)
3. set both flags to 0 so the gpu can render the next frame and it is waiting for the first vsync signal again.

In short it should not drop to 30fps or a way better way of saying it. It does not wait for the next vsync signal. It only waits for the very first one. After the first one it will just copy the image to the front buffer. Triple buffering holds no place here whatsoever. If you want full tear free gameplay and a smooth curve down to 30 fps triple buffering can indeed help but there is no reason to turn vsync off at that point. The disadvantage of that is that it requires more video memory and the framerate is getting an extra buffer which in turn increases lag.

I hope it is clear what I am trying to say now english is not my native language so maybe that is the problem.
Your logic seems to be correct but we come back to this:

(08-17-2013 09:25 PM)John Wrote: [ -> ]RadeonPro doesn't control vsync signal per se, it just tells the API (D3D9, DXGI etc.) to output a frame with or without waiting for next vsync signal depending on current sustained frame rate.
Pages: 1 2
Reference URL's