Official feedback on OpenGL 4.2 thread

[Groovounet]

The OpenGL 4.2 and GLSL 4.20 specification has been updated:
http://www.opengl.org/registry/

[Closed]

Good day! I was found some errors in OpenGL 4.2 (2011.08.22) spec:

1) section 2.14, page 155:

Original:
The state required to implement the viewport transformation is four integers and two clamped floating-point values for each viewport.

Error description:
Wrong! 6 floating values are required (4 - viewport, 2 - depth range), see glViewportIndexed* and GL_VIEWPORT_SUBPIXEL_BITS)

2) section 3.9 (Texturing), page 213

Format RGB565 is missing in table 3.12. So, it is unusable because missed sized internal format.

Sorry! If i'm wrong (:

[Closed]

Updated NVIDIA/AMD driver status, introduced new bugs not included in article from www.g-truc.net.

http://www.steelratsoftware.com/inde...58#addcomments

[Stewox]

John Carmack of ID SOFTWARE says this about OPENGL

http://twitter.com/#!/ID_AA_Carmack/status/126421181069918208

[kyle_]

Nice of Carmack to provide some advocacy (took him a while to notice the problem though
But what does this have to do with multiple threads?

[Groovounet]

Because in we could use work threads to process meshs, textures anythings and upload them into the GPU memory. If we have to create a window for each thread, then we are wasting the framebuffer memory attached to this window.

[mbentrup]

While I don't think that it is a big restriction that you need a window to create an OpenGL context (note that you don't need a window per thread), I sometimes wished that GLX/WGL would have a function that could create a new context, given just another GL context as input (compatible/shareable with the input context of course).

Especially when the original context is created by a library (like GLUT or SDL), it's quite painful to query the PixelFormat etc. of the original context to create a cloned context.

[Alfonse Reinheart]

Especially when the original context is created by a library (like GLUT or SDL), it's quite painful to query the PixelFormat etc. of the original context to create a cloned context.

That doesn't make sense. If you want to create an off-screen context for doing uploading and so forth, pixel formats are completely irrelevant. You don't want a default framebuffer. You don't even have a window or DC to set the pixel format into. All you want is a new context that is shared with the old one.

One of the early ideas with wglCreateContextAttribsARB was that you would be able to pass NULL for the device context and thus create a display-less GL context. The 3.0 and above specs even have language that previous versions didn't for such eventualities.

Indeed, it may actually work now. You might be able to create multiple contexts from the same DC, but pass NULL for the DC when using wglMakeCurrent. According to the spec, this ought to be able to work. I'm not sure if I buy it though; someone ought to test it out.

[mbentrup]

Especially when the original context is created by a library (like GLUT or SDL), it's quite painful to query the PixelFormat etc. of the original context to create a cloned context.

That doesn't make sense. If you want to create an off-screen context for doing uploading and so forth, pixel formats are completely irrelevant. You don't want a default framebuffer. You don't even have a window or DC to set the pixel format into. All you want is a new context that is shared with the old one.

Exactly. Unfortunately the HDC is required and WGL specifies that two contexts may only share resources if they use the same pixel format. (You may not even get the same results if you call wglGetProcAddress in contexts with different pixel format).

GLX does not explicitly state this requirement, but the driver may return BadMatch, if the contexts are "incompatible" for whatever unspecified reasons.

One of the early ideas with wglCreateContextAttribsARB was that you would be able to pass NULL for the device context and thus create a display-less GL context. The 3.0 and above specs even have language that previous versions didn't for such eventualities.

Indeed, it may actually work now. You might be able to create multiple contexts from the same DC, but pass NULL for the DC when using wglMakeCurrent. According to the spec, this ought to be able to work. I'm not sure if I buy it though; someone ought to test it out.

That language refers afaik to the case when you pass a NULL DC to wglMakeCurrent, but for the context creation the DC was always required.

In practice you won't find OpenGL apps that use *only* windowless contexts and any windowless contexts are probably for uploading textures or using transform-feedback to fill buffers etc, which are then later used in the 'main' context, so I think a specific function to create a shareable context for a given GL context would be very useful.

[Alfonse Reinheart]

In practice you won't find OpenGL apps that use *only* windowless contexts and any windowless contexts are probably for uploading textures or using transform-feedback to fill buffers etc, which are then later used in the 'main' context, so I think a specific function to create a shareable context for a given GL context would be very useful.

But that's my point: we already have one. wglCreateContextAttribs. Just pass it the same DC you used to create your windowed context. It also has a parameter for a HGLRC that it will be shared with.