Bug 95266

The "Reproduction of issue" attachment is a tar.bz2 file, btw. When I try to download it it just dumps the binary as character data to my browser...Let me know if I should re-upload it and do something differently.

You might consider including an apitrace that reproduces the issue. People are probably going to be less inclined to run some random binary off the interwebs.

Also, is this only a bug with llvmpipe (and/or gallivm), or have you tested this with various hw drivers in mesa? (Sorry, your wrote a lot of text and I only skimmed it.)

I included an apitrace on the last bug, and was told that it was not suitable for reproducing bugs (something about apitrace forcing a 4.5 context IIRC). I can make one for this issue if anyone needs it.

I share concerns about running random binaries, and have included instructions for building VTK from official sources to reproduce the issue for the more wary developers among us :)

I've only tested using the mesa configuration options provided in the report. If there are other configurations you'd like me to test, I'd be happy to do so. Just let me know the exact options to specify -- mesa's configure options are a bit of a black box to me.

(In reply to David Lonie from comment #3)
> I included an apitrace on the last bug, and was told that it was not
> suitable for reproducing bugs (something about apitrace forcing a 4.5
> context IIRC). I can make one for this issue if anyone needs it.

Looking at it...

2 @0 glXCreateContextAttribsARB(dpy = 0x6c4f20, config = 0x72c1c0, share_context = NULL, direct = True, attrib_list = [GLX_CONTEXT_MAJOR_VERSION_ARB, 4, GLX_CONTEXT_MINOR_VERSION_ARB, 5, 0]) = 0x74cf10

don't do that? :) Mesa does not support GL 4.5, was that trace captured on some proprietary driver that does? Can you change VTK (even temporarily) to only request GL 3.0? Or alternatively flip to requesting a core context (which that trace isn't doing) and request GL 3.2?

FWIW I was able to run your trace from the other bug with

MESA_GL_VERSION_OVERRIDE=4.5 MESA_GLSL_VERSION_OVERRIDE=450

so I suspect that a trace of this issue would be nice to have as well.

