OpenGL Siggraph BOF

Is there any information online about what was said at this talk? Are there program notes or PDF slides or something available for us to look at?

Plus, the whole OpenGL community would benefit from access to a podcast, if anyone recorded the event (audio or video).

Or if you were at the BOF, how about blogging and posting a link here, posting your impressions here, linking to press articles here, etc.

I third that… we poor also need info. :slight_smile:

Clicky!

OK. Well, now I’m kinda glad that I didn’t attend SIGGRAPH; I’d hate to fly cross-country for that…

Skimpy is probably a word I’d use to describe it. Disconcerting is another.

The GL 3.0 proposal is still being shown off as a joint ATi/nVidia thing rather than a fully-backed effort of the ARB/Kronos. I don’t like what that suggests with regard to how far along the 3.0 process is. By this point, I would have expected the ARB/Kronos to have accepted it and be working on refinement. Obviously an actual specification is still a ways off, but the slides told us nothing about what 3.0 looked like. We know more about the new object model than we do about 3.0 (though I suspect the object model is a part of 3.0). The 3.0 presentation seemed more like form than substance. A repetition of 3.0’s direction, rather than any real information.

As for the new object model itself, it mostly seems reasonable. Though I’m concerned about 2 things:

1: Object Overload. There’s a lot of objects being defined here. And I’m not sure that they’re the best way to go about doing this sort of thing.

For example, take program objects. OK, you have a fully linked program. In order to use it, you need a uniform object that is created based on this program. Fair enough. But you also need a Vertex Array object based on this program, so that you can bind your buffers to it. What’s the draw call going to look like?

glDraw(FBO, VAO, UniformObj, ProgramObj)

It seems a bit verbose. Here’s what I mean.

Having the uniform object being separate from the program object makes no sense. The uniform object was not only created from the program object, it is almost certainly incompatible with any other program object. While the vertex array object is more likely to be cross-program compatible, is it really necessary to do that?

I suggest instead that the linked program object produce one or more “program instance object”. This object holds on to uniform and attribute state for that program. That way, your instance only has one object to worry about (the linked program can be stored off as a global resource that people only touch to create instances).

The only problem this creates is that the instance is fully dependent on the original program. If that program object is deleted, the instance that referenced it becomes invalid. And that’s probably not good. But it would make the whole thing more reasonable to the user.

2: What is it with these “attribute objects”? It seems to me that they’re just fancy ways of passing lots of parameters to object creation functions so that the whole immutability thing that you’re wanting (for good reason) works out. As well as providing extensibility.

The problem is that the code just looks hideous. I mean, you create this object (on the heap, no less) for the sole purpose of passing it to an object creation function and then deleting it immediately afterwards. There’s got to be a better way to do this, right?

BTW, if buffer object parameters are no longer going to be hints, will you be specifying more clearly the actual behavior that an implementation is expected to provide when you use a particular set of hints?

Originally posted by Korval:
OK. Well, now I’m kinda glad that I didn’t attend SIGGRAPH; I’d hate to fly cross-country for that…
Well, I wouldn’t fly for just the OpenGL BOF, but the conference was awesome IMO. :slight_smile:

Originally posted by Korval:
The GL 3.0 proposal is still being shown off as a joint ATi/nVidia thing rather than a fully-backed effort of the ARB/Kronos. I don’t like what that suggests with regard to how far along the 3.0 process is.
The question was raised at the BOF about when an OpenGL 3.0 spec was expected to be ready, and the answer was that they are targetting Siggraph 2007. If they can pull that off, and with Vista delayed to 2007 and probably slow adoption of DX10, I think OpenGL could be in good shape. Of course, some of the ideas for GL3.0 were proposed already for GL2.0 (like L&M profile), and that didn’t turn out like what it was supposed to be in the end.

Originally posted by Korval:
Having the uniform object being separate from the program object makes no sense.
Actually it does. It’s essentially the equivalent of constant buffers in DX10. You want to be able to share constants between shaders, and you want to be able to create all constants on load and avoid setting constants during runtime, so you just bind the appropriate constant buffers instead of uploading constants from system memory like you do in DX9 and to some extent in GLSL.

so you just bind the appropriate constant buffers
You can bind multiple uniform objects when you render? Why didn’t they say so?

I mean, once you have that (which, I have to say, can’t be anything less than a pain to implement. You have to deal with not having certain uniforms being used in a program and so forth. A simple draw call is going to take a lot more time now), the idea makes a lot more sense. If you could only use one uniform object per render call, then it makes far less sense to have the uniform object be fundamentally separate from the program.

Originally posted by Korval:
You can bind multiple uniform objects when you render?

DX10 HW must be capable to bind 16 constant buffers (each containing up to 4096 4-component values) simultaneously to single shader stage (vertex, geometry, pixel)


