'Function "glXCreatePbuffer" not yet in function whitelist'

[JayFoxRox]

No offscreen rendering possible yet, I'd still like to use vogl to debug my application.

[mikesart]

Hi Jannik. Do you have a bit of sample code or an apitrace file that we could use to get vogl working with this? Thanks!

[JayFoxRox]

Hi Michael, this mesa-demos test should help: http://cgit.freedesktop.org/mesa/demos/tree/src/xdemos/pbdemo.c This works fine in apitrace but not vogl. It's straight pull and compile for me. Note that there is also "wglCreatePbufferARB" and "eglCreatePbufferSurface" in WGL and EGL.

The most typical use is probably when you mix hard- and software rendering. Personally I use it in a QEMU fork for the emulation of a GPU. We don't even really use the pbuffer as we switch to an FBO. However, the pbuffer is still necessary to have a windowless GL context. Creating a second code path to create a window so vogl works would be an option, but would also complicate the code. Also it would still not solve the problems for people actually using pbuffers who might not be able to change the code.

(pbdemo.c shouldn't be mesa specific but I heard nvidia has some issues with pbuffers in general, regardless vogl should be able to handle it. I only have intel GPUs so I'm not able to test pbdemo.c on nvidia - I'll just assume it works as mesa-demos should be clean code)

[amonakov]

However, the pbuffer is still necessary to have a windowless GL context.

This is technically not true at least in the context of GLX starting from OpenGL 3.0; quoting from http://www.opengl.org/registry/specs/ARB/glx_create_context.txt,

In the description of glXMakeContextCurrent [...]
If either <draw> or <read> are not a valid GLX drawable, a
GLXBadDrawable error is generated, unless <draw> and <read> are both
None and the OpenGL version supported by <ctx> is 3.0 or greater. In
this case the context is made current without a default framebuffer,
as defined in chapter 4 of the OpenGL 3.0 Specification. 

So you can have a rendering context without a window-system-provided drawable by passing NULL drawables to glXMake[Context]Current, provided that the context API version is at least 3.0.

FWIW I'm not aware of any problems with pbuffer functionality on NVIDIA Linux drivers.

[JayFoxRox]

Unfortunaly I'm running OGL 2.1 with extensions on one machine. I'd also like our application to stay compatible to OGL 2.0 for as long as possible.

I believe there was some problem with FBOs when using pbuffers. I had at least one person report that the FBO was never complete on nvidia using a pbuffer-context, yet it worked with a window context. It might just be a bug in our code but I found similar reports about the same issue (either very old / unsolved / bugs in user code). I still thought it would be good to mention it in case problems with the piece of mesa code arise ;)

[amonakov]

OK, thanks for your clarifications; regarding pbuffers on nvidia, I'm using pbuffers on nvidia side in primus and there were no problems like that; I'm inclined to think it's either a bug in application code or a long gone bug in old drivers.

In any case that was tangential, support for pbuffers in VOGL would be a nice addition.

[mikesart]

Thanks for all the info - I'm heading out for the next 6 days but will take a look at this when I return.

[schulmar]

As of Qt 5.1 there is an QOpenGLOffscreenSurface class which I am using in some of my applications. From its documentation:

How the offscreen surface is implemented depends on the underlying platform, but it will typically use a pixel buffer (pbuffer).

So it would be nice to have PBuffer support because I cannot replay the traces of my Qt OpenGL applications.

[mdsitton]

Curious if this is ever going to be looked at?

[JayFoxRox]

You do realize that this project has been practicly dead for more than a year?

That merge 23 days ago came rather unexpected I must say..