Yes, flickering does occur with VGL 2.3. It does go away when I switch to software opengl.
2014-02-28 18:39, DRC skrev: > OK, fair enough. I'm working with Altair in parallel to try and > diagnose this, and they've confirmed that the infinite loop issue occurs > with VGL 2.3.3, but I'm trying to nail down whether the flickering issue > is also VirtualGL's fault. Can you confirm whether the flickering > occurs with VGL 2.3 and if it goes away when you switch to software OpenGL? > > Altair is sending me a demo license for HM so I can diagnose this on my > end. I suspect that it's entirely a VGL issue, so the use of ThinLinc > vs. TurboVNC probably doesn't matter. > > > On 2/28/14 4:09 AM, Patrik Pira wrote: >> Oh you mean turbovnc viewer. I read hypermesh viewer... >> >> We are not using turbovnc. We use Cendio's thinlinc (version 4.0). Their >> tigervnc Xvnc support softare glx so if I run hypermesh without vglrun >> it works okay albeit slower. >> >> 2014-02-28 09:41, DRC skrev: >>> You mean the native Windows viewer? Which version? And also, which >>> version of the TurboVNC server are you using? >>> >>> >>> On 2/28/14 1:12 AM, Patrik Pira wrote: >>>> I wasn't aware of that there is a java viewer also. I use the native one >>>> when the problem appears. >>>> >>>> I start it with: >>>> >>>> $ vglrun hm >>>> >>>> In the end, the file "hmopengl" is executed which is native 64-bit code. >>>> >>>> To reproduce deadlock, create a 1-dimensional, standard section, HYPER >>>> BEAM, thinwalled box. After pressing "create", process will deadlock >>>> during painting of next HyperBeam window. >>>> >>>> Hypermesh 12.0 will produce some initial flickering when painting the >>>> Hyperbeam window. Hypermesh 11.0 has no visual anomalies as far as I can >>>> see. >>>> >>>> 2014-02-27 19:59, DRC skrev: >>>>> Altair is looking into it. Are the visual anomalies specific to a >>>>> particular viewer? Do you, for instance, see them with both the Java >>>>> and the native viewer on a particular platform? >>>>> >>>>> >>>>> On 2/27/14 1:17 AM, Patrik Pira wrote: >>>>>> I also tried hypermesh 11.0 and it also deadlocks with VirtualGL 2.3.3. >>>>>> Works fine when downgrading to VirtualGL 2.3. >>>>>> >>>>>> 2014-02-26 20:24, Patrik Pira skrev: >>>>>>> Hypermesh 12.0, which seems to be the latest version released according >>>>>>> to their website. >>>>>>> >>>>>>> We use NVIDIA cards, I believe these servers have a Quadro 4000 or >>>>>>> similar card. Driver version 310 or 320 something on RHEL6 x86_64. I am >>>>>>> not at work right now so I can't check the exact version. >>>>>>> >>>>>>> As it works (mostly) okay with VirtualGL 2.3 but not with VirtualGL >>>>>>> 2.3.3 (nor with 2.3.2) it looks to me like a regression in recent >>>>>>> versions of VirtualGL. >>>>>>> >>>>>>> 2014-02-26 20:10, DRC skrev: >>>>>>>> What version of HyperMesh? Altair actively sells VirtualGL and >>>>>>>> TurboVNC >>>>>>>> as part of their grid service offering, so I know that it has been >>>>>>>> tested. The only possibility is that a new version came out that broke >>>>>>>> something, or perhaps there is something different about your >>>>>>>> environment. >>>>>>>> >>>>>>>> What graphics adapter and driver version are you running? >>>>>>>> >>>>>>>> >>>>>>>> On 2/26/14 3:47 AM, Patrik Pira wrote: >>>>>>>>> Hello >>>>>>>>> >>>>>>>>> I'm having problems running Altair hypermesh with the latest version >>>>>>>>> of >>>>>>>>> VirtualGL (2.3.3). Application sort of deadlocks when creating a >>>>>>>>> hyperbeam section and rapidly just redraws the opengl drawing area >>>>>>>>> without responding to input. Only way out is to kill the process. >>>>>>>>> >>>>>>>>> After some maillist archive reading I figured out that this issue was >>>>>>>>> fixed with the changelog entry below. >>>>>>>>> >>>>>>>>> =============================================================================== >>>>>>>>> 2.3 beta1 >>>>>>>>> =============================================================================== >>>>>>>>> [1] >>>>>>>>> Re-fixed issue that caused MainWin-based applications to hang. This >>>>>>>>> was >>>>>>>>> initially fixed in VGL 2.1 final, but it was re-broken by the rewrite >>>>>>>>> of the >>>>>>>>> global faker configuration routines in VGL 2.2. >>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> So I installed VirtualGL 2.3 and suddenly it worked. It's not very >>>>>>>>> pretty with some spurious flickering in the opengl drawing area, but >>>>>>>>> it >>>>>>>>> works. >>>>>>>>> >>>>>>>>> I also tried all the other application reciepe workarounds with >>>>>>>>> virtualgl 2.3.3 but they had no impact. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Patrik Pira > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
