Bug 704

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:

https://travis-ci.org/neothemachine/ardor3d-screenshot/builds/5527942

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.:
  http://jogamp.org/deployment/archive/master/gluegen_652-joal_413-jogl_936-jocl_761/

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
> LIBGL_DEBUG=verbose.
> 
> 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:

https://raw.github.com/travis-ci/travis-cookbooks/master/ci_environment/xserver/files/default/etc/init.d/xvfb.sh

Just run "xvfb.sh start" and set DISPLAY=:99.0

I think I finally found the problem, see my bug report for xvfb:
https://bugs.freedesktop.org/show_bug.cgi?id=62742