PDA

View Full Version : Longs Peak and beyond



Korval
02-23-2007, 02:21 PM
Well, the new Newsletter (http://www.opengl.org/pipeline/vol003/) 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 ;) 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?

Jan
02-23-2007, 03:32 PM
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 :)

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.

k_szczech
02-23-2007, 03:48 PM
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.

Zengar
02-24-2007, 01:21 AM
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...

Overmind
02-24-2007, 04:38 AM
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.

Michael Gold
02-25-2007, 08:53 PM
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 ;) 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.


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? Stay tuned.

Michael Gold
02-25-2007, 09:03 PM
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 :) Thanks. :) 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.

Michael Gold
02-25-2007, 09:06 PM
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.

Korval
02-25-2007, 09:31 PM
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 ;) ) 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.

elFarto
02-26-2007, 12:52 AM
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

Michael Gold
02-26-2007, 04:51 AM
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.

Overmind
02-26-2007, 05:26 AM
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 ;)

Zengar
02-26-2007, 07:13 AM
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...

elFarto
02-26-2007, 07:24 AM
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

Michael Gold
02-26-2007, 08:14 AM
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.

Benj @ AMD
02-26-2007, 03:02 PM
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. :D

Michael Gold
02-26-2007, 03:26 PM
Originally posted by Benj @ AMD:
Might?! I can almost guarantee it. :D Hmm... Benj, I see your member number is 7-666. Figures.

Flavious
03-03-2007, 12:55 PM
Originally posted by Michael Gold:
New context creation API.
Any chance of getting a sneak peek at what this might look like? :)

Cheers

Flavious
03-03-2007, 01:11 PM
Originally posted by Korval:
What about glViewport or glDepthRange?
How about combining these into a single call? (They seem to belong together.)

Cheers

Flavious
03-03-2007, 01:23 PM
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

Korval
03-03-2007, 02:01 PM
why the 't' at the end of glTemplateAttrib?There's a semantic difference between passing an enumeration token and passing an int. An integer is a number; it has no intrinsic meaning. An enum token does have a semantic meaning.


which seems to more closely match the naming convention of other functionsWhat other functions? You mean in the OpenGL 2.1 which is not part of Longs Peak? No point in being consistent with 2.1 since Longs Peak is not a 2.1 extension. As long as they're internally consistent, it's fine.

Flavious
03-03-2007, 03:54 PM
I see what you're saying, but here we're passing both.

Maybe by the same line of reasoning, it should be something like

glTemplateAttribtti_i() (first i for parameter type, second for attribute type)

That's where it seems either not verbose enough, just a little redundant, or plain unfamiliar. Since I think that it's impossible to set an int attribute with a float value, I'm leaning a bit towards redundant, only I'd agree that the semantics would be effectively swapped in this case; you'd be describing the type of attribute, rather than the type of argument (I think that's what threw me).

I see no harm in maintaining some familiarity within the new API, so long as it doesn't interfere with things going forward. I think predictability and consistency are two of the nicest aspects of OpenGL. And I also think the traditional conventions employed by the API are just plain cool ;)

Cheers

Korval
03-03-2007, 04:24 PM
I don't understand what the problem is. They explained how this works very clearly in the newsletter (http://www.opengl.org/pipeline/article/vol003_4/) . What is the part that's unclear?

Is it simply that they are saying that an enum is a type separate from an integer that concerns you?

Flavious
03-05-2007, 07:13 PM
I was just a bit curious about the naming convention. Now after thinking it through a bit, it actually makes a good deal more sense.

I noticed some concern over this in another thread too, mainly with respect to the underscore. This is a novelty in the GL landscape, after all, so I think it's pretty understandable.

Anyway, it's all good.

Cheers

Jan
03-06-2007, 12:34 AM
A Jedi friend told me a few weeks ago, that he felt a disturbance in the force. Now we know, it was the underscore.

