But I think there should be a very simple query mechanism: this mechanism should return true, iff for a given configuration the object creation will succeed. That is, for every
lpCreate<Object>(arg0, arg1, ...)
function there should be a
lpIsValidConfigFor<Object>(arg0, arg1, ...)
function which checks only the validity but does not create the object.
No i think. Valid != can do it whenever you need it.
Counterexample of events:
=> ask if A obj can be created.
<= yes, there is enough (address) space (or whatever finite resource).
** some OTHER app uses or clutters that space somehow.
=> make obj A
<= … oh, [censored] - i lied, can’t do it.
as i see it, GL3 plan is sound. No?
Well no, that’s not true. GL3 separates out the parameters from the content of an object, so you’ll just be trying to create a container object capable of what you require rather than submitting and re-submitting data as part of the creation process. So your simple example is not proving any point at all.
The latter is less performant, as you have to blindly resize the bitmap until it fits
Technically, that’s not true. For images.
GL 3.0, at the last info dump, had ImageFormat objects which, as part of their parameters, took a range of image resolutions. You can’t create a texture (technically an Image) without an ImageFormat, and it is illegal to specify resolutions for that Image that are outside the range you asked for with the ImageFormat.
So rather than sitting and spinning on every texture create to find the largest resolution, you would only need to sit and spin on ImageFormat creation. And ImageFormats are intended to be widely shared.
But I think there should be a very simple query mechanism: this mechanism should return true, iff for a given configuration the object creation will succeed.
What would be the point?
I mean, you went through the trouble of setting up an Template object with all of the parameters. The fact that you want to query whether this object can be created means that you will want to create it. Probably sometime in the near future. Would it kill you to just create it now and hang on to it?
Oh, and let’s not forget the ImageFormat stuff.
So rather than sitting and spinning on every texture create to find the largest resolution, you would only need to sit and spin on ImageFormat creation.
So technically ImageFormat can be thought as a kind of a “formalized” query. Feels like a sound approach.
Does this come from a newsletter? Or if not, do you have a link? I’d like to see what guarantees ImageFormat would convey. Ideally, if you have an ImageFormat the texture creation would never fail, unless there is an out-of-memory error (virtualized memory to the rescue?), or the user hot-plugs the video card. Also, do we know if this approach will be followed for all OpenGL resources were it makes sense? (e.g. vertex formats)
Hopefully GL3 will be able to avoid the mix of approaches in GL2, where different resources can be queried (texture size), tested with proxy objects (texture formats and size), can return unsupported errors (FBO), or even fail without any way you could test beforehand (GLSL, plug and pray). 
On another note, I silently admire Khronos. I didn’t follow FBO or GL2 development back then, but I find it rather impressive that there have been almost no leaks for 6 months now. Well done guys!
There were never leaks )) Very few insiders and too little people interested.
Does this come from a newsletter?
Essentially, yes. The stuff about what an Format does was covered in a Newsletter (specifically, here). I specifically asked one of the ARB guys if the creation of an Format (or other objects) that couldn’t be hardware accelerated would fail, and the answer was yes. So if you ask for a FLOAT_32 format and you want it to be bilinearly filtered, then the creation of the format would fail.
It was in the SIGGRAPH info where they specified that Format objects would contain usage information. Not hints (which are ignorable), but usage info. That is, if you create a Format and you don’t say that it needs to be bilinearly filterable, it is an error to use an Image created from that format as a texture.
Indeed, you can’t use an Image created from that Format as a texture (ie: bind it to a glslang sampler) unless you actually say that you want to be able to. That way, the concept of “RenderBuffer” goes away entirely; it’s simply a matter of the Format that you use. If you want images created from a Format to be bound as both Textures and Render targets, you can, but you have to say so in the Format.
Also, do we know if this approach will be followed for all OpenGL resources were it makes sense?
The Vertex Array Object structure is similar to Formats, but different. The VAO contains all of the binding points for the vertex attributes for a single draw call. So it can verify if the data type, size of data, stride, etc. are valid for a complete set of array data. The only things that vary (ie, is not checked at creation time) are the buffer objects themselves and the offset into those buffers.
Program objects take care of themselves (either the program works or it doesn’t build an object). FrameBuffer objects have as a requirement for creation the Format for each attachment point, so they can verify at creation time whether Images created from those Formats can be attached.
You should read up on the SIGGRAPH information. It’s all pretty sweet. Which makes the fact that it’s been 6 months without new information since then even more infuriating…
What would be the point?
I mean, you went through the trouble of setting up an Template object with all of the parameters. The fact that you want to query whether this object can be created means that you will want to create it. Probably sometime in the near future. Would it kill you to just create it now and hang on to it?[/QUOTE]
Think of some combo boxes for end-users for tweaking render parameters, for example, which should only contain valid values or valid combinations of values; no need to create the corresponding GL objects for that!
Think of some combo boxes for end-users for tweaking render parameters, for example, which should only contain valid values or valid combinations of values; no need to create the corresponding GL objects for that!
Then delete them afterwards. That isn’t performance-critical code.
Thanks for the detailed explanation, Korval. I’m going through the available material know, and it’s pretty sweet indeed.
Let’s hope for a 2008 release…
I turn my eyes for a few days and whoooa!
This topic continues to grow covering more and more areas. We’ve allready been through all our standard off-topic topics: Microsoft, D3D vs OpenGL, vertex arrays, new object model in upcoming GL3 (if you look at the date of newsletter where it was presented then it’s not that new afterall)…
What can I say? Maybe I’ll just stick to the original topic:
“Are we there yet?” 
And untill we’re there don’t expect me to have anything more to say…
I think this delay is taking the p*ss now. We seriously want some feedback on the status of GL3.
You’d have thought common courtesy would dictate that ‘someone’ would make some kind of announcement, even if it’s simply “Hello, we’re still progressing, don’t worry!”. A “Hello, OpenGL World” kinda thing 
Actually, the lack of any feedback whatsoever is verging on downright rude, in my book.
true, but they might be under a NDA
some NDAs dont allow u to even say that youre under NDA
the longer it goes on the more its looking like a legal issue + not an implementation issue
mark, ive refined the coords, so with the help of google earth u should know which house to drop the bomb on
Q to zed…
I was bored, and checked your location… Do you live in a field by a racecourse?
Since 1998 (AFAIK) until 2006 there was a Direct3D tutorial and an OpenGL tutorial at GDC (one day long, each one). Last year there was no OpenGL tutorial but there was a Khrons Group booth at GDC’s Expo (not very well planned, in my opinion) where it is supposed that one day it was a talk about GL3 (it was a noisy place in the Expo). And there were a few talks about OpenGL in the conference.
This year it has been no OpenGL tutorial (Direct3D one was still there), there was no Khronos booth, there was no OpenGL talk.
So, if there is no OpenGL in the main game developer conference I don’t see the ‘promotional’ advantages of the Khronos Group. The only thing I see is that there was something and now there is nothing.
Also, the IHV sold us, the developers, the advantages about the changes from ARB to Khronos like: being informed, the OpenGL newsletter, more feedback, etc. And, after the initial ‘explosion’, there is nothing.
Even the main IHV have decreased their developer OpenGL support in the recent years: you can compare the number of the OpenGL examples vs D3D examples in the NVIDIA SDK 8.5 vs the same comparision in the SDK 10.0. And how the tools they made those years are just D3D tools.
OpenGL is becoming some kind of religion. You have to believe without seeing.
Let’s hope jesus comes along real soon.
Also, the IHV sold us, the developers, the advantages about the changes from ARB to Khronos like: being informed, the OpenGL newsletter, more feedback, etc. And, after the initial ‘explosion’, there is nothing.
You say this as though the current issues are Khronos’s fault. I mean, it may well be, but thus far, nobody has any evidence to suggest that it is. Let’s not forget that before the initial “explosion” of information, there was nothing. They’d stopped releasing the ARB meeting minutes, so we had no information about anything with regard to OpenGL.
They’d stopped releasing the ARB meeting minutes, so we had no information about anything with regard to OpenGL.
So we’ve returned to the Standard Operating Procedure then. Obviously it doesn’t work quite as well in these modern times (see Zak’s GDC comments).
Well, there will always been OpenGL ES! Start porting your apps to mobile devices. In a few years the hardware will catch up.
An NDA could be a reason enough for not talking about OpennGL behind employer’s back, but newsletters were official - no NDA should be in conflict with the very fact that newsletter is released. It could at most limit the extent of information provided within newsletter to some ridiculous minimum, but the show must go on.
If some company starts working in secrecy, it is typical that they’re trying to ensure everyone that they mean business. No company wants to loose their reliability by dissapearing without a word.