Has anyone tried RadeonPro for microstuttering?

[omeds]

In the beginning of my SLI days I would have disagreed, being overly enthusiastic about minimized microstutter. Now I agree. You would have to set the limit to your lowest fps, otherwise it won't work all the time. That simply destroys scaling.

But there is one exception:
If you're playing with vsync anyway and still get stutter, you could limit to 60fps which can also help.

You just need to set a cap that you can maintain. I use 59fps with vsync on 60hz displays, and 125 without vsync on 120hz displays, no problems.

 

[Plimogz]

a hah hah hah hah haaaaaa yes!!!! Just ran crysis 2 maxed out @2560 with crossfire 7970's with zero detectable microstutter (to me anyways). Just used a simple frame cap in Afterburner and voila!!!!! Finally after all these years of me bashing multi gpu I will actually start recommeding it. I am a believer. I'm actually going to go back and fire up some of my old rigs to see if this will work for them too.

Awesome! gotta try this if I ever find time to sit down to a game.

 

[boxleitnerb]

You just need to set a cap that you can maintain. I use 59fps with vsync on 60hz displays, and 125 without vsync on 120hz displays, no problems.

Exactly - that I can maintain, that is the problem.

I used this in Skyrim for example. I played with 4xSSAA, so it was quite demanding for the GPUs. Outside in the forest I could have 40fps while at other locations or in dungeons I had a constant 60fps. Now if I cap the framerate at 40fps so I would not get microstutter in foresty locations, I lost a whooping 20fps everywhere else. That is just inacceptable.

Of course I could just turn down the settings in order to reach a constant 60fps. But then a single GPU might do the trick too with maybe 40fps, but without microstuttering at half the cost. You see the problem right there, the compromise can be too severe.

 

[omeds]

Well, I only play games at a solid frame rate at or above my refresh rate in the first place, so they remain fluid. But sure if you play at 40 fps then it might be an issue.

Sure occasionaly there might be a small drop, but if its maintaining my desired frame rate 95%+ of the time, I'm happy.

 

[Skurge]

Exactly - that I can maintain, that is the problem.

I used this in Skyrim for example. I played with 4xSSAA, so it was quite demanding for the GPUs. Outside in the forest I could have 40fps while at other locations or in dungeons I had a constant 60fps. Now if I cap the framerate at 40fps so I would not get microstutter in foresty locations, I lost a whooping 20fps everywhere else. That is just inacceptable.

Of course I could just turn down the settings in order to reach a constant 60fps. But then a single GPU might do the trick too with maybe 40fps, but without microstuttering at half the cost. You see the problem right there, the compromise can be too severe.

Isn't that what adaptive vsync or dynamic vsync does? Let the cards go up to 60fps when you are in dungions, but once you are in the forest it will limit the cards to 40FPS? or am I understanding this wrong?

 

[boxleitnerb]

It does, but when vsync is off below 60fps, microstutter will still exist during those periods. To combat microstutter all the time one needs either sufficiently high fps or the fps cap.
I'm also not so convinced by this adaptive stuff. Below 60fps I would get tearing after all and I cannot stand that.

 

[pandemonium]

It is a framerate cap, albeit a dynamic one. V-sync = frame rate cap to buffer each frame according to the display's Hz.

All this does is lower the cap in more demanding scenes and raise it in less stressful ones and that results in each card in a multi-GPU setup being forced to generate equal frames at equal timings (or as equal as one can get).

RadeonPro has been around for a long, long time, but I don't remember it having that function last I used it (it's been a while). So this being mentioned is pretty noteworthy for AMD owners and will probably be implemented soon enough with official catalyst packages.

I'll have to test this myself though and see how well it works with my setup. Thanks for the link. 🙂

 

[boxleitnerb]

It is a framerate cap, albeit a dynamic one. V-sync = frame rate cap to buffer each frame according to the display's Hz.

All this does is lower the cap in more demanding scenes and raise it in less stressful ones and that results in each card in a multi-GPU setup being forced to generate equal frames at equal timings (or as equal as one can get).

RadeonPro has been around for a long, long time, but I don't remember it having that function last I used it (it's been a while). So this being mentioned is pretty noteworthy for AMD owners and will probably be implemented soon enough with official catalyst packages.

