0x0 GLXPbuffers are underspecified

[nwnk]

Mesa has never supported this, and I believe NVIDIA doesn't either, and it's a fairly goofy thing to do in any case. However the spec doesn't say what error to raise to indicate failure here. Mesa happens to throw BadValue in its real-GLX paths, and will simply return 0 for fake-GLX.

A similar observation applies to EGLPbuffers, but there are probably many more EGL implementations than GLX. In any case I'm happy to simply codify whatever error is most common, and ideally update the specs to indicate that 0x0 might not be supported.

[oddhack]

Assign to @pdaniell-nv to figure out what NVIDIA's GLX implementation does, which is hopefully the same as Mesa's, then we can do a spec patch. Is it just 0x0 or also 0xN / Nx0 that should be addressed by this?

[cubanismo]

Our driver will apparently handle 0xN, Nx0, and 0x0 pbuffers and give you a valid pbuffer object you can make current to and whatnot from what I can tell.

[cubanismo]

FWIW, I'm still fine with a spec update that says implementations might return BadValue or something here. It's just not what our implementation does right now.

[nwnk]

Hah! Neat. A few questions:

• I imagine making such a pbuffer current would behave like you said glXMakeCurrent(dpy, None, ctx) from the GL perspective and just clip everything?
• This is true of both GLX and EGL?
• Any idea how long that's been legal in your driver? GLX_SGIX_pbuffer kinda reads like that was always legal, now that I look at it again. If it behaves like in point 1 above I'm just as happy to fix xserver and Mesa to handle it.

[cubanismo]

Yes, the pixel ownership test will always fail for these pbuffers.

Good news everyone! In EGL, we support this as well, but it actually behaves as if the pbuffer has a 1x1 valid rect, so the behavior is subtly different than our GLX implementation. FWIW, I consider that a bug in our driver, but that's the current behavior. According to comments in the code near this hack, old versions of firefox (up to 3.0.8) use 0x0 pbuffers in EGL, and probably in GLX too, and get very confused when it doesn't work, so there's some evidence of a marginally-interesting use case in the field at least.

For GLX, it has been that way at least as long as I've been here (~15 years). The behavior itself seems to be inherited from the sample implementation, though the current special casing and handling of it dates to a refactoring just before I got to NVIDIA, around ~16 years ago. I didn't do archaeology further back than that or try to verify it actually worked consistently in practice throughout that interval. The current handling in our EGL driver dates back over a decade.