remdul
03-06-2007, 09:54 AM
That underscore doesn't feel right to me either. Were any alternatives considered?

Korval
03-06-2007, 12:09 PM
Oh come on, guys. It's just an underscore. It's not the end of the world.

Jon Leech (oddhack)
03-06-2007, 11:53 PM
Originally posted by Flavious:
Any chance of getting a sneak peek at what this might look like? :)
const int attribs[] = {
WGL_CONTEXT_VERSION, 3,
0
};
HGLRC ctx = wglCreateContextVersionEXT(hDC, shareContext, attribs);

Jon Leech (oddhack)
03-06-2007, 11:55 PM
Originally posted by remdul:
That underscore doesn't feel right to me either. Were any alternatives considered? Yes. We just haven't found any alternatives that seem any better :confused:

Jan
03-07-2007, 01:34 AM
Originally posted by Jon Leech (oddhack):

const int attribs[] = {
WGL_CONTEXT_VERSION, 3,
0
};
HGLRC ctx = wglCreateContextVersionEXT(hDC, shareContext, attribs);And off we go, for the next round of speculation!


Honestly guys, you are making your own life even harder, by presenting bits and pieces, because now people will again speculate how the rest looks like.
I can understand, that it itches you to show your results, but maybe you should wait a little and then present one complete thing. We have got so much information the last week, we have enough to speculate about for at least a month ;-)

We are all very enthusiastic about this!

Jan.

Zengar
03-07-2007, 02:18 AM
Any chance to get rid of pixel formats? Or to make rendering context pixel-format neutral as long they are on the same device?

Cyranose
03-07-2007, 08:04 AM
Jon, just as an aside, I totally understand why the C interface is critical and I don't dispute that. And I understand why any internal C++ objects aren't exposed as such.

But what do you all think about exposing a standard C++-style set of wrappers (at least) to add some much-needed syntactic sugar?

For example, using templates and/or simple polymorphism in C++, all this explicit name mangling can go away, leaving us with glTemplateAttrib() and more type safety overall.

Isn't an API redesign the right time to introduce something like that? (of course maintaining compatibility for those using other languages -- I understand the issue of apparent forking would be a concern, but it can also be addressed, for example, by using the dreaded underscore in C prototypes where we'd see angle brackets in C++ template instantiations).

Korval
03-07-2007, 09:34 AM
For example, using templates and/or simple polymorphism in C++There's no need for templates or polymorphism. Simple function overloading will suffice for most of the cases.

And I also see no reason why this has to be done by the ARB.

Flavious
03-07-2007, 09:40 AM
Thank you very much for the peek, Jon. I had no idea it would look so simple. Very nice indeed.

Cheers

Cyranose
03-07-2007, 09:47 AM
Simple function overloading will suffice for most of the cases.Yes. That's what I meant by simple polymorphism. :)

I can see two reasons for the ARB to be involved, if not necessarily doing the coding. One is that if there's an official C++ naming scheme, it would make it easier and more consistent to show the translation to C names, for example, in man pages. To some extent, that requires starting with C++ names and basing the C names on those. IOW, the C++ choices inform the C choices more than the reverse.

Two, is that there are a dozen different ways do accomplish the C++ wrapper (I think I may have tried them all ;) and the ARB group working on API issues has the implicit authority to bring this aspect to a conclusion. I just hope they don't mind me suggesting more work for their plate. :)

-Avi

Korval
03-07-2007, 12:16 PM
Fortunately, since Longs Peak is very object-based, there's really only one way to make a C++ wrapper.

Or, at least, only one right way.

Cyranose
03-07-2007, 12:32 PM
Well, if anyone from the ARB wants to send me a draft of the new API at whatever point, I'd be happy to help type up a proposal for that "one true" C++ wrapper. I tend to think there would still be things to debate, in any event.

knackered
03-07-2007, 02:41 PM
Let's keep this simple. Leave them alone to keep it simple, and to get it out of the door sooner rather than later.