(In reply to David Lonie from comment #3)
> I included an apitrace on the last bug, and was told that it was not
> suitable for reproducing bugs (something about apitrace forcing a 4.5
> context IIRC). I can make one for this issue if anyone needs it.

I agree a trace would be useful.

If the issue repros with Mesa + llvmpipe, then just record the trace with Mesa + llvmpipe.

If you don't record the trace with the exact same OpenGL implementation, then all sort of things can go wrong.

I'm trying to get a trace, but apitrace is failing an assertion:

$ apitrace trace --api gl bin/vtkRenderingCoreCxxTests "TestTranslucentLUTDepthPeeling"                                                                                                         

vtkRenderingCoreCxxTests: /build/apitrace/src/apitrace-7.1/build/wrappers/glxtrace.cpp:97195: void (* _wrapProcAddress(const GLubyte*, __GLXextFuncPtr))(): Assertion `procPtr != (__GLXextFuncPtr)&glXCreateContextAttribsARB' failed.

This is only happening on Mesa (I get a successful trace using my system nVidia drivers), and it also happens when following the "Trace manually" instructions here:

https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown#tracing-manually

Is this issue familiar to anyone? I'll keep trying to get this working, but would appreciate any tips if this is a known issue :)

(In reply to David Lonie from comment #7)
> Is this issue familiar to anyone? I'll keep trying to get this working, but
> would appreciate any tips if this is a known issue :)

It looks like apitrace is about to enter an infinite loop: the address of the supposedly "real" glXCreateContextAttribsARB function is actually pointing to the fake glXCreateContextAttribsARB wrapper function.

I'll take a look.  Thanks for trying.


It looks like doing `MESA_GL_VERSION_OVERRIDE=4.5 glretrace -S frame vtkRenderingOpenGL2CxxTests.4075.trim.trace` works.

FWIW it was not the samplers returning NaN for the float texture, but rather the _coords_ being NaNs (thus the results from sampling could be anything, though it is possible some implementations would use 0.0 as coord instead). But those coords came from the vs, which seemed simple enough. So possibly the NaNs might have been the result of a previous render pass. (It is of course also possible some shader is simply bogus and relying on NaNs getting flushed to zero somewhere on output.)
It would indeed be helpful to know if hw drivers are affected too.
(Using vtk sources to reproduce is pretty easy.)

(In reply to Jose Fonseca from comment #8)
> It looks like apitrace is about to enter an infinite loop: the address of
> the supposedly "real" glXCreateContextAttribsARB function is actually
> pointing to the fake glXCreateContextAttribsARB wrapper function.
> 
> I'll take a look.  Thanks for trying.
> 
> 
> It looks like doing `MESA_GL_VERSION_OVERRIDE=4.5 glretrace -S frame
> vtkRenderingOpenGL2CxxTests.4075.trim.trace` works.

I suspect problem is that you're loading Mesa libGL.so via LD_PRELOAD. From attached mesa_bug.tar.bz2:

  $ cat run-mesa.sh 
  #!/bin/bash
  
  echo "Running test against mesa libGL."
  LD_PRELOAD=libGL.so ./vtkRenderingCoreCxxTests "TestTranslucentLUTDepthPeeling" -I

This will defintely interfere with apitrace since apitrace needs to use LD_PRELOAD to inject.

The proper way of using a custom libGL.so is to simply set LD_LIBRARY_PATH to the directory that has it:

  ln -sf libGL.so libGL.so,1
  LD_LIBRARY_PATH=$PWD ./vtkRenderingCoreCxxTests "TestTranslucentLUTDepthPeeling" -I

and all should work fine.

Created attachment 123472 [details]
TestTranslucentLUTDepthPeeling.trace

Trace.

(In reply to Jose Fonseca from comment #10)
> The proper way of using a custom libGL.so is to simply set LD_LIBRARY_PATH
> to the directory that has it:
> 
>   ln -sf libGL.so libGL.so,1
>   LD_LIBRARY_PATH=$PWD ./vtkRenderingCoreCxxTests
> "TestTranslucentLUTDepthPeeling" -I

Just tried that here, no such luck: 

$ ln -s libGL.so libGL.so.1
$ LD_LIBRARY_PATH=$PWD:$LD_LIBRARY_PATH apitrace trace --api gl ./vtkRenderingCoreCxxTests "TestTranslucentLUTDepthPeeling"                                                                                       
apitrace: loaded into /usr/bin/apitrace                                                                                                
apitrace: unloaded from /usr/bin/apitrace                                                                                              
apitrace: loaded into /ssd/src/VTK/build-tmp/mesa_bug/vtkRenderingCoreCxxTests                                                         
apitrace: tracing to /ssd/src/VTK/build-tmp/mesa_bug/vtkRenderingCoreCxxTests.18.trace                                                 
vtkRenderingCoreCxxTests: /build/apitrace/src/apitrace-7.1/build/wrappers/glxtrace.cpp:97195: void (* _wrapProcAddress(const GLubyte*, __GLXextFuncPtr))(): Assertion `procPtr != (__GLXextFuncPtr)&glXCreateContextAttribsARB' failed.

Looks like you did get a trace from it, though, so I wonder what's different. Thanks for uploading that, hopefully that will make it easier to track down!

FWIW this is what it looks like on i965: http://i.imgur.com/LMmcGkM.png

I'm guessing that's correct, but the "correct" screenshot is inside an archive and I'm lazy. It is indeed totally messed up with llvmpipe.

(In reply to Ilia Mirkin from comment #13)
> FWIW this is what it looks like on i965: http://i.imgur.com/LMmcGkM.png
> 
> I'm guessing that's correct, but the "correct" screenshot is inside an
> archive and I'm lazy. It is indeed totally messed up with llvmpipe.

Yep, that's what it should look like.

Just pointing out something that may not be that obvious - David is using the xlib powered gallium libGL. That one uses the (iirc) unsupported split shared LLVM libraries.

(In reply to David Lonie from comment #12)
> Just tried that here, no such luck: 
> 
> $ ln -s libGL.so libGL.so.1
> $ LD_LIBRARY_PATH=$PWD:$LD_LIBRARY_PATH apitrace trace --api gl
> ./vtkRenderingCoreCxxTests "TestTranslucentLUTDepthPeeling"                 
> 
> apitrace: loaded into /usr/bin/apitrace                                     

apitrace is being injected into apitrace...

This can only happen if you have stuff you shouldn't have on LD_PRELOAD and LD_LIBRARY_PATH variables...  :-/

Please start from a clean terminal.  Don't do anything other than I described.  In particular don't set LD_PRELOAD, and only set LD_LIBRARY_PATH=$PWD.

Honestly it's better not to fiddle with LD_PRELOAD directly yourself at all.  It just makes everything unnecesarily harder.  Just let the `apitrace trace` command do it.


I repeat: 

- the right way of loading libGL.so is to set LD_LIBRARY_PATH=/path/to/where/libGL.so.1/lives/

- the right way of tracing is to `apitrace trace myapp`

- and the right way of doing both is to

  export LD_LIBRARY_PATH=/path/to/where/libGL.so.1/lives/
  apitrace trace myapp


(Also note, the right name for libGL is not libGL.so as you had in the tarball.  It needs to be libGL.so.1.  I suspect that this mismatch is what lead you to resort to LD_PRELOAD to start with.  But if the name is libGL.so.1 that should never be necessary.)

Thanks for the info Jose, I'll make a note of that for the future.

And to further confirm, trace replays fine on both a GF108 and GT215 with nouveau's nvc0 and nv50 drivers. So this is a gallivm issue, not mesa. Adjusting subject.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/240.