NVIDIA
Talks with Andy Currid - The relationship between VSYNC, FRL and frame rate limitations in vGPU 1.1
This is a summary of a discussion with GRID designer Andy Currid, regarding the relationship between VSYNC, FRL, and frame rate limitations in vGPU 1.1: [size="L"][u][b]vGPU Frame Rate Controls[/b][/u][/size] [size="M"][b]VSYNC[/b][/size] [list] [.]The vGPU 1.1 implementation generates a 60Hz VSYNC[/.] [.]Any application that syncs to VSYNC will render at approximately 60Hz*.[/.] [size="S"]*NOTE: This is approximate because in the VSYNC implementation in vGPU 1.1 uses a software timer and there is a fair amount of jitter in the software timer implementation.[/size] [/list] [size="M"][b]Frame Rate Limiter (FRL)[/b][/size] [b]Purpose[/b] [list] [.]A frame rate limiter (FRL) has been implemented in vGPU 1.1 that is independent of VSYNC.[/.] [.]FRL is the primary mechanism that we use in vGPU 1.1 to balance performance across multiple vGPUs executing on the same physical GPU.[/.] [.]Finer-granularity mechanisms may be implemented in future, but FRL is what we use in the current vGPU 1.1 implementation.[/.] [/list] [b]Differences Between Profiles[/b] [list] [.]FRL imposes a maximum frames-per-second that vGPU will render at, even for apps that ignore vsync and choose to render as fast as they can.[/.] [.]The -Q vGPUs have their FRL set to 60Hz.[/.] [.]The non-Q vGPUs (i.e. the K100/K200) have their FRL set to 45fps[/.] [.]Applications that sync to vsync on K100/K200 will still end up rendering at 45fps.[/.] [.]The FRL is set in the vGPU configuration files, which we don’t support end users modifying.[/.] [.]Concessions are made to individuals who are looking to benchmark vGPU and need to disable FRL in order to do that; in the release notes it is documented how to do this.[/.] [/list] [b]60 FPS vs. 45 FPS[/b] [list] [.]We believe that 60fps is the useful maximum that is worth rendering at if you’re ultimately remoting the graphics over a network.[/.] [.]Citrix and VMware both default to 30fps on their remote graphics connections, though both can be configured to sample and remote at 60fps.[/.] [.]There is a latency advantage to rendering at 60fps even if you’re only remoting at 30.[/.] [.]We set the K100/K200 vGPUs to 45fps because those vGPUs support up to 8 vGPUs per physical GPU, and we were skeptical that we can sustain 60fps across 8 vGPUs on the same physical GPU.*[/.] [size="S"]*Note: It is possible we were too conservative in that setting, and we’re definitely open to reviewing that as we get more data about how vGPU performs in the real world.[/size] [/list] [size="M"][b]Why use VSYNC in vGPU[/b][/size] [list] [.]Why do we bother with vsync when we have FRL? Without VSYNC, we would fail WHQL and some applications depend on a VSYNC event being available.[/.] [size="M"][b]Frame Buffer Sampling[/b][/size] [.]AFAIK Citrix does not currently tie their sampling to the rendering rate.[/.] [.]They use a periodic timer to sample the framebuffer using NVFBC.[/.] [.]If the frame has changed since the last sample, they encode and remote it. Otherwise they sleep and sample again[/.] [/list]
This is a summary of a discussion with GRID designer Andy Currid, regarding the relationship between VSYNC, FRL, and frame rate limitations in vGPU 1.1:

vGPU Frame Rate Controls

VSYNC

  • The vGPU 1.1 implementation generates a 60Hz VSYNC
  • Any application that syncs to VSYNC will render at approximately 60Hz*.

  • *NOTE: This is approximate because in the VSYNC implementation in vGPU 1.1 uses a software timer and there is a fair amount of jitter in the software timer implementation.


Frame Rate Limiter (FRL)

Purpose
  • A frame rate limiter (FRL) has been implemented in vGPU 1.1 that is independent of VSYNC.
  • FRL is the primary mechanism that we use in vGPU 1.1 to balance performance across multiple vGPUs executing on the same physical GPU.
  • Finer-granularity mechanisms may be implemented in future, but FRL is what we use in the current vGPU 1.1 implementation.


Differences Between Profiles
  • FRL imposes a maximum frames-per-second that vGPU will render at, even for apps that ignore vsync and choose to render as fast as they can.
  • The -Q vGPUs have their FRL set to 60Hz.
  • The non-Q vGPUs (i.e. the K100/K200) have their FRL set to 45fps
  • Applications that sync to vsync on K100/K200 will still end up rendering at 45fps.
  • The FRL is set in the vGPU configuration files, which we don’t support end users modifying.
  • Concessions are made to individuals who are looking to benchmark vGPU and need to disable FRL in order to do that; in the release notes it is documented how to do this.


60 FPS vs. 45 FPS
  • We believe that 60fps is the useful maximum that is worth rendering at if you’re ultimately remoting the graphics over a network.
  • Citrix and VMware both default to 30fps on their remote graphics connections, though both can be configured to sample and remote at 60fps.
  • There is a latency advantage to rendering at 60fps even if you’re only remoting at 30.
  • We set the K100/K200 vGPUs to 45fps because those vGPUs support up to 8 vGPUs per physical GPU, and we were skeptical that we can sustain 60fps across 8 vGPUs on the same physical GPU.*

  • *Note: It is possible we were too conservative in that setting, and we’re definitely open to reviewing that as we get more data about how vGPU performs in the real world.


Why use VSYNC in vGPU
  • Why do we bother with vsync when we have FRL? Without VSYNC, we would fail WHQL and some applications depend on a VSYNC event being available.

  • Frame Buffer Sampling
  • AFAIK Citrix does not currently tie their sampling to the rendering rate.
  • They use a periodic timer to sample the framebuffer using NVFBC.
  • If the frame has changed since the last sample, they encode and remote it. Otherwise they sleep and sample again

Regards,

Luke Wignall
Performance Engineering Manager
NVIDIA | Worldwide Sales ­ GRID Computing
http://www.linkedin.com/in/lukewignall/
https://twitter.com/lwignall

#1
Posted 09/27/2014 05:28 PM   
Scroll To Top

Add Reply