Overmind
03-07-2007, 03:04 PM
Why should the ARB bother with any particular language besides C? Why C++ and not Java, C#, Lisp, Python, *insert your favourite language here*?

Better let them just define a single C API, and let others do all these other languages.


IOW, the C++ choices inform the C choices more than the reverse.The C choices can be taken in C++ without change, while the other way round is not possible without change. It may not be the most beautiful naming, but it works in (nearly) every language out there.

Believe it or not, there are a lot more languages than C and C++, so it's not just as simple as changing a few names. Most languages define some way to import C functions, so C is definitely the way to go if you want to support as many languages as possible.


Simple function overloading will suffice for most of the cases.The same reason why an underscore is neccessary in the first place prevents you from using overloading:
glTemplateAttribt_if(enum, int, float)
glTemplateAttribti_f(enum, int, float)

I don't know if this particular combination exists, but I think you get the idea.

PS: Polymorphism has nothing to do with overloading ;)

Korval
03-07-2007, 03:20 PM
The same reason why an underscore is neccessary in the first place prevents you from using overloading:Which would be why I said most cases.

On a completely different note, has the OpenGL GDC stuff started?

Cyranose
03-07-2007, 03:22 PM
The same reason why an underscore is neccessary in the first place prevents you from using overloading:
glTemplateAttribt_if(enum, int, float)
glTemplateAttribti_f(enum, int, float)If that combination existed, it would be a great example of how NOT to design an API. Just try and explain the distinction there to people learning the API.

I don't believe the ARB has to pick any one programming language.

However, just as we now layer "fixed functionality" on top of more flexible constructs, so the C API of an true object-based API should not be the limiting factor anymore. But I'm not really arguing to ditch C support, just to improve C++ support. And yes, I'd love for an official header file for any language people care about. If the ARB simply wants to hold a contest for the best free version of each, which they then "bless" as official, that's fine by me. But I think there's an opportunity for more improvements in the driver's seat, as well as under the hood.

P.S. I don't know why people are arguing the definition of polymorphism. Don't take my word for it. Look it up. It's not just virtual functions. :)

Jan
03-07-2007, 11:51 PM
Great. Why would you rather want to have something that works in _most_ cases, than something that works in _all_ cases, in any language from now until forever. Something that is clear and precise, needs no workarounds and can easily be put into a wrapper, if one thinks that C++ is the one and only language and everything needs to be in C++ ?

I work with C++ everyday and i like the language very much. But things that make no sense, make no sense, period. Someone who knows his craft knows what tools to use for what. You don't use a power shovel to put a nail into a wall, do you?

Jan.

Overmind
03-08-2007, 01:56 AM
Ok, the example with int and float is not very well chosen. Let's try something more concrete:

glTemplateAttribt_2i(enum, int, int) ... set an attribute with type 2i
glTemplateAttribti_i(enum, int, int) ... set an int-indexed attribute with type int

Again I don't know if this combination exists, but I think it is not so absurd to assume the existance of both ivec2-typed attributes and array-of-int-typed attributes.

I think the difference is clear enough. If you think this is bad API design, then I would love to see your suggestion how this could be made any more clear.

Cyranose
03-08-2007, 05:14 AM
There are lots of "features" in C++ that I try to avoid in my APIs until I know I need them. Even virtual functions can often be overkill. However, one thing C++ can do very well is make APIs (especially those featuring objects...) very simple to understand and quick to control.

Overmind, your example still highlights the problem with the overly terse C APIs.

In this case, the first approach I'd try in C++ is see if the (enum,int,int) bits can be wrapped in their own typed object for clarity. In the case of glTemplates, if these are client-side objects, it might be okay to actually build a GLTemplate class with actual getters and setters specialized to the attribute and its various parameters. But trying to avoid any appearance of big [Microsoft-like] versioned gettr/settr structs, I'd start with a lot of little ones, where more can be added down the road without changing any names or offsets. Assuming some GL.h header base class like:


template <int GLID, typename T1, typename T2>
class glAttrib
{
protected:
inline glAttrib();
public:
inline void Set(const T1&amp; t1, const T2&amp; t2);
inline void Get( T1&amp; t1, T2&amp; t2) const;

inline void Apply(glTemplate*) const;
// type-specialized implementations of Apply can call the proper glTemplateAttibXX_X function under the hood
...
private:
// storage
// T x;
// T y;
// a variable number of params could be handled in
// several ways, one of which is to push these
// into the more derived classes.
};

// here go the Enum replacements:

struct glSomeAttrib : public glAttrib<GL_SOME_TOKEN, int, int> { glSomeAttrib(int x, int y) { Set(x,y); } };
struct glOtherAttrib : public glAttrib<GL_OTHER_TOKEN, int, int> { glOtherAttrib(int x, int y) { Set(x,y); } };

// And perhaps a few more wrappers for convenience:

template <typename A>
void glTemplateAttrib(glTemplate *ptr, const A&amp; attrib) { A.Apply(ptr); }

class glTemplate
{
GL_TEMPLATE_HANDLE handle;
// omitting lots...
public:
template <typename A> inline void SetAttrib(const A&amp; attrib) { A.Apply(this); }

};The main goal is to have the compiler find mismatches between enums and function parameters and avoid more runtime errors while adding more clarity. But it might also be nice for us to be able to use these classes to store attributes or whatever object-ish stuff we're talking about in our programs, for faster/cleaner dispatch -- not the whole driver-side objects themselves, which we shouldn't ever know or rely on, but the attribute tuples themselves should be safe.

So, in this case, I'd probably subclass this GLAttrib base for each specific enum type, specializing the parameter type(s) to fit each precisely and trying to add semantic information in the names, or in additional fields as needed.

In the case of an int-indexed attribute vs. a pair of ints as an attrib, those would be two different attribute types (classes) and therefore the names would be clear and different.

Anyway, all that header "goodness" aside, the end user would see and use a much simpler API:

template->SetAttrib(glSomeAttrib(x,y));

including the option of keeping these objects around:

glSomeAttrib A(x,y);
template->SetAttrib(A);

or slightly more C-like:

glTemplateAttrib(template,glSomeAttrib(x,y));

"GLSomeAttrib" might be better to connote data structures vs. function calls than lower case. Namespaces are even better. The glSomeAttrib could potentially carry the suffixes for extra clarity, or even be templatized itself for more options. [The downside in that case is the compiler error when trying to use an unsupported template combination is more cryptic than it should really be. See BOOST_STATIC_ASSERT for some ideas on how to provide better custom compile-time errors.]

All of this can easily wrap the messier (IMO) C API without needing a different DLL. Show me any case it can't handle and I'll make a quick adjustment. :)

And also, btw, this is the leasst intrusive of many approaches. If we took a "mixin" approach, we could even do away with setting up templates in piece-meal fashion. A custom client-side class could be composed of the elements you wanted. This class could be a runtime object you could use. But it could have enough meta information to describe itself to the driver, as GL-templates seem to do. But that's more of an under-the-hood change, so I'm not actively suggesting that, though I use it myself for some really flexible vertex buffer wrapper classes.

Korval
03-08-2007, 09:30 AM
If you think this is bad API design, then I would love to see your suggestion how this could be made any more clear.Simple: you can only set one value at a time. The Longs Peak example already shows us this: you set the width and height in separate calls.

If you are setting something that is intrinsically a vector, then you use "fv" or "iv", not "iii" or "3i" semantics.

zed
03-09-2007, 12:32 AM
yep i agree with korval, keep it as simple as possible ( so perhaps u type more, but hey u have copy + paste, RSI sufferers aside a little typing never harmed noone -- )
anyways personally i think the current API naming method is ideal, ok so maybe not OOP but so!
to quote the cliche, if it aint broke dont fix, its the one thing ive always admired about gl is its syntax