I mean, once you have that (which, I have to say, can’t be anything less than a pain to implement. You have to deal with not having certain uniforms being used in a program and so forth.

In DX10 the shader is responsible for defining the layout of the constant buffer in way similiar to C structs, there is no fully automatic assignment like in current GLSL. I suppose that the addition of the uniform objects in OGL will be done similiary to what the DX10 does. This way there is no problem if shader does not use some variable from the buffer as long as it defines the same structure for the buffer.

Korval,

I am sorry that you are disappointed by the slides. The fact is we had a lot of information and only barely covered it in the two hour session. There was a lot more said than covered by the slides, and there was more we could have said, had time allowed. In fact we only had 20 minutes total to cover GL 3.0.

Some of your assumptions and conclusions are incorrect. The ARB does not vote to approve an idea. We refine the idea until we have a spec, and then we vote on the spec. Meanwhile, considerable effort has been expended by the member groups (not just NVIDIA/ATI) on the portions that have been completed.

Do not assume that a draw call will accept a list of objects. We have published no such API. I dont like your proposed API any more than you do. :slight_smile:

An overriding consideration of this design is to provide the highest performance rendering by getting the driver and CPU out of the way. These ideas come from years of driver development and seeing how apps use the API and where the common bottlenecks occur.

Attribute objects are the best solution we found for atomic creation of immutable objects. A simple data structure might have been more obvious but its not extensible by multiple vendors. An attribute object is an opaque data structure. If you have a better idea, by all means please share. You do not necessarily have to destroy an attribute object immediately after object creation; if you wish to create many similar objects you can reuse the attribute object. Obviously that will be more efficient.

I believe those who attended had a better understanding of the proposal than one can glean from simply reading the slides. I’m happy to answer specific questions (as time allows; I’d rather focus on writing the spec).

Originally posted by Michael Gold:
…we had a lot of information and only barely covered it in the two hour session. There was a lot more said than covered by the slides, and there was more we could have said, had time allowed.

I believe those who attended had a better understanding of the proposal than one can glean from simply reading the slides. I’m happy to answer specific questions (as time allows; I’d rather focus on writing the spec).
Suggestion: audio podcasts hosted on the OpenGL site would solve these problems. You could make presentations as long as they need to be to get all the information across.

The simplest approach would be to have each presenter record an audio file (e.g. mp3) that people could download separately to accompany each of the existing slide sets from OpenGL.org. Sync to the slides by adding a remark like, “Slide 18” every time the presenter moves to a new slide. Quick, easy and the entire OpenGL community has something almost as good as being at the BOF (or any other presentation speakers provide).

I appreciate the ARB and BOF contributors are very busy, but it improves everyone’s situation to make good information widely available.

Think of all the time you’ll save posting articles to clear up misunderstandings from lack of information. Time that could be going into developing the OpenGL specs. :slight_smile:

The new object-model seems to be going into the same direction as D3D10 does it. I think that’s a good idea. Additionally, the typical style of OpenGL to set attributes through a function-call with an enum to specify the attribute is kept. In my opinion that’s the best thing one could be doing. In D3D10 you fill out a struct. That’s not extensible in any way. Argueing about efficiency here is stupid, because that’s all done at creation-time and one is talking about a few hundred objects that are created once per app, not per frame or something.

All in all, i like what i have seen.

What i’d like to add is, don’t forget “future” hardware. There was only one slide mentioning, what cool stuff is coming in the near future. I hope that OpenGL 3.0 will incorporate these things from the ground up and work perfectly with them. I think this is important. If you only take the functionality of 2.1 and create a new API that fits perfectly to it, it might be not flexible enough for functionality that’s coming with the next hardware generation. Of course it CAN be added through extensions, but i hope it will be integral part of the new API and thus will fit perfectly into it.

And something else: What about extensions? Will the extension-mechanism stay, as it is now, or will it be changed / made easier? I recall there was a discussion a long time ago to make it easier to check for extensions and to get the entry-points, etc.? Is it possible to make it easier, at all? Or will the new “ecosystem” simply include one standard library like GLEW ?

Jan.

Originally posted by smileyj:
Suggestion: audio podcasts hosted on the OpenGL site would solve these problems. You could make presentations as long as they need to be to get all the information across.

This is a good suggestion, and I wish someone had recorded the event for this purpose. But please bear in mind, our intention was not to provide a comprehensive tutorial of an in-flux specification, but to give a taste of what is to come. :slight_smile:

That being said, I would like to give a comprehensive tutorial when the time is right.

Jan,

I’m glad you understand our vision and the tradeoffs we are making w.r.t. object creation. The key point is that objects are used a lot more often than they are created, so optimizing for use is better than optimizing for creation.

We are definitely considering future extensibility, as you observe with attribute objects. In particular, the next round of extensions is already on our mind.

There is actually a whole slide set about upcoming functionality: the presentation is titled “NVIDIA_-_OpenGL_upcoming_features.ppt”. I want to make clear, since someone expressed confusion on this point, that the features described in this presentation are not tied to GL 3.0 and will be available sooner.

Good question about the extension mechanism. We’re still tied to opengl32.dll on Windows and all the limitations that implies. I believe the extension loading libraries remain a good solution for now; if you have suggestions how we can improve it from the implementation side, I’d love to hear them.

Actually i have no complains about the Extensions mechanism, as long as there are libraries doing the dirty work for me :smiley:

Maybe one “suggestion” would be, to not only writing the spec for extensions, but also to have one standard form for an XML file (or something similar), where the technical details will be filled in for that extensions. Than one could create a tool, that automatically parses those files and creates C++/Java/whatever code to be able to get access to those extensions.

I think one of the free libraries already does that. However, it would be more convenient to have a standardized file-format, so that those tools will be reliable.

Also, once written, the tool could be run by the same guy uploading the extension-spec, so that we could get the updated library along with the new spec immediately.

Jan.

Originally posted by Jan:
Maybe one “suggestion” would be, to not only writing the spec for extensions, but also to have one standard form for an XML file (or something similar), where the technical details will be filled in for that extensions. Than one could create a tool, that automatically parses those files and creates C++/Java/whatever code to be able to get access to those extensions.
Hi Jan,

This actually is planned. We are revamping the entire extension registry to use up to date file formats and tools, and cover other APIs in Khronos like OpenGL ES and OpenVG. Part of that will be moving the “specfiles” which define function signatures, enum values, GLX protocol, etc. from a custom flat file format to a suitable (yet to be defined) XML schema.

We already use the specfiles to generate a variety of stuff (GLX protocol spec, glext.h, GLX wrapper code in the OpenGL SI) and this will make it easier for other people to do the same (although I am not sure why people go to extremes like parsing glext.h to construct their wrapper libraries, when they could just use the same Perl scripts used to generate glext.h in the first place :confused: - the specfiles and scripts have always been available on oss.sgi.com).

BTW, if anyone knows of existing schema/DTDs which would be a good starting point for this, I’d love to get pointers to them. I am not actually looking forward to writing my own DTD from scratch :eek: - although I suppose creating the XSL to turn them into headers will be a good exercise in learning functional programming.

DX10 HW must be capable to bind 16 constant buffers (each containing up to 4096 4-component values) simultaneously to single shader stage (vertex, geometry, pixel)
This is about OpenGL, not Direct3D. The new object model and 3.0LM had better be usable on non-D3D10 grade hardware.

Argueing about efficiency here is stupid, because that’s all done at creation-time and one is talking about a few hundred objects that are created once per app, not per frame or something.
Efficiency (on several levels) is a big judtification for the new object model to begin with, so I would respectfully suggest that it is a perfectly valid point for discussion.

It seems to me that the underlying assumption, that building these objects are only creation-time concerns, is one that is, perhaps, becoming less valid as graphics applications progress. In the not-too-distant future, it would not be unreasonable to have an engine where the different kinds of uniform objects are being swapped into and out of render objects fairly frequently. This would be to accomidate a situation where, in one case, an object is being affected by two shadows, but then later is only being affected by one, but you don’t change the program when you do it (conditional branching taking care of the problem). Maybe you’re in 3 lights one frame and in 2 the next. And, since the days of one object being rendered by one shader are, for the most part, thankfully behind us, you’re talking about shuffling around a lot of uniform objects. Maybe you have to create them on the spur of the moment, or maybe you have a library of them around.

It doesn’t matter; what matters is the cost of having a “render object” (one that stores the program and all of the uniforms that it uses, among other things) change which uniforms it uses. In effect, of deleting that render object and creating a new one. This involves a lot of iterating through all of the uniforms and doing a great many string compares. Seeing which elements of the uniform are valid for the shader, and which ones aren’t. Then formatting an appropriate piece of memory (potentially in hardware space) for such data. Not to mention the other overhead in creating a new render object (validating your vertex array, etc).

I’m concerned that you’re moving the inefficiency to another location, one that in the near future may be where developers increasingly want to go.

The ARB does not vote to approve an idea. We refine the idea until we have a spec, and then we vote on the spec.
But the ARB does process ideas and turn them into specs.

The slides themselves strongly implied that the L&M work was primarily an nVidia&ATi thing: “These are the opinions of two ARB member companies and may not reflect the opinions of the ARB as a whole.” This wasn’t attached to the beginning of the .ppt for the new object model or the superbuffers work. So it does draw a distinction between GL 3.0 L&M and the rest of the work that the actual ARB is doing.

The quote makes it sound very much like ATi and nVidia are off doing their own thing, and then sometime later the ARB will come along and work on what they return. That nobody else in the ARB is as of yet involved with the process of creating perhaps the most important OpenGL version ever.

It also sounds very much like there is some significant possibility of this proposal becoming nothing, much the same way the 3DLabs GL2.0 proposal became mostly nothing. After all, if the ARB were fully behind this effort, then it seems that such a disclaimer would be unnecessary.

I don’t like the implication that this L&M GL proposal may be just another big tease like 3DLabs proposal was, that dissent in the ARB/Kronos will eventually cause it to just evaporate and we’ll still be stuck with what we had before. What does it mean for this proposal to not “reflect the opinions of the ARB as a whole” when the others lack such a disclaimer?

that the features described in this presentation are not tied to GL 3.0 and will be available sooner.
Then it seems that we have 3 potentially competing concepts that is creating a degree of confusion. Particularly considering that they are all conceptually interrelated.

  • GL 3.0 LM
  • New features
  • New object model

It’s the interrelation that makes the statement of these being separate confusing. After all, L&M pretty much relies on the new object model; it would be silly to add a new object model after creating a new API.

And it would be redundant to add new features (like a new kind of shader, etc) to the old object model just so that you can come along with the new object model and redefine how that feature works (the reasoning behind not promoting ARB_async_object to 2.1).

And the new object model itself is meaningless without the deprication implied by GL 3.0 L&M; otherwise, you would always be adding new features to both profiles. Plus, the new object model comes with bunches of new entrypoints and so forth, functions that are useless to the old way of doing things (and vice versa). Which implies a degree of deprication.

Maybe the next newsletter could go into explaining how these three are different and related.

have one standard form for an XML file (or something similar), where the technical details will be filled in for that extensions. Than one could create a tool, that automatically parses those files and creates C++/Java/whatever code to be able to get access to those extensions.
Something of that nature already exists for specifications. The format for a spec is fairly strict, so it is easy enough to parse through them and build a list of entrypoints and enumerants.

Though as an XML’o’phile and a middling XSLT user, I wouldn’t mind seeing DocBook being used for GL specifications. Certainly, you can use the various attributes over standard DocBook elements to make it work. And you could publish them as .pdfs as well as html or basic text.

Korval,

I feel really good about the current roadmap, the progress we’re making within the ARB and the spirit of cooperation we are enjoying while working toward a common goal. If you wish to read between the lines and look for trouble where none exists, this is your right; but I’m not going to waste effort trying to convince you otherwise.

Originally posted by Michael Gold:
[b] Korval,

I feel really good about the current roadmap, the progress we’re making within the ARB and the spirit of cooperation we are enjoying while working toward a common goal.[/b]
Ditto. Really what’s been happening is that the ARB is fully occupied with getting the new object model, GLSL updates, FBO updates, etc. complete, so the 3.0 process just hasn’t taken up too much of our time yet. But I think I’m safe in saying that the ARB as a whole is comfortable with the general direction of the 3.0 proposals from ATI and NVIDIA.

Once the object model is worked through and applied to different classes of objects as outlined in Michael’s BOF slides, combined with using OpenGL ES 2.0 as a starting point for the L&M profile, there probably isn’t that much more to do. We can talk for a long time about exactly what needs to be put back into ES 2.0 to create the L&M profile, and maybe we will, but that’s not defining new functionality.

Finally, it is really, really important that ATI and NVIDIA are on the same page on this, because they collectively represent essentially the entire market for cutting-edge graphics hardware now that 3Dlabs is out of the desktop graphics business (not to discount Intel, who is a very important hardware vendor and the winner by market share last time I looked - but they seem to consciously avoid high-end discrete graphics products, and that’s where new features show up first). What has most often held up progress in the ARB in the past is disagreement between the major hardware vendors.

Jon (speaking solely for myself)

Hi

One little thing I couldn’t quite figure out how it works is the relationship between GLSL samplers, image objects and sampler objects.

Could you (Mr Gold) possibly write a short piece of example code to show the relationship of the above, prehaps showing how to ‘bind’ an image object to a GLSL sampler.

Regards
elFarto

Originally posted by Korval:
[quote]DX10 HW must be capable to bind 16 constant buffers (each containing up to 4096 4-component values) simultaneously to single shader stage (vertex, geometry, pixel)
This is about OpenGL, not Direct3D. The new object model and 3.0LM had better be usable on non-D3D10 grade hardware.
[/QUOTE]I was not talking about what kind of hw the model should support. I simply mentioned that DX10 HW is required have such capability. Because that capability would be in the HW, it is very likely that it will be exposed trough the new model. On the older HW the API may expose hard limit on number of buffers or it may merge buffers with associated performance hit (probably small if the layout of the buffers that can be bound to individual “bind points” is known beforehand), whichever they choose.