Official feedback on OpenGL 4.2 thread

[kyle_]

If we have to create a window for each thread

This was never the case, though i recall seeing msdn article that says separate HDC's should be used to make contexts current on their threads if you draw to the same window.

But that's my point: we already have one. wglCreateContextAttribs.

wglCreateContext works just as well here (unless you care for, well, context attributes).

[Alfonse Reinheart]

wglCreateContext works just as well here (unless you care for, well, context attributes).

wglCreateContext doesn't take a HGLRC to share with, so if you want sharing, you have to explicitly call wglShareLists afterwards. It's always good to be up-front about sharing.

[Dan Bartlett]

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.

If you look at issue 4) in the WGL_ARB_create_context extension specification , it reads:

4) Should there be a way to make a context current without binding
it to a window system drawable at the same time?

RESOLVED: Yes, but only in OpenGL 3.0 and later. This results in a
context with an invalid default framebuffer, the meaning of which is
defined in the OpenGL 3.0 specification.

NOTE: Apparently on Windows, opengl32.dll makes use of the drawable
argument to identify the namespace of the driver, so we may not be
able to work around it.

I guess this means that if you have 2 cards from different vendors with different drivers, then the hdc is being used to identify the driver to create the context using, which if you provide NULL it can no longer do (without guessing).

Whether this is something Microsoft can solve, or an unsolvable problem without using a different platform API (EGL or new OpenCL-like platform layer) I'm not sure.

Maybe some extra attribute in the context creation flags would be enough.

wglGetPlatforms(NULL, &num_platforms);
*allocate platforms buffer*
wglGetPlatforms(platforms, &num_platforms);
*choose a platform*
*free platforms buffer*
 
attributes[0] = WGL_CONTEXT_PLATFORM;
attributes[1] = chosen_platform;
attributes[2] = WGL_CONTEXT_MAJOR_VERSION_ARB;
attributes[3] = 4;
attributes[4] = WGL_CONTEXT_MINOR_VERSION_ARB;
attributes[5] = 0;
attributes[6] = WGL_CONTEXT_PROFILE_MASK_ARB;
attributes[7] = WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB;
attributes[8] = 0;
 
wglCreateContextAttribsARB(NULL, NULL, attributes);

[Eosie]

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).

It's there as the shareList parameter:

GLXContext glXCreateContext(Display *dpy, XVisualInfo *vis, GLXContext shareList, Bool direct);

[AleX AciD]

The quick reference card describes non-existent functions: DrawArraysOneInstance and DrawElementsOneInstance.

[thokra]

The spec clearly states that these functions are not part of the API but are merely used to explain the behaviour of actual functions.

[biller23]

The spec clearly states that these functions are not part of the API but are merely used to explain the behaviour of actual functions.

This makes sense in the spec, but he's talking about the quick reference card. Why are these functions displayed there?

[thokra]

On second thought, that's actually unnecesseary.

[xahir]

Need of context creation for multiple threads is because of loading objects from files as I understand. Like 3d model or scene files, or shader files etc. But I have a basic problem about that besides context creation too.

If I want to load a model file containing vertex attributes or indices I'd rather want to save attribute info into OpenGL state...(ie. VAO).
Similarly for scene files there may be some render-to-texture effects so I will need to generate some framebuffers for that need while loading the file...
When I begin to load shader files I need to generate my pipelines...

And here is my problem: None of VAO, framebuffers or pipelines are sharable among contexts. Just because they refer to other objects. I still dont understand why they need to be client state and not server state. Because we are not holding onto object pointers or such. We are holding some object names which are given by the driver and being recognized across threads.

Display lists (ironically core profile is removing lists but DX is introducing lists for multiple threads) might be a solution if using buffers/shaders was valid.