Overmind
03-09-2007, 01:44 AM
a little typing never harmed noone
if it aint broke dont fixFully agreed on both points.

About the whole thing being confusing for beginners: That's what the new glu functions will be for. I don't expect people totally new to GL will be able to understand how to use Long Peaks without any utility function right away.

Nikolai Timofeev
03-11-2007, 10:35 PM
And again about separate program bindings for different pipiline stages.
There is currently linkage stage in OpenGL with working with GPU programs. And that is very well, because I'm just specify
varyings with same names and linker doing all job - binding all resources between differen programmable units, in opposite
with Cg/HLSL or ASM ARB/D3D Shaders where interaction between programs done through semantics ( TEXCOORD0, COLOR etc.)
( Semantics does not mean at all in D3D10, - output layout from one stage must coincide with input layout on next pipeline stage -
for example vertex shader must always write _Vertex_Position_ register , but in Fragment shader I do not use that register,
but it still must be declared here - it very inconveniently, especially when shader's code auto-generated,
and all shaders combinations known only in run time, don't say about stupid errors at all ).

Now in LP we can hold programs for different stages separately. Is there linkage stage ? -
It is done during binding time ? - how runtime can determine "program binding completeness" for that?

V-man
03-11-2007, 11:35 PM
"for example vertex shader must always write _Vertex_Position_ register , but in Fragment shader I do not use that register, "

The vertices are used by the triangle setup stage and then by the rasterizer.

Flavious
03-12-2007, 01:05 PM
Not to belabor the naming issue, but what about this:

glTemplateAttribInt
glTemplateAttribFloat
...

(in the off chance it wasn't already considered and summarily rejected)

It's a clean break from the other tradition, but I think it may avoid confusion and, perhaps more importantly, the underscore.

Cheers

Korval
03-12-2007, 03:48 PM
It's a clean break from the other tradition, but I think it may avoid confusion and, perhaps more importantly, the underscore. Two reasons.

One, it's rather wordy.

Most importantly, two, it doesn't convey the proper information. The reason that the <name type> is there is because attributes need it. Setting a value in a struct works like this:


structVar.structMem = value;Each of these is represented in the glTemplateAttrib call. We know that the first parameter is "structVar"; the template object we're setting the value on. The "structMem" is a name that, in the case of glTemplateAttrib, has one of several possible name types. The name could be a regular token, a token plus an integer, or maybe something else too.

And "value" is a value, which has a type.

So there's 3 types to work with, one of which is known (the type of the object, which is always template attribute). The function names must be differentiated on both name type and value type.

Flavious
03-13-2007, 01:20 AM
I rather think that token is implicit in the TemplateAttrib portion of the name (what are we referring to with TemplateAttrib, if not a predefined token).

To handle both cases, (token, value) or (token, index, value), maybe something like this:

glTemplateAttribInt(template, name, value)
glTemplateAttribIndexInt(template, name, index, value);

or

glTemplateAttribElementInt(template, name, index, value);
glTemplateAttribArrayInt(template, name, index, value);

Respectively, I think these are roughly equivalent to

template.name = value;
template.name[index] = value;

unless I've misunderstood the proposed purpose of the (token, index) tuple.

Cheers

Edit: added another index alternative...

Korval
03-13-2007, 10:54 AM
glTemplateAttribIndexIntDoes the index apply to the integer value or to the template attribute?

That's why the underscore is there. It provides explicit demarcation between the template attribute type and the value type.

Cyranose
03-13-2007, 11:44 AM
quote: a little typing never harmed noone

quote: if it aint broke dont fix

quote: That's what the new glu functions will be for. I don't expect people totally new to GL will be able to understand how to use Long Peaks without any utility function right away.
Wow. I'm really surprised. The people responding here are usually very giving of their time to help newcomers learn OpenGL. But here you seem quite reluctant to help steer an API being redesigned to be _easier_ and _simpler_ be that for both new users as well as well as veteran users such as yourselves.

The idea that you don't mind a little extra typing or potential confusion is fine. But a key problem with the evolution of OpenGL thus far is that the best new features have been the ones that are also hardest to learn and code -- often because the API does not give compile-time feedback when we do something wrong. It compiles, runs, and all we get is a blank window and [if we're lucky] a GL error message.

The key thing I'm pushing for is not to make it easier for pros (which is a fine thing in and of itself). I'm pushing to help eliminate beginner mistakes, which I'd think you'd be in favor of too, given how often you all have to respond to such posts on these boards. Or maybe you like that part too much to give it up? ;)

