Has the driver been upgraded recently? Does setting VGL_READBACK=sync work around the problem? Does using a different version of VGL work around it? Suffice it to say that no one else is experiencing this, so I strongly suspect that you'll have better luck filing it as a support request with nVidia. They are familiar with VGL.
On Sep 11, 2014, at 8:46 AM, Stephan Josel <s.jo...@axis-simulation.com> wrote: > > Hi! > > Thanks for your quick reply. Yes, I forgot to mention the card. It's a > Nvidia GPU GT 430 with driver version 334.21. We didn't experience any > of this kind of problem for a long time, it's very strange. > > Thanks, > Stephan > >> I have never seen issues like this with nVidia drivers, and in fact VGL >> is deployed commercially on machines where dozens of users (sometimes >> more) are sharing a GPU. >> >> I have, however, seen multi-instance problems like this with Intel's >> drivers. You didn't specify which GPU and driver revision you are using, >> and that's probably the most relevant piece of information pertaining to >> this issue. >> >>> On Sep 11, 2014, at 6:55 AM, Stephan Josel <s.josel@...> wrote: >>> >>> Hi! >>> >>> Has anyone experienced the following and found a solution? >>> >>> On our server (I set it up as headless X-server on display :0) where vgl >>> is installed user A starts an OpenGL application. Another user (user B) >>> connects to the server and tries to start also the same OpenGL >>> application. However, user B does not get a correct display of the >>> OpenGL application, he rather gets a "damaged" framebuffer or even a >>> black one. If I change the order of start of the application (user B >>> first then user A), the same behavior is there. >>> >>> I did the following to exclude errors: >>> >>> * Check if X :0 has direct rendering: yes >>> * Found no suspicious log entries in the vgl client logs >>> * Reproduced the error with different OpenGL applications >>> >>> It's very strange since this behavior came suddenly. >>> >>> Thanks in advance, >>> Stephan >> ------------------------------------------------------------------------------ >> >>> Want excitement? >>> Manually upgrade your production database. >>> When you want reliability, choose Perforce >>> Perforce version control. Predictably reliable. >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> >>> _______________________________________________ >>> VirtualGL-Users mailing list >>> VirtualGL-Users@... >>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
