#52 VisualEnvironment with VirtualGL faile save error

[gacho]

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

[DRC]

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]

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]

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]

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]

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.

[DRC]

Please try the latest pre-release build and see if it fixes the issue:

http://www.virtualgl.org/DeveloperInfo/PreReleases

[gacho]

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]

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]

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]

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]

>. 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]

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]

>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]

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]

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]

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

[DRC]

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.)