Overclock.net › Forums › Graphics Cards › AMD/ATI › ATI Drivers and Overclocking Software › AMD GPU Drivers: The Real Truth.
New Posts  All Forums:Forum Nav:

AMD GPU Drivers: The Real Truth. - Page 29

post #281 of 454
* I'm sure Nvidia Variable Target Frame Rate is the same, except Nvidia Sets the Target frame rate instead of the user.
post #282 of 454
It's just a simple fps cap nothing else.
Workstation
(4 items)
 
  
CPUMotherboardGraphicsMonitor
Xeon E5-2690 Supermicro 2011 Nvidia GP100/ Vega FE Dell ultrasharp 4k 
  hide details  
Reply
Workstation
(4 items)
 
  
CPUMotherboardGraphicsMonitor
Xeon E5-2690 Supermicro 2011 Nvidia GP100/ Vega FE Dell ultrasharp 4k 
  hide details  
Reply
post #283 of 454
Quote:
Originally Posted by sugarhell View Post

It's just a simple fps cap nothing else.

Yes. It keeps the Frames locked 60 ~ I don't think it works smoothly though if frames drop below 60, there would be nothing to lock.
post #284 of 454
Quote:
Originally Posted by Gamedaz View Post

Yes. It keeps the Frames locked 60 ~ I don't think it works smoothly though if frames drop below 60, there would be nothing to lock.

The only thing that works in that situation is not to drop below 60 fps.
Workstation
(4 items)
 
  
CPUMotherboardGraphicsMonitor
Xeon E5-2690 Supermicro 2011 Nvidia GP100/ Vega FE Dell ultrasharp 4k 
  hide details  
Reply
Workstation
(4 items)
 
  
CPUMotherboardGraphicsMonitor
Xeon E5-2690 Supermicro 2011 Nvidia GP100/ Vega FE Dell ultrasharp 4k 
  hide details  
Reply
post #285 of 454
Quote:
Originally Posted by sugarhell View Post

It's just a simple fps cap nothing else.

Some time ago I was testing drivers and found out that high FPS while Vsync active is causign stuttering. It was most common in Skyrim, inside buildings.

There were two reasons why was this happenning:

A) Vsync with Double buffering
Buffers were full, GPU went to sleep, and when it was again fully awaken it was too late.

B) Game engine was still generating wireframe data on CPU level, but GPU was waiting for sync.
Buffers handled by DirectX overflowed.

High-performing HW able to deliver over 60 FPS (ok. over 300 in these scenes} suddenly start to hinder its own performance...

Solutions:

1. Forced 3rd buffer via Windowed mode
In Win 7 and Vista, DWM acts as another 3d Engine. Everything what game presented into DWM thinking its a front buffer was in fact just another backbuffer.

2. Frame limiter set to refresh rate of display (60)
Flow of wireframe data, became controlled and GPU was getting new data at even pace.

Subsequently doublebuffering and sleep was not a problem because GPU was receiving new draw call requests at same frequency as was presenting.



Question is how this simple FPS cap works.
Edited by Offler - 10/30/15 at 7:20am
post #286 of 454
I can explain why this happens but it is a long topic. In general different fps caps use different tech . Simply you want to delay your cpu until the next frame. So it goes like that 60 fps-> wait -> 60 fps.

This works somewhat similar to coroutines in unity. But in some game engines the physics engine is just bad. You calculate your physics movement based on delta time and frame latency. So if you delay your cpu with fps cap there is a possibility to break the animations of your world(stutter). For example in unity to deal with this you use the fixedupdate(); function that is independent from different fps.
Workstation
(4 items)
 
  
CPUMotherboardGraphicsMonitor
Xeon E5-2690 Supermicro 2011 Nvidia GP100/ Vega FE Dell ultrasharp 4k 
  hide details  
Reply
Workstation
(4 items)
 
  
CPUMotherboardGraphicsMonitor
Xeon E5-2690 Supermicro 2011 Nvidia GP100/ Vega FE Dell ultrasharp 4k 
  hide details  
Reply
post #287 of 454
Quote:
Originally Posted by sugarhell View Post

I can explain why this happens but it is a long topic. In general different fps caps use different tech . Simply you want to delay your cpu until the next frame. So it goes like that 60 fps-> wait -> 60 fps.

This works somewhat similar to coroutines in unity. But in some game engines the physics engine is just bad. You calculate your physics movement based on delta time and frame latency. So if you delay your cpu with fps cap there is a possibility to break the animations of your world(stutter). For example in unity to deal with this you use the fixedupdate(); function that is independent from different fps.

Most of the 3d gaming engines have very poor FPS management if any. Most common method is "do it as fast as possible" while hardware caps (mainly on GPU side) were keeping those negative effects supressed.

If the FPS cap is implemented in GPU driver I will really spent some time to test it. If it affects CPU side of 3d rendering then it will work for scenario i described. If its GPU side then it will help in scenario when issue is ocurring on Front and Backbuffer, but it should not help if buffer overflows on DirectX.

And then we have external factors such as multithread rendering (not case of Skyrim), hyperthreading and physics acceleration with other hardware (not CPU, nor GPU). These factors mean that generating frames at correct pace is somehow a miracle... To these days I am not sure whether engines use CPU>GPU communication in form where generated frames have timestamp, or there is any response from GPU that image has been accepted (to simplify - differences between TCP and UDP protocol).

These things affect total performance of the system, and vary a lot between different game engines.

Having a FPS cap of any sort, directly on the driver is a move forward. Consoles should work very efficiently and for these purposes are used methods of double buffer, Vsync and FPS Cap, to ensure that no component is doing more work as required for smooth performance.

I just wonder it took so many years.
post #288 of 454
Im pretty sure AMDs implementation throttles to keep frame rates
post #289 of 454
Quote:
Originally Posted by The Mac View Post

Im pretty sure AMDs implementation throttles to keep frame rates

This is not possible. To throttle so you can maintain 60 fps you have to predict before the rendering. And because the rendering is realtime you cant predict.

Iirc it just stays "idle" until the next frame. For example you have in a scene 60 fps. That means 16.7 ms latency. If your actual fps before the cap is like 120 (8.3 ms) that means the gpu will have to wait and delay the cpu for 8.3333 ms .
Workstation
(4 items)
 
  
CPUMotherboardGraphicsMonitor
Xeon E5-2690 Supermicro 2011 Nvidia GP100/ Vega FE Dell ultrasharp 4k 
  hide details  
Reply
Workstation
(4 items)
 
  
CPUMotherboardGraphicsMonitor
Xeon E5-2690 Supermicro 2011 Nvidia GP100/ Vega FE Dell ultrasharp 4k 
  hide details  
Reply
post #290 of 454
Quote:
Originally Posted by The Mac View Post

Im pretty sure AMDs implementation throttles to keep frame rates
Quote:
Originally Posted by sugarhell View Post

This is not possible. To throttle so you can maintain 60 fps you have to predict before the rendering. And because the rendering is realtime you cant predict.

Iirc it just stays "idle" until the next frame. For example you have in a scene 60 fps. That means 16.7 ms latency. If your actual fps before the cap is like 120 (8.3 ms) that means the gpu will have to wait and delay the cpu for 8.3333 ms .

Also, that is very easy to disprove, since simple monitoring of load times and frequency shows that no throttling occurs.
My Rig
(14 items)
 
Ex-wife's Rig
(15 items)
 
 
CPUMotherboardGraphicsRAM
Core i5 4460 AsRock H81M-DG4 Sapphire Rx470 Platinum KVR 1600 16Gb 
Hard DriveHard DriveCoolingOS
2x Seagate 3Tb Samsung 850 EVO 120 Scythe Ninja 3 Rev.B Windows 10 Pro 
MonitorKeyboardPowerCase
Fujitsu Siemens A17-2A Logitech K280e SuperFlower SF-550K12XP Thermaltake Versa H25 
MouseAudio
Logitech G402 Sony MDR XD150 
CPUMotherboardGraphicsRAM
Athlon 750K 4.0Ghz AsRock FM2A75 Pro4+ Sapphire R9 270X Dual-X Kingston 2x4Gb 1600 
Hard DriveHard DriveOptical DriveCooling
Samsung 850 EVO 120  Western Digital 320Gb LiteON DVD-RW CoolerMaster Hyper Z600 
OSMonitorKeyboardPower
Windows 7 Pro x64 Toshiba 32" FullHD TV Logitech FSP Hexa 550 
CaseMouse
DeLUX Logitech 
  hide details  
Reply
My Rig
(14 items)
 
Ex-wife's Rig
(15 items)
 
 
CPUMotherboardGraphicsRAM
Core i5 4460 AsRock H81M-DG4 Sapphire Rx470 Platinum KVR 1600 16Gb 
Hard DriveHard DriveCoolingOS
2x Seagate 3Tb Samsung 850 EVO 120 Scythe Ninja 3 Rev.B Windows 10 Pro 
MonitorKeyboardPowerCase
Fujitsu Siemens A17-2A Logitech K280e SuperFlower SF-550K12XP Thermaltake Versa H25 
MouseAudio
Logitech G402 Sony MDR XD150 
CPUMotherboardGraphicsRAM
Athlon 750K 4.0Ghz AsRock FM2A75 Pro4+ Sapphire R9 270X Dual-X Kingston 2x4Gb 1600 
Hard DriveHard DriveOptical DriveCooling
Samsung 850 EVO 120  Western Digital 320Gb LiteON DVD-RW CoolerMaster Hyper Z600 
OSMonitorKeyboardPower
Windows 7 Pro x64 Toshiba 32" FullHD TV Logitech FSP Hexa 550 
CaseMouse
DeLUX Logitech 
  hide details  
Reply
New Posts  All Forums:Forum Nav:
  Return Home
Overclock.net › Forums › Graphics Cards › AMD/ATI › ATI Drivers and Overclocking Software › AMD GPU Drivers: The Real Truth.