And as a reminder, I'm only talking about a C++ (or other OOP language) overlay on the C API. Saying "that's what the GLU functions are for" is a strange way to disagree with that request. It doesn't much matter if the header file says GL.H (with a C++ ifdef) or GLU.H as long as the result is a lower learning curve and more API hand-holding for those that need it.

And let's not forget, the main reason OGL is so easy to learn are some of the very features that are being depreciated (or at least layered) -- glVertex3f, etc... Not that depreciation is wrong. But we should balance that with at least comparable simplicity for newbies.

Anyway, I think this is falling on deaf ears. I'll personally be fine no matter what the API turns out to be.

Back to work for me. :)

Korval
03-13-2007, 12:37 PM
steer an API being redesigned to be _easier_ and _simpler_ be that for both new users as well as well as veteran users such as yourselves.These are mutually exclusive design goals. Particularly because that which makes the language useful for veterans doing real work is exactly that which makes it difficult for beginners.

Real developers need an API that is fast-path, guaranteed. Beginners just need to get something on the screen. Advanced users don't have a problem with needing to use 20 function calls to build the template objects necessary to create, for example, an image, as long as that image is guaranteed to be on the fast path. For a beginner, this is onerous; they just want a textured polygon.

As OpenGL 2.1 proves, you can't do both effectively. You have to pick one. Furthermore, it's better to pick the advanced users over the beginners because, worst comes to worst, you can aways wrap things in a more intuitive API. You can't "unwrap" that intuitive but slow API in an unintuitive but fast one.


And as a reminder, I'm only talking about a C++ (or other OOP language) overlay on the C API.And I still don't see the point of making the ARB spend valuable time doing it. Not when there are other developers who are perfectly willing to create such a thing.

knackered
03-13-2007, 01:42 PM
The job of OpenGL is to abstract the hardware functionality as closely as possible. The main aim of the redesign of OpenGL is to boil it down to the bare minimum interfaces which allow for every conceivable future extension without the need for new fundamental interfaces to be added.
If communication with the hardware is done using a command stream, which it is, then the API should be command stream orientated, despite the fact the resources are conceptually objects.
Leave the C++ wrappers to 3rd parties - just as people have wrapped win32 functions in C++ wrappers such as MFC or wxWidgets.
The best one will become the new GLUT.
The reason I personally am against any further discussion about this is because from my experience the ARB take an eternity to actually get things done, and so feature creep is something we, as serious OpenGL users, do not want to encourage.

I want to see this Longs Peak API released within the next few months - I can see no reason why it should take any longer than that. Hardware is simple now, user-defined shaders have taken the complexity away from the driver.

Zengar
03-13-2007, 02:18 PM
+1

Jan
03-13-2007, 04:11 PM
Yeah, i second that.

Flavious
03-13-2007, 05:35 PM
Originally posted by Korval:
Does the index apply to the integer value or to the template attribute?
I think it applies to the template attribute.

