Official feedback on OpenGL 4.0 thread

[Executor]

IMHO, Instead of making multiple versions API (GL2, GL3, GL4, GLES, GLES2 and other), can use profiles - one API, many profiles. Like this:
GL_CONTEXT_GL2_HARDWARE_PROFILE_BIT_ARB - for DX9 hardware
GL_CONTEXT_GL3_HARDWARE_PROFILE_BIT_ARB - for DX10(.1) hardware
GL_CONTEXT_GL4_HARDWARE_PROFILE_BIT_ARB - for DX11 hardware
GL_CONTEXT_GLES_HARDWARE_PROFILE_BIT_ARB - for embedded systems
GL_CONTEXT_GLES2_HARDWARE_PROFILE_BIT_ARB - for embedded systems

For next release opengl api, some profiles may be deprecated, or supplemented other new features.
For example, OpenGL 4.1:
added ARB_texture_barrier functional in core for GL_CONTEXT_GL3_HARDWARE_PROFILE_BIT_ARB and GL_CONTEXT_GL4_HARDWARE_PROFILE_BIT_ARB profiles.

Or something like this.

[Alfonse Reinheart]

What does that matter? You can already specify a version number to glContextCreateAttribARB. Why would you need a special bit to say you want GL3 when you just asked for a GL 3.3 context?

[Jan]

One important point is, that with version numbers (instead of profiles) vendors will be able to simply write "supports OpenGL 4.0" on their products. That is very important for competition, because when some other vendor is still stuck at version 3.2, some people won't buy their hardware, even though they might not know anything about OpenGL. Bigger number, more interest by customers (just like with DX, too).

That forces vendors to adapt OpenGL more quickly and that in turn is a good thing for developers.

Jan.

[Emanuele]

Hi, I don't understand how with OpenGL 4.0 is possible to achieve MT rendering (or better submit n parallel commands) to the OpenGL driver without DSA api.
Could you please explain to me?
Does the OpenGL specification not only force monothread to issue commands but even isothread (it means that the only thread allowed to issue OpenGL commands within a process is the thread that creates the context, so an even more restrictive condition than simple monothread)?

If it's possible, in which instances?
Because some years ago one of my OpenGL programs was loading a lot of images as textures and actually I was able to load them from jpg files with separate threads in memory but then, to load them as OpenGL textures, I had to use the thread that created the context otherwise I'd experience an unexpected behaviour.

Could you please help me better understand?

Cheers,

Ps. I use the term iso (thread) because it's latin to mean "the same and only".

[bsupnik]

Hi Y'all,

I agree with Rob mostly - it's certainly very nice to have DX11 type functionality in ARB specs slated for core now, so early on. With DX10 we had NV vendor specs for a long time, and it wasn't clear how many would make it to core. For an apps developer this introduces uncertainty in the road map.

Re: DSA and MT rendering, it is not at all clear to me what MT rendering case would be solved. This is my understanding of the situation:

- As of now, you can render to different render targets with different threads using multiple shared contexts. If you use "state shadowing" to avoid unnecessary binds/state selector changes, you'll need to use thread local storage for the shadowing. One context, one thread, one FBO, off we go.

- As of now, this will not actually cause parallel rasterization on the card because modern GPUs (1) have only one command interpreter to receive and dispatch instructions and (2) allocate all of their shaders in one big swarm to work through that rasterization. If anyone knows of a GPU that has gone past this idiom, please shout at me.

- If you do am MT render from multiple threads/shared contexts, what will really happen is the driver will build up multiple command buffers (one for each context) and the GPU will round-robin execute them, with a context switch in between..pretty much the same way a single core machine executes multiple apps. I do not know what the context switch cost or granularity is.

- Because drivers spend at least some time building up command buffers, a CPU bound app that spends a lot of time in the driver filling command buffers might in theory see some benefit from being able to fill command buffers faster from multiple threads. I have not tried this yet, and I do not know if driver sync overhead or the cost of on-GPU context switches will destroy this "advantage." It is my understanding that a GPU context switch isn't quite the performance nightmare it was 10 years ago.

If the goal is MT rendering to a single render target/FBO, I don't know how that will ever work, as serialized in order writes to the frame buffer is pretty close to the heart of OpenGL. I don't think DSA would address that either.

As a final side note, I'm not as excited about DSA as everyone else seems to be. (Of course, X-Plane doesn't use any GL middle-ware so we can shadow state selectors and go home happy. :-)

In particular, every time I've taken a careful look at what state change actually does, I see the same thing: state change hurts like hell. Touching state just makes the driver do a ton of work. So I'm not that interested in making state change any easier...rather I am interested in finding ways to avoid changing state at all (or changing the ratio of content emitted to state change).

In other words, what's annoying about selecting a VBO, then setting the vertex pointer is not the multiple calls to set a VBO/vertex pointer pair...it's the fact that the driver goes through hell every time you change the vertex pointer. Extensions like VBO index base offsets (which allow for better windowing on a single VBO) address the heart of the problem.

Cheers
Ben

[pjcozzi]

I agree with the mentioned benefits of .x versions over just extensions. Besides guaranteeing vendor support and marketing reasons, it is also nice for developers to be able to create an x.y context and know what features to expect.

GL3 for DX10 hardware and GL4 for DX11 hardware.

Perhaps by the time GL5 comes out, people will be saying DX12 for GL5 hardware.

Regards,
Patrick

[ZbuffeR]

to load them as OpenGL textures, I had to use the thread that created the context otherwise I'd experience an unexpected behaviour.

You want to use the PBO extension :
http://www.opengl.org/registry/specs...fer_object.txt
See also :
http://www.songho.ca/opengl/gl_pbo.html

[davej]

In gl.spec, Indexub and Indexubv both have a category of VERSION_1_1_DEPRECATED but neither have a deprecated property as the others with that category do.

[Rob Barris]

I think the value of DSA when used on an MT driver has to do with these issues:

a) MT drivers don't like it when you query and may inflict big delays on your thread.

b) Currently, you have to perturb the drawing state (via binds) to do things to objects, like TexImage. Background texture loaders may run into things like this.

c) So if you want to do things to objects without perturbing the drawing state, you need to save and restore bind points.

d) if you are not in a position where you have done your own shadowing, so you know what the bind point was "supposed to be set back to" for drawing, then you have to query. This can be particularly difficult for things like in-game overlays that are implemented as a separate library without knowing anything about the code base they are co-resident with.

DSA allows for directly communicating changes to objects without altering the drawing state, and not having to query/reset bind points that affect the drawing state.

[Chris Lux]

will the slides from the OpenGL session from GDC be available on the Khronos site?