Created attachment 416 [details]
standard log for TestGLAutoDrawableFactoryOffscrnCapsNEWT
I'm trying to run jogl on a Ubuntu VM using Xvfb/Mesa and have problems with pbuffers.
I downloaded and extracted the latest aggregated build  and ran the following tests (after I added the missing junit jars to the jar/ folder):
java -cp "jar/junit-4.10.jar:jar/ant-junit-1.7.1.jar:jar/ant-1.7.1.jar:jar/gluegen-rt.jar:jar/jogl-all.jar:jar/jogl-test.jar" com.jogamp.opengl.test.junit.jogl.acore.TestGLAutoDrawableGLWindowOnOffscrnCapsNEWT
Tests run: 28, Failures: 3 (testGL2OffScreenPbufferDblBuf, testGL2OffScreenPbufferSglBuf, testGL2OffScreenBitmapSglBuf)
java -cp "jar/junit-4.10.jar:jar/ant-junit-1.7.1.jar:jar/ant-1.7.1.jar:jar/gluegen-rt.jar:jar/jogl-all.jar:jar/jogl-test.jar" com.jogamp.opengl.test.junit.jogl.acore.TestGLAutoDrawableFactoryOffscrnCapsNEWT
Tests run: 18, Failures: 5 (testGL2OffScreenBitmapSglBuf, testGL2OffScreenPbufferSglBuf, testGL2OffScreenPbufferDblBuf, testGL2OffScreenFBODblBufStencilMSAA, testGL2OffScreenFBODblBufMSAA)
For both test runs I attached the log files (with and without -Dnewt.debug=all -Dnativewindow.debug=all -Djogl.debug=all).
Created attachment 417 [details]
Debug log for TestGLAutoDrawableFactoryOffscrnCapsNEWT
Created attachment 418 [details]
standard log for TestGLAutoDrawableGLWindowOnOffscrnCapsNEWT
Created attachment 419 [details]
debug log for TestGLAutoDrawableGLWindowOnOffscrnCapsNEWT
Created attachment 420 [details]
runtime version check
Created attachment 421 [details]
runtime debug test
Created attachment 422 [details]
all rendered images saved by the two test suites
Just a small note, I can reproduce this issue on the Travis CI VM's:
ardor3d-screenshot is a library of mine where I use newt offscreen. I just tested it with the FBO flag and the tests ran through, I have to check the actual renderings though, because in the past I had some troubles with FBO on my Desktop machine. But anyway, this is just a side note, the real question is to find out why pbuffers aren't working.
Interesting that pbuffer doesn't work
despite the fact that the GLX config lists it.
GL_VENDOR VMware, Inc.
GL_RENDERER Gallium 0.4 on llvmpipe (LLVM 0x300)
GL_VERSION 2.1 Mesa 8.0.2
So this is a vmware machine I assume, using their drivers.
Maybe this virtual GL driver somewhat is broken ?
-> javax.media.opengl.GLException: pbuffer creation error: glXCreatePbuffer() failed
How about trying to run a native pbuffer test ?
Since the pbuffer API is pretty straightforward and simple,
I doubt that a native application behaves differently.
Best bet, it's a vmware problem ..
Note: Good that FBO works, which is the default for offscreen now anyways.
Created attachment 432 [details]
TestGLAutoDrawableGLWindowOnOffscrnCapsNEWT Log on VBox Mesa 8.0.5
Ok, tested on a vbox debian7:
GL_RENDERER = Gallium 0.4 on llvmpipe (LLVM 0x209)
GL_VERSION = 2.1 Mesa 8.0.5
GL_VENDOR = VMware, Inc.
pbuffer works there w/ master tip, i.e.:
Please retry .. it's odd that the test behave so different, I will attach my test.log of said machine
w/ same build.
Created attachment 433 [details]
test log vbox mesa 8.0.5
Hmm interesting. I don't know if its VMware, probably not, it's an Amazon EC2 instance. The GL_VENDOR just says VMware because they (and Intel IIRC) are the main developers of this software renderer. In Travis CI tests, the VMs are actually VirtualBox VMs, again with the same GL_VERSION string and vendor.
I just upgraded my Mesa version from 8.0.2 to 8.0.4 but saw no change. 8.0.5 isn't in Ubuntus official repos yet and installing from an inofficial ppa just screwed it up completely on my VM, so I reverted to 8.0.4. Also, I can't really find anything on http://www.mesa3d.org/relnotes-8.0.5.html related to pbuffers.
Can you downgrade to 8.0.4 and try it again? Just to confirm it's not the version difference.
I just loaded the mesa-demos from git://anongit.freedesktop.org/git/mesa/demos and ran src/xdemos/glxpbdemo 400 400 test.ppm which creates a pbuffer (using glXCreatePbuffer) of size 400x400 and writes an image to test.ppm. The output was:
root@vm129:/gllibs/demos/src/xdemos# ./glxpbdemo 400 400 test.ppm
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
Chose 0x69 as fbconfigid
failed to create drawable
Error: couldn't create pbuffer
The first two lines are just (normal) debug lines I got by setting LIBGL_DEBUG=verbose.
So... it's definitely not a bug in jogl. But maybe we can still figure out what's wrong.
(In reply to comment #13)
> I just loaded the mesa-demos from
> git://anongit.freedesktop.org/git/mesa/demos and ran src/xdemos/glxpbdemo
> 400 400 test.ppm which creates a pbuffer (using glXCreatePbuffer) of size
> 400x400 and writes an image to test.ppm. The output was:
> root@vm129:/gllibs/demos/src/xdemos# ./glxpbdemo 400 400 test.ppm
> libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
> libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
> Chose 0x69 as fbconfigid
> failed to create drawable
> Error: couldn't create pbuffer
> The first two lines are just (normal) debug lines I got by setting
> So... it's definitely not a bug in jogl. But maybe we can still figure out
> what's wrong.
Sure .. if I could reproduce it. But this would involve debugging Mesa itself,
since the API being used is quite simple and nothing to see here.
IMHO this is better suited to be discussed in Mesa3D's space,
i.e. their bugreport system / mailinglists etc.
I will close this bug now, however, feel free to continue sending updates here
and we can discuss it.
> Can you downgrade to 8.0.4 and try it again? Just to confirm it's not the version difference.
That would take too much time for me to confirm a fixed bug, i.e. when it's working w/ Mesa 8.0.5
as being delivered w/ Debian 7 (Wheezy) .. as I have tested.
Ubuntu also uses patches of their own, which may break things - we have experienced this ..
Why don't you install Debian 7 Wheezy on your A. EC2 ?
I think I'm onto something. First, a question: in your successful test, did you really use Xvfb? I just tried it on my desktop VM without Xvfb (but also with llvmpipe / LIBGL_ALWAYS_SOFTWARE=1) and it worked! When I start the Xvfb server on :99 and change the DISPLAY var accordingly, and repeat the test, it doesn't work. So my clue at the moment is that there's a bug in Xvfb. The next thing I'll do is try to get Xdummy running as an alternative.
Can you confirm the error with Xvfb? You can start xvfb (packaged on ubuntu as "xvfb") easily with the following script:
Just run "xvfb.sh start" and set DISPLAY=:99.0
I think I finally found the problem, see my bug report for xvfb: