Longs Peak and beyond

Well, the new Newsletter is out. Some comments.

Async object creation: Sure, why not.

Removing the need to have a complete program in a program: I’m somewhat split on this. As long as it doesn’t create any deficiencies in terms of performance when using two programs compared to one, I’m fine. I’m just slightly concerned that it could cause a bunch of string compares to happen every time you bind multiple shaders for rendering. Assuming you still bind shaders to something in order to provoke rendering…

Image buffers: Like, what took you so long :wink: Does this mean that direct rendering to vertex buffers (aka, rendering to a renderbufferbuffer/texturebuffer can then be bound as a regular buffer object for vertex access) just works?

Uniforms grouped in blocks by the shader: Not entirely sure this is a good idea. My first question is this: is this something that’s going to require Uber-hardware, or can any hardware that can handle glslang currently do this?

Second question, is it necessary for the buffer object (possibly a new subtype?) to specify all of the parameters that the uniform block(s) in the shader uses?

Third, how would this impact performance?

On Longs Peak-to-GL2.1 integration: If you’re going to do the whole multiple-context thing, you definitely need to call it OpenGL 3.0 when it ships. Any other name, like OpenGL 2.2, would not properly show the depth of the changes involved.

As for the actual implementation of cross-usage, it seems fine. GL 2.1 should be able to use Longs Peak objects, but Longs Peak should not be able to use 2.1 stuff; that would just add clutter to an API that is supposed to be clean.

I am curious how you intend to implement the multi-context option, since the parameters for context creation are all pretty much fixed and un-upgradable. Or, at least, they are in Windows.

On template objects: Good name, BTW. The use of the command, “glCreateTemplate(GL_IMAGE_OBJECT)” to create the template object suggests that the result significantly depends on the parameter enum token passed into the function. Does this mean that if you create an image object template, for example, errors will occur if you start giving it attributes meant for, say, a framebuffer object?

As for more general questions, here’s one.

OK, so by now, we have a pretty good idea of what a number of different constructs in Longs Peak will look like compared to GL 2.1. What I want to know is what some of the more forgotten parts of GL will look like. Will there be objects for setting blend parameters or alpha testing? What about glViewport or glDepthRange? How do we go about setting those bits of data that don’t cleanly fit into known object types?

The new object-model is exactly how i imagined it to be. It’s flexible, easy to use and extensible. I like it very much already :slight_smile:

I haven’t quite understood, whether LP will be a whole new API or MTE will be. The idea to be able to create 2 contexts to be able to get the new functionality of LP sounds, … well, in my opinion this is crying out loud for trouble. I fear, that there will never be a driver, that can actually handle this case properly. LP is supposed to be a new API, but you can use parts of it in the old API? No way.

In my opinion the current API is pretty powerful. So, applications that need to support “old” drivers, should stick to it (for example CAD-programs, etc.). I don’t think most of these programs make use of the available features anyway.

All other apps can have a clean break, no mixing. I mean, how long does it take to rewrite a renderer to use a different API? Usually that’s not a big deal. Games (id Software) certainly will either use the “old” or the “new” API, not a mixture.

And the most interesting features can be made available using the existing extension-mechanism. Just as nVidia already did it.

All in all it seems OpenGL is on the way to become competitive again. It seems they are doing a really good job. I just hope they get it done this year.

Jan.

Image buffers: Like, what took you so long Does this mean that direct rendering to vertex buffers (aka, rendering to a renderbufferbuffer/texturebuffer can then be bound as a regular buffer object for vertex access) just works?
Looks like I’m not the only one thinking about it. My topic here:
http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=015059

Uniforms grouped in blocks by the shader: Not entirely sure this is a good idea. My first question is this: is this something that’s going to require Uber-hardware, or can any hardware that can handle glslang currently do this?
Well, I’m implementing similar thing in my framework - not directly for uniforms, but as general set of environment variables that can be automatically bound to uniforms. Of course that means calling glUniform() the standard way when binding shader program, so it’s neither slower or faster than what we currently have, but if this will be supported by driver then I’m likely to support it.
And yes, I’m pretty sure it can be implemented on current hardware with some performance gain.

Second question, is it necessary for the buffer object (possibly a new subtype?) to specify all of the parameters that the uniform block(s) in the shader uses?
The way I see it - such environment would consist of uniforms defining things like fog density, sun position etc. You change fog density and all shaders are affected by this change, you don’t have to initialize fog density, but shaders using it can produce undefined results. The buffer itself must be large enough just as the vertex array must be large enough to cover your index range, but the difference is that it’s not one particular environment but a concatenation of currently active environments with additional uniforms passed from application that has to cover you active uniforms for shaders you use.
That’s not my knowledge though - it’s just my understanding of this topic.

I don’t think that uniforms from the buffer will be supported on every hardware. Nvidia has an extension for G80, but it was not exposed for earlier cards. And as far as I know, G70 and earlier will have uniforms hard-coded into the shader code. Still, this is something that is very easy to emulate by the driver…

The worst case performance for changing the buffer on older cards still can’t be worse than manually setting the uniforms. If the card supports uniform buffers it uses them, if not the driver reads the buffer and just sets the uniforms.

The only thing that could be a problem would be uniform buffers generated on the GPU (render to uniform array). But that’s something older cards can’t do anyway.

Originally posted by Korval:
Removing the need to have a complete program in a program: I’m somewhat split on this. As long as it doesn’t create any deficiencies in terms of performance when using two programs compared to one, I’m fine. I’m just slightly concerned that it could cause a bunch of string compares to happen every time you bind multiple shaders for rendering. Assuming you still bind shaders to something in order to provoke rendering…
Well, its optional. You can still put all stages together in a single program; its just not required anymore. As for binding multiple programs, the compatibility check can be done efficiently.

Image buffers: Like, what took you so long :wink: Does this mean that direct rendering to vertex buffers (aka, rendering to a renderbufferbuffer/texturebuffer can then be bound as a regular buffer object for vertex access) just works?
Not yet…

Uniforms grouped in blocks by the shader: Not entirely sure this is a good idea. My first question is this: is this something that’s going to require Uber-hardware, or can any hardware that can handle glslang currently do this?
In theory, it can be made to work, but its more likely to be efficient on newer hardware. The number of available uniform partitions will be implementation-dependent.

Second question, is it necessary for the buffer object (possibly a new subtype?) to specify all of the parameters that the uniform block(s) in the shader uses?
Well, the buffer object provides storage for the uniforms so by definition, yes, if I understand the question.

I am curious how you intend to implement the multi-context option, since the parameters for context creation are all pretty much fixed and un-upgradable. Or, at least, they are in Windows.
New context creation API.

On template objects: Good name, BTW. The use of the command, “glCreateTemplate(GL_IMAGE_OBJECT)” to create the template object suggests that the result significantly depends on the parameter enum token passed into the function. Does this mean that if you create an image object template, for example, errors will occur if you start giving it attributes meant for, say, a framebuffer object?
Yes.

[b]As for more general questions, here’s one.

OK, so by now, we have a pretty good idea of what a number of different constructs in Longs Peak will look like compared to GL 2.1. What I want to know is what some of the more forgotten parts of GL will look like. Will there be objects for setting blend parameters or alpha testing? What about glViewport or glDepthRange? How do we go about setting those bits of data that don’t cleanly fit into known object types? [/b]
Stay tuned.

Originally posted by Jan:
The new object-model is exactly how i imagined it to be. It’s flexible, easy to use and extensible. I like it very much already :slight_smile:
Thanks. :slight_smile: We’re pretty excited about it, too.

I haven’t quite understood, whether LP will be a whole new API or MTE will be. The idea to be able to create 2 contexts to be able to get the new functionality of LP sounds, … well, in my opinion this is crying out loud for trouble. I fear, that there will never be a driver, that can actually handle this case properly. LP is supposed to be a new API, but you can use parts of it in the old API? No way.
LP will be a new API. This is all tentative but the current thinking is is to allow LP image objects to be bound to legacy texture objects and renderbuffers. That’s the extent of the interaction between the two APIs. Both legacy and LP contexts may also bind to the same drawable. The idea is, this allows a transition path so legacy code will continue to work, and you can rewrite parts of the application in LP without needing to recode the entire app. We’re interested in feedback on this plan. I can elaborate if this is too vague.

Originally posted by k_szczech:
[QUOTE]That’s not my knowledge though - it’s just my understanding of this topic.
Your understanding seems correct. I agree that, even without hardware support, this usage model can be more efficient than the current API, if only by eliminating the application’s need to constantly reload uniforms. Without hardware support the driver may have to copy the parameters but if you’re calling glUniform all the time its copying them anyway.

The number of available uniform partitions will be implementation-dependent.
That’s partitions per shader, right?

New context creation API.
Yeah, that was the part that made me curious.

As it stands now, creating a rendering context is all done through Win32 API calls. And, more importantly, you can’t access a GL implementation’s functions before you make this call. Would that mean that you have to create a context the old way, get a function pointer to the new API, and then create a new-style context (sort of like modern WGL extensions)?

Or are you going to be delivering a replacement Win32 library with new connection hookups?

This is all tentative but the current thinking is is to allow LP image objects to be bound to legacy texture objects and renderbuffers. That’s the extent of the interaction between the two APIs.
Personally, I don’t see a problem with that being the extent of the interaction. Longs Peak seems so nice (to be made nicer once I wrap it in a C++ interface :wink: ) that I’m not sure I’d want to go back.

However, I wouldn’t want to speak for everybody on that. Though, I’m not sure how you would define things like Longs Peak-style shaders or the more exotic buffer objects in GL 2.1 terms.

I am sure of one thing: get Longs Peak out the door (and hopefully into stable GL implementations) before spending too much time on a backwards compatibility API. Indeed, I might even venture the notion that until people actually get their hands on LP (or, at least, see a near-final spec), they won’t know exactly how they want the two to interoperate.

Originally posted by Michael Gold:
New context creation API.
Does this mean a OpenGL32.dll replacement? I can see a huge advantage to having a new DLL for the new API, leaving the existing one for legacy programs/API.

Microsoft have no intention of keeping that DLL up-to-date in the way that libGL.so is keep up-to-date under Linux/BSD/etc…

How hard would it be to create a new OpenGL32.dll library that did the same as the existing one except exported the new API instead. AFAIK the existing one is only responsible for
forwarding the requests onto the current driver’s OpenGL implementation (which is gets from a registry key).

Regards
elFarto

Yes, on Windows one would have to create a legacy context in order to access the new WGL extension. Unless/until MS revs their DLL there is no way around this.

Re: new opengl32.dll; we have considered this and there would indeed be some advantages. However there is functionality we would give up, and Microsoft has made it particularly difficult to replace opengl32.dll on Vista. The best solution may be a wrapper which calls opengl32.dll but hides the ugliness of initialization, similar to GLee/GLEW. We could provide something like this in the SDK but I suspect the existing extension wrappers are up to the task.

The existing extension wrappers all need an existing GL context. Of course it should not be a problem to write an extension wrapper for WGL that automatically produces a dummy context for querying the WGL functions.

If it were up to me, I’d prefer a new dll in the SDK that exports just a few functions:

  • the new context creation API
  • wgl/glxGetProcAddress

ALL other functions should be queried through GetProcAddress. Anything more than that can still be done through custom extension wrappers.

This DLL should be simple enough to implement, and it has practically zero maintainance. It won’t have to be updated ever again (except perhaps for new OS versions, and then it’s very likely just a recompile).

Providing such a DLL with the SDK would have the advantage that it won’t ever again produce this confusing extension vs. core vs. 1.1-core situation we have now.

From then on the usage of OpenGL Long Peaks and beyond is simple: Create a context, and then query every function you need. No difference between extensions, current core and future core versions.

It’s not easier or harder to use than now, but it would be a lot more consistent and not so confusing to people that are new to OpenGL.

Just a suggestion though, I know there are more important things than how we get our extensions :wink:

Will there be no pixelformat issues? I don’t really understand how it works now… I had such wrapper for my application, it would create a temporary window with an accelerated GL context and query all possible pixel formats. But what if I have more then one graphics device installed (is it possible at all)? Or if I have more then one monitor? Can I really rely on pixelformats that are present on a dummy context? I haven’t find anything about it in the spec…

Originally posted by Michael Gold:
Re: new opengl32.dll;…
I was just thinking how this bit of the initialisation is actually EGL’s domain, but if what your saying about Microsoft making it difficult (which I’m not surprised at) to replace then it really doesn’t matter.

It just annoys me that initialising OpenGL on windows always seems to require some black magic, even if it is hidden behind GLFW and friends.

Regards
elFarto

The pixel formats will likely be unchanged. Currently a pixel format is associated with a renderer (i.e. ICD or msogl). Presumably you can use the same pixel format to create both legacy and LP contexts.

Bear in mind that the spec is not complete, and we’re still working through details like this. Keep the questions coming, as you might think of something we failed to consider.

Originally posted by Michael Gold:
Keep the questions coming, as you might think of something we failed to consider.
Might?! I can almost guarantee it. :smiley:

Originally posted by Benj @ AMD:
Might?! I can almost guarantee it. :smiley:
Hmm… Benj, I see your member number is 7-666. Figures.

Originally posted by Michael Gold:
New context creation API.

Any chance of getting a sneak peek at what this might look like? :slight_smile:

Cheers

Originally posted by Korval:
What about glViewport or glDepthRange?

How about combining these into a single call? (They seem to belong together.)

Cheers

I’m also very excited about the template mechanism for specifying attributes. This is way cool.

Just out of curiosity, why the ‘t’ at the end of glTemplateAttrib? Why not just glTemplateAttribi, for example, which seems to more closely match the naming convention of other functions?

Cheers