I'll have to test this myself though and see how well it works with my setup. Thanks for the link. 🙂

Could you maybe post a frametime diagram where one can see that? So far I only have seen constant values.

 

[pandemonium]

Why would I need to? It's directly implied by the option in RadeonPro.

Dynamic Framerate Control - Keep up to ## FPS:

 

[Skurge]

It does, but when vsync is off below 60fps, microstutter will still exist during those periods. To combat microstutter all the time one needs either sufficiently high fps or the fps cap.
I'm also not so convinced by this adaptive stuff. Below 60fps I would get tearing after all and I cannot stand that.

I'd imagine something like a 2 stage cap would work. When over 60 it's limited to 60, when it drops below 60, you can set it to limit it to 40.

 

[boxleitnerb]

Why would I need to? It's directly implied by the option in RadeonPro.

Dynamic Framerate Control - Keep up to ## FPS:

It works the same way with a normal fps limiter. If I limit to 50 and cannot keep 50, the cap will obviously have no effect.

The question is:
What happens to the frametimes if you go below the cap? Will they be smoothed out as well (which I doubt as it would be quite complicated)? If you have the tool and a CF setup, it wouldn't be too hard to post some results.

@Skurge:

That would be very very nice. I imagine Nvidias frame metering does something along those lines already.

 

[pandemonium]

I'd love to post some results; when I'm at home and able to do so. 🙂

Interestingly, I don't see this option in the changelog of the program and no recent updates in that log since February of 2011... So either the log isn't being update and new releases are being made, or this option has been around for a long time and has gone unnoticed, lol.

 

[Keysplayr]

n/m

 

[omeds]

It does, but when vsync is off below 60fps, microstutter will still exist during those periods. To combat microstutter all the time one needs either sufficiently high fps or the fps cap.
I'm also not so convinced by this adaptive stuff. Below 60fps I would get tearing after all and I cannot stand that.

Well, without a frame rate cap, you would get ms ALL the time. At least by using a cap, you will reduce the occurance of ms. So no matter which way you slice it, using a cap is an improvement.

The real issue is, you insist on playing with frame rates that are not fluid in the first place. If you had more GPU power or used less aggressive settings, you could achieve ms free AND fluid gameplay.

The reason you get tearing with adaptive vsync, which is a separate issue, is because below 60fps vsync is disabled to prevent juddering when frame rates transition to below your refresh rate. Tearing below 60fps is the trade off. Again, if you played with fluid frame rates, you would not have this issue.

 

[pandemonium]

That was some confusing running around.

For anyone else actually trying this, it's not available as an "official" release and by BETA only, from the BETA thread on guru3d forums.

Updated beta changelog:

Not for the faint heart

If you wanna know what's coming up to next version while it's being developed, try the Preview build with upcoming features and bug fixes, but with new bugs as a bonus maybe.

Download it here

Preview updated [10/06/2012 19:45 -0300]

Bold text on changelog indicates new or changed/improved features.

This build brings 64-bit support, includes a few general bug fixes and improved OpenGL support, which includes, along several bug fixes, the new OSD features and DFC support. DVC, FXAA and SMAA for OpenGL is still under development (no ETA at all thou)

There's also improved support for DirectX 9.0Ex games (World of Tanks, Arma 2 OA and others)

I've dropped a few old OSD features like the old fps counter, crossfirex bar and api logo at startup, those features are superseded by new OSD text that shows the same information.

As a final note, 64-bit support can cause issues with other programs like FRAPS and DXtory. FRAPS is currently being detected by RadeonPro which in turn deactivates 64-bit module when FRAPS is running or is started when RadeonPro is already running. DXtory works partially, I recorded a few movies without issues, but had problems starting some programs like MPC-HC 64-bit. To alleviate the problem, 64-bit support on RP can be enabled/disabled at program settings, without the need to restart the core 32-bit program.

As usual, enjoy and please report bugs here.

Updates
-------
xx/xx/2012 - New build 1.1.1.0

