You have to disable frame spoiling in order for the -fps option to limit
the actual 3D rendering rate:
Did you pass 'sp' to vglrun?
vglrun -sp -fps {f} {application}
I am more keen on the idea of implementing GLX_EXT_swap_control as
opposed to implementing a separate frame rate governor, and I will look
at your patch in detail. However, I also want to understand whether
doing the above (using the existing frame rate governor without frame
spoiling) accomplishes a similar effect and, if not, why not.
On 6/3/13 4:52 PM, Dyweni - VirtualGL-Users wrote:
> Frame spoiling has no effect in my setup. (Maybe you can spot a problem
> in my setup?) Here's how I have things configured:
>
>
> (Game) -> VirtualGL (1) -> TurboVNC Server (2) -> Wire (Ethernet/Cable
> Modem) -> TurboVNC Viewer (3)
>
> (1) Game is run in VirtualGL in order to limit the outgoing FPS that is
> sent across the wire (vglrun -fps x game). To much FPS and the whole
> thing becomes "unresponsive". Limiting the FPS here is the optimal way
> (I've found) to keep the bandwidth used under a specific value. I don't
> want the game traffic to hog all available bandwidth. This is
> especially critical when sending out across the Cable modem as I need to
> avoid the ISP's upload bandwidth capping mechanism.
> (2) TurboVNC Server is used to isolate each game instance. Activity in
> one instance must not be able to interfere with any other instance.
> TurboVNC is run in 1024x768 resolution. This is also required as I want
> the users to be able to connect / disconnect from the game instance on
> the fly, so that the game instance will continue to run even if no one
> is connected to it.
> (3) TurboVNC Viewer is used to display the game instance and control
> quality settings (jpeg compression, subsampling) to fine-tune the
> bandwidth used.
>
>
> In this setup, I use the 'vglrun -fps' to control the bulk of how much
> bandwidth is used, letting the quality settings then fine-tune that a
> bit more. The game still runs at full speed (roughly 118FPS, 100% CPU)
> letting VirtualGL show only x frames per second to the TurboVNC server.
>
> What I am trying to do now is limit the FPS of the game itself, in order
> to drive down its CPU usage. This is where I thought the GLX Swap
> Control interval would come into play.
>
> I should note that the test I ran yesterday was not the best of all
> tests... I was running the game at 2558x975 at 24bits.
>
> I have revised by changes to implement the kind of behaviour I am
> expected from VirtualGL. What I am looking for is for VirtualGL to
> simulate a monitor refresh and emulate GLX's swap control intervals
> itself. It is working pretty well for me, using glxgears as my test
> application. I have implemented GLX_EXT_swap_control, but still need to
> implement WGL_EXT_swap_control. I changed -fps3d to set the virtual
> monitor refresh rate. If not provided, it defaults to 60. Here are the
> new performance marks:
>
>
> (glxgears -interval n)
> INTERVAL FPS CPU
> 0 27000 100%
> 1 60 1%
> 2 30 1%
> 3 20 0%
> 4 10 0%
>
> (vglrun glxgears -interval n)
> INTERVAL FPS CPU
> 0 1122 107%
> 1 57 6%
> 2 29 3%
> 3 19 2%
> 4 15 2%
>
>
> I have attached a new patch for your review / feedback. Any feedback
> would be great.
>
>
>
> ---
> Thanks,
> Dyweni
>
>
> On 2013-06-02 23:36, DRC wrote:
>> But you didn't answer my question. Why can't you achieve the same
>> effect by setting VGL_FPS and disabling frame spoiling? The reason why
>> frame spoiling exists is to make 3D apps feel more "interactive." You
>> can think of it like this: through a remote connection, the mouse and
>> keyboard are probably being sampled at 40-60 fps, and if you're
>> interacting in real time with a 3D app and the image transport
>> pipeline in VGL is unable to keep up with the mouse/keyboard sample
>> rate, then the performance will feel "draggy." Thus, frame spoiling
>> allows the app to render at the speed of the mouse interaction, even
>> though all of those frames may not make it to the client.
>>
>> In your case, though, you have established that the VGL pipeline is
>> capable of 36 fps on your system, so if you're trying to limit the
>> rendering rate to less than that, you are effectively not spoiling
>> frames anyhow. Thus, disabling frame spoiling and setting VGL_FPS
>> should achieve the same effect as your VGL_3DFPS option.
>>
>> On Jun 2, 2013, at 11:09 PM, Dyweni - VirtualGL-Users
>> <t7nhgfds7...@dyweni.com> wrote:
>>
>>> Hi DRC,
>>>
>>> I use VirtualGL / TurboVNC to play multiple instances of the game EVE
>>> Online through a web interface. The web interfaces makes it real easy
>>> to "multi-box". The backend server (where the games all run) does all
>>> the heavy lifting and the lightweight client (netbook, laptop, etc) just
>>> displays the game via the web interface.
>>>
>>> The game has several settings related to syncing with the monitor
>>> refresh rate. They are 'Interval {immediate,one,two,three,four}'.
>>> Interval immediate disables "sync to vblank". Intervals
>>> one/two/three/four enable "sync to vblank" and run at 1, 1/2, 1/3, and
>>> 1/4 the monitor refresh rate.
>>>
>>> When I run the game natively, I get the following performance marks:
>>> Interval FPS CPU
>>> Immediate 230 100%
>>> One 60 18%
>>> Two 30 10%
>>> Three 20 7-8%
>>> Four 15 6%
>>>
>>>
>>> VirtualGL does not support the "sync to vblank" GLX extensions, which
>>> causes the game to be unable to limit its FPS. Here are the performance
>>> marks for the same intervals when running under VirtualGL without my
>>> patch added.
>>> Interval FPS CPU
>>> Immediate 36 93%
>>> One 36 93%
>>> Two 36 93%
>>> Three 36 93%
>>> Four 36 93%
>>>
>>> The patch I posted to the mailing list earlier today, allows the user
>>> to specify what the desired FPS should be. Here are the performance
>>> marks for the same intervals when running under VirtualGL with my patch
>>> added and the fps3d option set to 20.
>>> Interval FPS CPU
>>> Immediate 20 56%
>>> One 20 56%
>>> Two 20 56%
>>> Three 20 56%
>>> Four 20 56%
>>>
>>> As you can see, the patch has made the first step forward towards
>>> allowing the user to run the game at a lower FPS and reclaim some of
>>> that CPU power for other tasks (in my case, more game instances).
>>>
>>> Surprise! In documenting the performance marks tonight, I see my patch
>>> needs a lot more work before I feel comfortable declaring it optimal. I
>>> would have expected to see similar breaks in FPS / CPU that the native
>>> test shows (obviously there will be some differences due to VirtualGL
>>> overhead). Regardless, I was hoping for some feedback. I guess the
>>> artist is his own worst critic!
>>>
>>>
>>>
>>> ---
>>> Thanks,
>>> Dyweni
>>>
>>>
>>> On 2013-06-02 20:53, DRC wrote:
>>>> I am still unclear why the normal mechanism of setting VGL_FPS and
>>>> disabling frame spoiling wouldn't work for you. Have you tried that?
>>>> It's not that I'm opposed to this feature, but I also don't want to
>>>> implement something that isn't actually necessary. Please make a case
>>>> for why VGL_3DFPS solves a problem that couldn't be solved by using
>>>> VGL_FPS with frame spoiling disabled.
>>>>
>>>> On Jun 2, 2013, at 3:58 PM, Dyweni - VirtualGL-Users
>>>> <t7nhgfds7...@dyweni.com> wrote:
>>>>
>>>>> Hi DRC/All,
>>>>>
>>>>> I have mucked around with the VirtualGL 2.3.2 code and have come up
>>>>> with a solution that seems to work well. I have to mention that the
>>>>> solution is rather rough around the edges. Some of the code / ideas
>>>>> were drawn from Mesa's GLXGEARS program (i.e. calculating and
>>>>> reporting the current FPS and the location to do so in).
>>>>>
>>>>> Here is how this works:
>>>>> 1. User provides -fps3d <n> argument to vglrun. N is any double 0 or
>>>>> greater.
>>>>> 2. The function 'glXSwapBuffers' (server/faker-glx.cpp) continually
>>>>> monitors the current fps and adjusts 'delay' to keep the fps around
>>>>> the requested fps value (the fps3d argument).
>>>>> 3. User can tweak the fps3d value via the vglconfig (CTRL+SHIFT+F9)
>>>>> GUI utility.
>>>>>
>>>>> I am sure that the algorithm for adjusting the delay can be improved.
>>>>> It was what I could come up with in the limited time I had today.
>>>>>
>>>>> I have attached a patch that applies to VirtualGL 2.3.2. Please feel
>>>>> free to review / test and provide feedback.
>>>>>
>>>>> ---
>>>>> Thanks,
>>>>> Dyweni
>>>>>
>>>>>
>>>>> On 2012-07-26 13:41, DRC wrote:
>>>>>> Since VirtualGL redirects the 3D rendering into offscreen buffers,
>>>>>> there
>>>>>> is no concept of VSync, because there is no monitor involved until
>>>>>> the
>>>>>> pixels are drawn on the client machine, and by that time, the 3D
>>>>>> rendering is already done.
>>>>>> In the current implementation, there is no way to limit the 3D
>>>>>> rendering
>>>>>> rate except to disable frame spoiling. Disabling frame spoiling
>>>>>> couples
>>>>>> the 3D rendering and compress/send stages of the pipeline, so the
>>>>>> frame
>>>>>> rate will be the lesser of (a) the VGL_FPS setting or (b) the rate
>>>>>> at
>>>>>> which the client can process frames. However, that's probably not
>>>>>> what
>>>>>> you want, because you may experience "mouse lag" when frame spoiling
>>>>>> is
>>>>>> disabled.
>>>>>> This issue has never come up, because in visualization apps, the
>>>>>> frame
>>>>>> rate is ultimately limited by the sampling rate of the mouse, which
>>>>>> is
>>>>>> generally 40-60 Hz. I'm honestly not sure what would be the best
>>>>>> approach to applying a frame rate governor on the 3D side (a
>>>>>> VGL_3DFPS
>>>>>> option, if you will.) It might be as simple as putting a delay into
>>>>>> the
>>>>>> buffer swap function.
>>>>>> What I'm wondering, however, is whether our long-term plans to
>>>>>> replace
>>>>>> Pbuffers with FBO's and hidden windows might magically fix this,
>>>>>> since
>>>>>> VSync might still work when rendering to a hidden window.
>>>>>> If anyone else has further insight, please share.
>>>>>> On 7/26/12 12:56 PM, Dyweni - VirtualGL-Users wrote:
>>>>>>> Hi All,
>>>>>>> I'm wondering if VirgualGL has support for VSync? I know that
>>>>>>> VirtualGL
>>>>>>> has support to output only x frames per second, but that is
>>>>>>> different
>>>>>>> from VSync.
>>>>>>> I have a game (EVE Online) that can limit itself to the VSync. In
>>>>>>> normal X, it limits itself to 60 FPS (my monitor refresh rate)
>>>>>>> thanks to
>>>>>>> VSync, and that keeps the CPU usage low. However, when running on
>>>>>>> VirtualGL, it does not limit its FPS and they skyrocket to 120+ FPS
>>>>>>> which drives the CPU usage high.
>>>>>>> I would like to be able to lock the game to the VSync (say 60 FPS,
>>>>>>> to
>>>>>>> keep the CPU usage low) and then export x frames per second (as I
>>>>>>> do
>>>>>>> know with the -fps) switch.
>>>>>>> Is this possible?
>>>>>>> --
>>>>>>> Thanks,
>>>>>>> Dyweni
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>> Live Security Virtual Conference
>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>>> Discussions
>>>>>>> will include endpoint security, mobile security and the latest in
>>>>>>> malware
>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>> _______________________________________________
>>>>>>> VirtualGL-Users mailing list
>>>>>>> VirtualGL-Users@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>> Discussions
>>>>>> will include endpoint security, mobile security and the latest in
>>>>>> malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> VirtualGL-Users mailing list
>>>>>> VirtualGL-Users@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>>>>> <0001-Support-limiting-3D-application-framerate-into-Virtu.patch>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>>>>> It's a free troubleshooting tool designed for production
>>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>>> Download for free and get started troubleshooting in minutes.
>>>>> http://p.sf.net/sfu/appdyn_d2d_ap2
>>>>> _______________________________________________
>>>>> VirtualGL-Users mailing list
>>>>> VirtualGL-Users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>>>> It's a free troubleshooting tool designed for production
>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>> Download for free and get started troubleshooting in minutes.
>>>> http://p.sf.net/sfu/appdyn_d2d_ap2
>>>> _______________________________________________
>>>> VirtualGL-Users mailing list
>>>> VirtualGL-Users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>>> It's a free troubleshooting tool designed for production
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>> http://p.sf.net/sfu/appdyn_d2d_ap2
>>> _______________________________________________
>>> VirtualGL-Users mailing list
>>> VirtualGL-Users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>>
>> ------------------------------------------------------------------------------
>>
>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>> It's a free troubleshooting tool designed for production
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap2
>> _______________________________________________
>> VirtualGL-Users mailing list
>> VirtualGL-Users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
>
> _______________________________________________
> VirtualGL-Users mailing list
> VirtualGL-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