One possible source of perceived ambiguity is that traditionally the type suffix has indicated the parameter type, but not necessarily the target type, as is the case with say glVertex2i. That's why I thought that spelling out the typename would serve to hedge against that perfectly understandable preconception; here the parameter type must match the target type (this makes little sense to me, otherwise). In sum, the typename suffix is always the target value's type, while I imagine the index type would always be an uint (although other arrangements could be made).

I too should add that I'll be perfectly content with whatever the ARB decides upon, however deeply unsatisfying I personally find the underscore to be ;)
(The thing about underscores is, once they get a foothold, you'll never be rid of them!)

Cheers

MZ
03-13-2007, 08:08 PM
Originally posted by Flavious:
glTemplateAttribInt(template, name, value)
glTemplateAttribIndexInt(template, name, index, value);

or

glTemplateAttribElementInt(template, name, index, value);
glTemplateAttribArrayInt(template, name, index, value);or:

glTemplateAttribi(template, enum, int) // replacing glTemplateAttribt_i
glTemplateIndexedAttribi(template, enum, int, int) // replacing glTemplateAttribti_i

This would retain the oldschool suffixes and their meaning, if anyone happened to care...


Originally posted by Korval:

glTemplateAttribIndexIntDoes the index apply to the integer value or to the template attribute?

That's why the underscore is there. It provides explicit demarcation between the template attribute type and the value type. So far we've seen 2 ways of specifying an attribute name: token and {token, index} tuple.
As it has been mentioned above, they correspond to 'struct' and 'array' member access in C.

Notice that both of these ways are used in the current OGL. The {token, index} can bee seen in indexed tokens names, like: GL_LIGHTi, GL_TEXTUREi, GL_COLOR_ATTACHMENTi_EXT, GL_DRAW_BUFFERi_ARB, and others. So, it's nothing new here, except the new solution avoids problems of allocation of token number ranges.

Now, the "underscore" notation leaves place for possiblities other than these two. But honestly, will we ever need any?

Jon Leech (oddhack)
03-14-2007, 02:44 AM
Originally posted by MZ:

Now, the "underscore" notation leaves place for possiblities other than these two. But honestly, will we ever need any? Very likely we will. As we work through the various objects, we've had suggested name types including "object handle" and "integer", neither of which are in the current drafts, as well as "token + string", which is still on the table. It is hard to forsee the future but given this experience I'm reluctant to use a less generalizable naming scheme, even at the cost of an unsightly underscore.

We do not plan to work on C++ bindings anytime soon. There's plenty to do just designing the C API for Longs Peak, and bindings to other languages do not affect the GL driver in any way, so anyone can do them. And (just speaking for myself, though I suspect most other ARB members would agree) while I can program C++ as well as the next guy, that doesn't mean I think my OOP design skills are so awesome that I should inflict them on the entire GL developer community :-) Let a thousand open source bindings bloom! (OK, maybe 3 bindings would be enough, that seems to be about how the extension loader library ecosystem worked itself out for example.)

Korval
03-14-2007, 09:44 AM
OK, maybe 3 bindings would be enough, that seems to be about how the extension loader library ecosystem worked itself out for example.Ya know what could facilitate open source bindings?

Releasing a near-final draft of the API before finalization ;)

Jon Leech (oddhack)
03-14-2007, 10:41 AM
Originally posted by Korval:
Ya know what could facilitate open source bindings?

Releasing a near-final draft of the API before finalization ;) The Khronos IP disclosure guidelines make it difficult to release detailed information before the Promoters have formally approved specs, alas. We have to be cautious even in how much we talk about on the forums. Sad but true.

But we will likely do some sort of NDA review period prior to spec release, and people wanting to write wrappers may be able to sign up for that.

Zengar
03-19-2007, 07:24 AM
There is another feature that comes to my mind that may be useful. A possibility to query if a configured object is well supported by hardware. For example, if I create a shader, I would like to query if it will run in hardware. Or, if I use a vertex array, if it will be supported effectively in hardware. Same with textures. What about a function like bool IsFast(obj)?