- Changed: German translation update (thanks to Lennart Brüggemann)
- Changed: improved OSD rendering performance on DirectX 10/11 games
- New: Added support for 64-bit applications
- New: FXAA support (DirectX 9/10/10.1/11)
- New: FXAA can be activated/deactivated during the game (configure the hotkey on RadeonPro's Settings screen)
- New: SMAA support (DirectX 9/10/10.1/11)
- New: SMAA can be activated/deactivated during the game (configure the hotkey on RadeonPro's Settings screen)
- New: Dynamic Vsync Control (DVC) support. This feature controls how vertical synchronization is applied at rendering time, automatically turning it off when frame rate is below monitor's refresh rate to reduce stuttering and turning it on when framerate is above or equal to monitor's refresh rate, improving smoothness.
- New: DVC can be activated/deactivated during the game with SHIFT+HOME key
- New: Dynamic Framerate Control (DFC) support. This feature acts like a frame rate limiter with smoothness control, just set a frame rate target and RadeonPro will try to keep it as close as possible while maintaining frame rendering times close to each other to avoid stuttering.
- New: DFC can be activated/deactivated during the game with SHIFT+END key
- New: DFC feature's frame rate target is adjustable in real time, press SHIFT+INSERT to increase the limit and SHIFT+DELETE to decrease it
- New: Lock frame rate up to monitor's refresh rate. This feature limits internal frame rendering times accordingly to refresh rate (i.e. 60 Hz = 16.67 ms) instead of waiting vertical retrace.
- New: On-Screen Display panel, showing current status of some RadeonPro features on top of game screen. Press PAGEDOWN key to toggle between full panel/reduced panel/hidden.
- New: OSD panel can be made visible since game start either globally or at profile level, just configure it on OSD tab
- New: OSD panel versions can be disabled either globally or at profile level, just configure it on OSD tab
- New: Real time GPU monitoring with On-Screen Display support. GPU monitoring displays your video cards temperatures, utilization, FAN speed and VRAM utilization
- New: Current date/time/FPS and actual playing time can be displayed at OSD
- New: Better keyboard handling (i.e. fixes some games that don't allow OSD control or change of FPS corner)
- New: Improved hook handling with better Steam overlay compatibility
- New: OverDrive controls allow basic overclocking, manual cooler fan speed and PowerTune adjustments (available only at profile level)
- New: Added proper support for Direct3D9Ex games (i.e. Splinter Cell Conviction, Blades of Time, Fallout New Vegas, World of Tanks etc.)
- New: Improved OpenGL support and bug fixes
- Fixed: Some games that used to hang at startup when API monitoring was active are now playable (i.e. STALKER Call of Pripyat)
- Fixed: screenshots now works in DirectX 10/11 with R10G10B10A2/B8G8R8A8 formats used by some games (Dirt 3/Showdown, F3AR). Performance is not so good as in other games, but it will be optimized soon.
- Removed: old style FPS counter, API logo at startup and CrossfireX bar, use other OSD options instead
- Removed: alternate AMD Radeon logo
- Removed: skins (all). They will be replaced by new Web skins feature. Anyone with HTML and Javascript skills will be able to create skins for RadeonPro.
- Removed: Aggressive API detection (useless with new hook handler)
- Known issues:
-- Vsync is a bit broken in DirectX 9 for 64-bit apps

 

[boxleitnerb]

True, but it comes at a cost as I said. I buy mGPU to increase my settings in the first place. If I reduce settings a single GPU might do the trick without microstutter at slightly lower fps, depending on how much the scaling is affected by the cap.
This problem gets worse when the framerate really fluctuates alot, lets say you have values from 30 to 90. Lowering settings so you would never drop below 60 would be a drastic step, negating the positive effect of mGPU altogether.

It's like one step forward and one step back so to speak. If this thing truly were dynamic, then I'd be all for it. But as it stands (and I've experimented with static fps caps for over a year with my SLI setup), the downside can be really severe.

 

[omeds]

Well as with anything, if you want better quality you need the horsepower to do it.

 

[boxleitnerb]

That's not the point - the point is that depending on the game and your settings, most if not all of your horsepower could go to waste with an fps cap. I've explained why.

The only two scenarios where this makes sense is limiting higher fps when not playing with vsync (and where usually no or little microstutter occurs) or when playing with vsync and limiting at 60 for perfect smoothness. vsync would ruin scaling anyway so it doesn't matter there.

 

[omeds]

It is the point. Your system cannot achieve the level of performance required at the settings you wish to use.

Solution: Get more GPU horsepower or reduce settings, OR live with ms at choppy frame rates.

Why does scaling above your refresh rate matter if you have max settings/SSAA/AO etc, at fluid frame rates anyway?

 

[cmdrdredd]

It is the point. Your system cannot achieve the level of performance required at the settings you wish to use.

Solution: Get more GPU horsepower or reduce settings, OR live with ms at choppy frame rates.

Why does scaling above your refresh rate matter if you have max settings/SSAA/AO etc, at fluid frame rates anyway?

Maybe it affects input lag. Has anyone tested the input lag using this fps limiter?

There are some titles where the difference between fps can be noticed even if both are consistent.

 

[omeds]

If you use a 59fps cap with vsync @ 60hz it helps reduce input lag immensely, while also helping to eliminate ms.

I have never noticed input lag using a 125fps cap. I played online fps semi-competitively since '02 and have always used a 125 or 250 fps cap for online fps, for minimal tearing and smooth gameplay without vsync, even before I had my first MGPU setup, so afaic, a cap should be used for the best experience anyway, the fact it also greatly reduces ms is another benefit.

 

[boxleitnerb]

It is the point. Your system cannot achieve the level of performance required at the settings you wish to use.

Solution: Get more GPU horsepower or reduce settings, OR live with ms at choppy frame rates.

Why does scaling above your refresh rate matter if you have max settings/SSAA/AO etc, at fluid frame rates anyway?

If you're not using vsync, that is a moot point. I was speaking about drops below 60 anyway.

Third option:
Implement frame metering that reduces ms without having to resort to using an fps cap 😉

What you should consider is that 40fps@ single GPU != 40 fps@multi GPU. The former can be playable, the latter unplayable. Single GPU has a home advantage here, that is the significant point.

Imagine this:

• 4xSSAA and mGPU:
  min fps = 45, avg fps 70. With cap@40 not very well playable, without cap also not well playable
• 2xSSAA and mGPU:
  min fps = 60, avg fps 100. With cap@60 very well playable, but cap not necessary because at higher fps microstutter becomes less noticeable usually. Also reduced image quality
• 2xSSAA and sGPU:
  min fps = 35, avg fps 55. Reasonably well playable because sGPU > mGPU at the same framerate. Achieved at half the cost.

Having an fps cap can solve one problem at the cost of introducing another, namely lower performance. It's different, but depending on the scenario not necessarily better.

 

[omeds]

Personal preference, I find 40 fps fairly unplayable on either single or MGPU.

In your first example with an average of 70 fps, why not cap it to 59/60/62/66? With an average of 70, how much of the time do you think it will be below 60?
A majority of the time (when you can achieve 60fps) it will be better than without a cap, and a small amount of the time (when fps drop below 60) it will be exactly the same as you play now, without a cap. You don't lose anything, but gain smooth ms free gameplay most of the time.

Sure, frame metering would be great and I'm all for it, but atm, you can get fluid, ms free gameplay if you have enough GPU performance.

 

[nextJin]

If you use a 59fps cap with vsync @ 60hz it helps reduce input lag immensely, while also helping to eliminate ms.

I have never noticed input lag using a 125fps cap. I played online fps semi-competitively since '02 and have always used a 125 or 250 fps cap for online fps, for minimal tearing and smooth gameplay without vsync, even before I had my first MGPU setup, so afaic, a cap should be used for the best experience anyway, the fact it also greatly reduces ms is another benefit.

This what I do with all of my games, I set a limiter to 59 with vsync on. There is no microstutter, little if any screen tearing, and no input lag (at least not like it is with Vsync on without the limiter)

U3011 (60hz panel) w/ 7970 CF @ 1125/1625

 

[wand3r3r]

Has anyone been able to test RadeonPro more thoroughly?

How was it e.g. when the avg FPS is less then the vsync?
Is it smooth, especially compared to not using it? What about compared to SLI?