#52 VisualEnvironment with VirtualGL faile save error

closed-out-of-date
nobody
VirtualGL (44)
5
2016-08-08
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.

     
  • DRC

    DRC - 2016-08-08
    • status: open-need-app --> closed-out-of-date
     
  • DRC

    DRC - 2016-08-08

    Closing as out of date. Please re-open on GitHub if you are still experiencing this issue with the latest VirtualGL releases (but I would still need the application in order to reproduce this.)

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks