#52 VisualEnvironment with VirtualGL faile save error

open-need-app
nobody
VirtualGL (44)
5
2015-06-04
2012-08-20
gacho
No

Hello, I use VisualEnvironment with VirtualGL and TurboVNC .
I save the image to a file (jpeg,png,gif) , but the file is incorrect

Environment is this

- VirtualGL-2.3.80-20120807
- turbovnc-1.0-20101020

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
# uname -a
Linux localhost.localdomain 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
]# cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 256.53 Fri Aug 27 20:27:48 PDT 2010
GCC version: gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)
# cat /proc/driver/nvidia/cards/0
Model: Quadro FX 4600
IRQ: 74
Video BIOS: 60.80.0e.00.01
Card Type: PCI-E
DMA Size: 40 bits
DMA Mask: 0xffffffffff
Bus Location: 0000:85.00.0

Is this Bug ??

PS.
Sorry , ID 3559750 is same Question.
I change my account , so I want to delete ID 3559750

thanks

Discussion

  • gacho
    gacho
    2012-08-20

    • labels: --> VirtualGL
    • milestone: --> VirtualGL: Application-specific issue
     
  • DRC
    DRC
    2012-08-20

    I have never heard of the application in question. I had to google it. Generally, with commercial apps, it's difficult to track down application-specific problems without getting the application in house. I will run through some basic troubleshooting steps with you, but if the problem isn't obvious, then it's unfortunately something that will require a paid support agreement in order to solve.

    The first thing I will ask you to do is run the application with tracing enabled (vglrun +tr) and post the output. You can also e-mail me the images if they are too big to go here. The e-mail link is on the VirtualGL.org web page.

     
  • gacho
    gacho
    2012-08-20

    Thank you for reply. 

    > application-specific problems without getting the application in house. I
    >will run through some basic troubleshooting steps with you,
    OK,I understand . it is enough.

    >The first thing I will ask you to do is run the application with tracing
    >enabled (vglrun +tr)
    OK.

    I e-mail you the images and trace log .

    Thanks.

     
  • DRC
    DRC
    2012-08-20

    As suspected, it appears that the application is using Pixmap rendering. Interposing Pixmap rendering has always been tricky in VirtualGL, and generally, we have just handled it on a case-by-case basis as issues have arisen. Our current implementation is fairly comprehensive and was implemented to fix issues with Mathematica, but apparently it still has a bug that is revealed in Visual-Environment.

    Since VirtualGL substitutes Pbuffers whenever the application requests to render to a Pixmap, it appears that there may be a mismatch in the pixel format that the app is expecting vs. what we're rendering. Going any farther is going to require access to the app, because I need to set a bunch of checkpoints in the VGL code and try to figure out why the mismatch is occurring.

     
  • gacho
    gacho
    2012-08-21

    Thank you for checking logs.

    >Going any farther is going to require access to the app, because I need to >set a bunch of checkpoints in the VGL code and try to figure out why the >mismatch is occurring.
    I see. It is difficult .

    I contact application vendor and request for cooperation.

     
  • DRC
    DRC
    2012-08-23

    It is possible that a patch I just checked into the subversion trunk fixed this. It was related to VirtualGL not properly handling all of the possible OpenGL states that could affect pixel readback or copying. I'll provide a pre-release build with this fix soon.

     
  • gacho
    gacho
    2012-08-24

    Thank you for new patch.
    Unfortunately, image file is incorrect.

    1. Uninstall old package (VirtualGL-2.3.80-20120807)
    2. Install new package(VirtualGL-2.3.80-20120823)
    3. Run vglserver_config
    4. Run Application with vglrun & save image files

     
  • DRC
    DRC
    2012-09-07

    We fixed another issue with Pixmap rendering that may have been related to this. It was causing a similar symptom in another application (when a user tried to save an image from the application, the pixels were corrupted.) Please re-test with the latest nightly build to see if, by some chance, this fixed the VisualEnvironment issue as well.

    http://virtualgl.sourceforge.net/vgl.nightly/

     
  • gacho
    gacho
    2012-09-07

    thank you for information.
    I run application with latest VirtualGL(ver 2.3.80-20120907).

    It is improved very much than previous version, But only a little is incorrect.
    Really a little , But I want to use correct image

    I e-mail you image files.

     
  • DRC
    DRC
    2012-09-10

    I am returning the conversation to the bug tracker, so there is a record of it. From the image files you sent, it appears that what is happening now is that, whenever VirtualGL is active, saving the 3D view to an image file will produce an image file that has the same background colors and axis indicators as the 3D view, and the same font spacing, etc. However, the numbers displayed in the image are, in places, incorrect. Without VirtualGL, saving the 3D view to an image file will produce an image file that has a white background, better font spacing, a simpler axis indicator, and correct numbers, and it seems that this is what the application intends (the image is probably meant to be "printer-ready.")

    From the trace log, it appears that the app is simply calling glXCreateGLXPixmap() to register the Pixmap with GLX, then doing front-buffer OpenGL rendering to the Pixmap, and it's apparently then calling XGetImage() to read back the results. I am having trouble understanding why the mere presence of VirtualGL would cause it to behave differently.

    My best suggestion at this point is to build apitrace (https://github.com/apitrace/apitrace) and use it to capture a trace of your application running without VirtualGL. If you can acquire an OpenGL/GLX trace of the application through the point at which it saves the correct image file, then you can send me the trace, and I should be able to use it to reproduce the issue here, as well as see all of the X11 and OpenGL calls that are involved in saving the image.

    Apart from that, I will have to obtain the application to do any further debugging.

     
  • gacho
    gacho
    2012-09-13

    >. If you can acquire an OpenGL/GLX trace of the application through
    > the point at which it saves the correct image file,
    > then you can send me the trace,
    I build apitrace ,and get tracelog. but tracelog size is too big to send.
    ( file size is about 37GB...)
    So I run apitrace dump , and write the dump data to text file now.
    It is over 120 million line, and continue to increase.
    If I can split text file , I will e-mail .

    If you know other good method about apitrace, Please let me know.

    Thank you.

     
  • DRC
    DRC
    2012-09-13

    Look for a sequence of calls between glXCreateGLXPixmap (there should be only one of those) and the nearest glXDestroyContext() call after it. Those are the calls that create the pixmap for saving the image and render the scene to it. If you can copy/paste just those calls into a separate file and send them, it may help me to determine what is going on.

     
  • gacho
    gacho
    2012-09-19

    >Look for a sequence of calls between glXCreateGLXPixmap (there should be
    only one of those) and the nearest glXDestroyContext() call after it.

    I finished separating tracelog, so I e-mail.

    I searched the tracelog, but there is no line including glXCreateGLXPixmap and glXDestroyContext.
    Functions are these.

    function name the number of times that was called
    ------------------------ ---------------------
    glBegin 11916905
    glBindFramebufferEXT 10
    glBindTexture 296
    glBitmap 1715
    glBlendFunc 1322
    glCallLists 4418
    glCheckFramebufferStatusEXT 4
    glClear 328
    glClearColor 170
    glClearDepth 162
    glClearStencil 158
    glColor3f 2224
    glColor3ub 3
    glColor4f 4714938
    glColor4ub 1564
    glColor4ubv 4418
    glColorPointer 2386
    glDeleteFramebuffersEXT 2
    glDeleteLists 7
    glDeleteTextures 4
    glDepthFunc 320
    glDepthMask 1230
    glDepthRange 4
    glDisable 73229
    glDisableClientState 8
    glDrawBuffer 24
    glDrawElements 2386
    glDrawPixels 348
    glEnable 138627
    glEnableClientState 8
    glEnd 11916905
    glEndList 2219
    glFinish 4
    glFlush 158
    glFramebufferTexture2DEXT 4
    glGenFramebuffersEXT 2
    glGenLists 33
    glGenTextures 6
    glGetBooleanv 2651
    glGetDoublev 4120
    glGetError 423
    glGetFloatv 3117
    glGetIntegerv 107003
    glHint 312
    glIndexMask 457
    glLightModelf 316
    glLightModelfv 158
    glLightModeli 102716
    glLightfv 1264
    glLineWidth 1702
    glListBase 4418
    glLoadIdentity 5313
    glLoadMatrixf 474
    glMaterialf 818
    glMaterialfv 2330
    glMatrixMode 14672
    glMultMatrixd 310
    glMultMatrixf 579
    glNewList 2219
    glNormal3d 1896
    glNormal3dv 17064
    glNormal3f 25410
    glNormal3fv 178935301
    glOrtho 2508
    glPixelStorei 387
    glPixelZoom 696
    glPointSize 7249603
    glPolygonMode 771
    glPolygonOffset 8
    glPolygonStipple 4
    glPopAttrib 4905
    glPopClientAttrib 4
    glPopMatrix 5578
    glPushAttrib 4905
    glPushClientAttrib 4
    glPushMatrix 5578
    glRasterPos2i 348
    glRasterPos3f 4418
    glReadPixels 4
    glRotatef 308
    glScalef 139
    glShadeModel 103025
    glTexCoord1f 153829134
    glTexEnvi 6
    glTexImage1D 6
    glTexImage2D 4
    glTexParameterf 8
    glTexParameteri 38
    glTranslated 1685
    glTranslatef 2161
    glVertex2f 14328
    glVertex2fv 924
    glVertex2i 12
    glVertex3dv 53088
    glVertex3f 11035346
    glVertex3fv 712276894
    glVertexPointer 2386
    glViewport 837
    glXWaitGL 164
    glXWaitX 158

     
  • DRC
    DRC
    2013-07-20

    There have been significant changes to VirtualGL's handling of Pixmap rendering since 2.3.2. Can you test the latest build and see if it fixes this issue?
    http://virtualgl.sourceforge.net/vgl.nightly/

     
  • gacho
    gacho
    2013-08-14

    Hi. Thank you for your information.
    I try new VirtualGL (2.3.3).

    # rpm -qa | grep VirtualGL
    VirtualGL-2.3.3-20130724.x86_64

    But, can not fix my problem...

    Thanks.

     
  • DRC
    DRC
    2014-03-28

    • status: open --> open-need-app
     
  • DRC
    DRC
    2015-06-04

    Have you tested this with the latest VirtualGL releases or pre-releases? Wondering if it is still occurring.