PDA

View Full Version : Official feedback on OpenGL 4.2 thread



Khronos_webmaster
08-08-2011, 09:00 AM
The Khronos™ Group today announced the immediate release of the OpenGL® 4.2 specification, bringing the very latest graphics functionality to the most advanced and widely adopted cross-platform 2D and 3D graphics API (application programming interface). OpenGL 4.2 integrates developer feedback and continues the rapid evolution of this royalty-free specification while maintaining full backwards compatibility - enabling applications to incrementally use new features, while portably accessing state-of-the-art graphics processing unit (GPU) functionality across diverse operating systems and platforms.

The OpenGL 4.2 specification has been defined by the OpenGL ARB (Architecture Review Board) working group at Khronos, and includes the GLSL 4.20 update to the OpenGL Shading Language. The OpenGL 4.2 specification contains new features that extend functionality available to developers and enables increased application performance. The full specification is available for immediate download at http://www.opengl.org/registry.

New functionality in the OpenGL 4.2 specification includes:

ARB_shader_atomic_counters GLSL built-in functions to query and increment/decrement atomic counters Counters stored in buffer objects ARB_shader_image_load_store allow shaders to load from, store to, and perform atomic read-modify-write operations to a single level of a texture ARB_texture_storage Immutable textures ARB_transform_feedback_instanced Draw multiple instances of the result of a transform feedback Without query and sync needed for DrawArraysInstanced() ARB_shading_language_420pack Collection of new GLSL features ARB_texture_compression_BPTC ARB extension since January 2010, promoted to core now Same formats as BC6H/BC7 in DirectX 11 ARB_base_instance Specify offset within buffer object for instanced drawing ARB_internalformat_query Find out supported number of samples per internal format ARB_compressed_texture_pixel_storage Modify an arbitrary subset of a compressed texture ARB_shading_language_packing allows GLSL shaders to read and write 16-bit floating-point encodings Pack small data types into one larger one ARB_map_buffer_alignment Pointer returned is aligned for SSE/AVX CPU instructions ARB_conservative_depth Shader constructs that help enable depth testing before fragment processing

Lastly, Khronos has simultaneously released a set of ARB extensions to enable as much OpenGL 4.2 core functionality as possible on previous generation GPU hardware; providing maximum flexibility and platform coverage for application developers.

Learn more about what is new in OpenGL 4.2 at the BOF at Siggraph, Wed, Aug 10th from 4- 6PM in the Pan Pacific Hotel, Crystal Ballroom B&C. http://www.khronos.org/news/events/siggraph-vancouver-2011

Groovounet
08-08-2011, 09:08 AM
Joy!

And reviewed (http://www.g-truc.net/post-0414.html#menu)

Geri.
08-08-2011, 09:13 AM
there should be a gl_arb_ray_tracing in the traditional path :P

mbentrup
08-08-2011, 12:11 PM
I have a quick question about the swizzle operators (Section 5.5 in the GLSL spec):


The individual components can be selected by following the variable name with period ( . ) and then the component name.


I always assumed that the swizzle operators can be used with any vector expression, not just variables (e.g. function results etc).

If this is the case, can the swizzle operators now be used on constants too, e.g. (1.0).xxx or 1.0.xxx ?

Alfonse Reinheart
08-08-2011, 02:24 PM
In review:

ARB_base_instance

Not the sexiest of extensions. And "DrawElementsInstancedBaseVertexBaseInstance"... really? There was no better alternative than that name?

Man, that one giant glDraw function from Longs Peak with 20 parameters is starting to sound better and better ;)

ARB_transform_feedback_instanced

Just a fix for lacking needed functionality.

ARB_compressed_texture_pixel_storage

I'm sure this is useful to someone. Just not me.

ARB_conservative_depth

I'm actually surprised that this one made it into the spec. It seems really low-level, but it has its place.

ARB_internalformat_query

I can't say I saw this coming. Though I have to say, it seems oddly named. It's more about multisample than internal formats. Though I suppose it could be extended later for other things, like asking if something is color-renderable.

Though that begs the question as to why that wasn't added into this extension.

ARB_map_buffer_alignment

Simple. Direct. To-the-point. Does an important job.

Good.

ARB_shader_atomic_counters

Didn't see this coming. After a cursory glance, the API seems reasonably well-specified and the functionality decent overall.

ARB_shader_image_load_store

Something so obvious that even I predicted it.

ARB_shading_language_packing

Meh. The functionality is fine and all, but it's not exactly blowing my skirt up.

ARB_texture_storage

Now we enter the realm of the bizarre.

Immutable textures have been something the ARB has wanted for years. Yet it's taken them this long to get it.

The behavior is very good, but I take some issue with how it's specified. It an API inconsistency.

It's obvious at this point that the ARB does not want to just add direct state access. They only provide DSA-style functions when they add new functionality, as they did here.

The problems are these. First, they provided old-style storage functions too. Why? I didn't see a big rush to provide old-style Sampler Object support. Yes, that's a new object type, rather than a modification of an older one. But it still feels inconsistent with the push towards DSA-style functions.

More importantly is this. If you create a texture object with this extension, you are almost guaranteed to later make a SubImage call. It's the only way to upload data; that's part of the purpose of this extension, right?

So... where is glTextureSubImage? You know, the DSA-style function that takes a texture object, not a type. If you call glTextureStorage2D, you have almost certainly not bound that texture to the context. So, you don't have to bind the texture to create the storage, but you have to bind the texture to upload to it? Doesn't that kinda defeat the purpose? Yes, I know you can use EXT_DSA, but if you don't want to (or the unlikely event that it's unavailable), what then?

It just seems inconsistent that they would add a function that strongly suggests using another function, but then not make that function available. And it's not like the ARB didn't use ARB_separate_shader_objects to add in the DSA version of program uniform setting. So this wouldn't be the first time the ARB added convenience functions to the language.

I do like the fact that you can specify compressed images without using different functions for them.

ARB_shading_language_420pack

AKA: ARB_glsl_doesnt_suck. Or ARB_glsl_is_cool_now.

I've never been a fan of these sorts of "bag of stuff" extensions, where they just bundle a bunch of functionality together. This is mostly due to fears about what hardware they will be implemented on. For something like ARB_gpu_shader5, it's obvious what hardware it'll show up on. But for something like this, which is mostly hardware agnostic, it seems weird. Indeed, according to the revision history, this is a Frankenextension, formed from the bones of many extensions and animated with lightning.

Fortunately, the extension's functionality seems to fit on GL 3.3-class hardware (though I wouldn't mind seeing a GL 3.4 that bundles this into core). A quick rundown of the bag of tricks:

Line continuation: Meh. Useful for #defines, but it doesn't exactly blow my skirt up. UTF-8 encoding: Sure why not. Implicit return value conversion: More banishing of stupid 3D Labs ideas. What hatred did those people have for implicit conversions anyway? Local 'const' variables with non-compile-time 'const' expressions: What took you so long? Qualifier ordering: Again, what took so long? GLSL has been accruing qualifiers like some kind of plague, but it's taken 9 revisions of the language to fix this? Uniform block `binding` location: Of course! Sampler unit `binding` location: See my comment on qualifier ordering. Initializer list: Somebody's read the C++11 specification. Good for you. Vector-type `.length`: Meh. If GLSL had templates or something, this might be useful, but I'm not sure I understand the purpose. Maybe for #define gimmickry. Scalar swizzles: Again, what kept you? Texel offset constants: Good

As they say in the StarCraft community: "It's about time."

ARB_faster_vertex_submission

No, that's not a real extension. It's just a place to register my disappointment that nothing has been done on this front.

ARB_separate_shader_objects

I honestly can't believe the ARB didn't fix ARB_separate_shader_objects. It's not like there weren't four (http://www.khronos.org/bugzilla/show_bug.cgi?id=433) bugs (http://www.khronos.org/bugzilla/show_bug.cgi?id=434) filed (http://www.khronos.org/bugzilla/show_bug.cgi?id=435) on this (http://www.khronos.org/bugzilla/show_bug.cgi?id=436) extension.

Yes, the last two are more "wish-list" than bugs (though I would say that they're more "this functionality is inconsistent with itself and poorly specified", which should count as a bug). And the ARB did fix the state tables in the 4.2 spec. But there is no excuse for GL_PROGRAM_SEPARABLE still not being listed in the program object state table.

Why bother advertising the Bugzilla database if they're just going to ignore it? The ARB has plenty of ways to ignore commentary; did they really need another?

Overall

A solid block of functionality (though little hardware-based). Some really good things, some really odd things, but overall, it was good. But I've only had a cursory glance at the extensions. And ARB_separate_shader_objects has shown that the devil is in the details.

So consider this a provisional grade of B+. Points were deducted for expecting me to type "DrawElementsInstancedBaseVertexBaseInstance", failure to address the vertex transfer issue, failure to bother to take an hour to read your bug list, and for not providing DSA-style texture uploading.

Oh, and when are we getting deferred contexts?

Alfonse Reinheart
08-08-2011, 06:01 PM
Actually, I'm bumping that score up to A-. The quick reference card is very nice this time around. It even has a pipeline reference.

Though I'm not sure if you can call it a "quick" reference if it has to have an index ;)

Alfonse Reinheart
08-08-2011, 09:26 PM
Idea for the ARB:

Many people would like a copy of the OpenGL specification in book form. Granted, I don't expect it to be a big seller, but there are some people who would certainly pay money for it. Just not enough to publish it.

At least, not through a traditional publisher. But a less traditional publisher like Lulu Press would actually be a pretty decent idea. The PDF would always be available for free, and it doesn't cost much of anything to just make a "book" available through them. You could sell it for something like $20.00 or so.

Everyone wins. The ARB gets a little extra pocket money. The users get to have the spec in book form reasonably inexpensively.

mbentrup
08-08-2011, 10:09 PM
Hi Alfonse,

i guess you did't see this paragraph of ARB_texture_storage:


Dependencies on EXT_direct_state_access

If EXT_direct_state_access is not present, references to TextureStorage* should be ignored.


So the old-style TexStorage* functions are needed when you have no DSA extension.

Heiko
08-09-2011, 12:57 AM
More OpenGL goodness. Very nice!

Gedolo
08-09-2011, 06:42 AM
No direct state access?
What does Khronos has against that?
Just add DSA counterparts of the non DSA stuff.

And seriously why do they even continue to make this a minor version bump? The changes seem to better reflect a OpenGL 4.1.1 instead of OpenGL 4.2.

This really hints at using the minor version number for big hardware generation changes and a third number after that for this kind of stuff. And you could use the major version number to change the api and the context creation calls while avoid breaking old software.


And something about the following:

ARB_shading_language_420pack

I'm assuming the 420 stands for the shading language version 4.2.0 please use separators.

Such as underscore (using underscores is the most consistent way I think) e.g.: ARB_shading_language_4_2_0_pack

This way you won't have a problem when one of the numbers reaches 10 or higher. Which has been a big problem for at least one project a while back. (Don't remember what it exactly was. Just that they had problems with versions above 9.)

Alfonse Reinheart
08-09-2011, 09:59 AM
This really hints at using the minor version number for big hardware generation changes and a third number after that for this kind of stuff. And you could use the major version number to change the api and the context creation calls while avoid breaking old software.

Well, the ARB has been consistent about using the major version for hardware generations since OpenGL 3.0. And they have been consistent about not doing API changes since OpenGL 1.0. So really, there's no point to doing it this way.


This way you won't have a problem when one of the numbers reaches 10 or higher.

It's just a string. There's no problem because it's only an identifier. Oh, and it's not 4.2.0; it's 4.20. GLSL versions use 2 digits for the minor version. For some reason.

Jan
08-09-2011, 12:20 PM
"glDrawElementsInstancedBaseVertexBaseInstance" - Just Wow.


Nice to see that OpenGL is still updated regularly and more and more details are fleshed out to make ones lives easier. But that's basically it - details. I don't see anything that interests me enough to actually read the specification in more detail. I assume that's a good thing, though.

However, I'm disappointed that DSA is still not there yet. It's IMO the most important "feature" for future OpenGL, because writing a good / modern rendering engine with OpenGLs current bind/modify method is just inefficient, awkward and error-prone.

I hope it's in the pipeline and we'll see it soon.

Jan.

PkK
08-10-2011, 03:05 AM
I wish we could get a "clean" version of the spec - one with all deprecated functionality removed.

Philipp

mfort
08-10-2011, 03:07 AM
Deprecation has been deprecated.

We now have Core and Compatibility profiles. The core spec is here: http://www.opengl.org/registry/doc/glspec42.core.20110808.pdf

Chris Lux
08-10-2011, 06:50 AM
I also like the new Spec very much, despite the very obvious missing parts with direct state access and shader includes...

Great Work!
-chris

PkK
08-11-2011, 05:49 AM
Deprecation has been deprecated.

We now have Core and Compatibility profiles. The core spec is here: http://www.opengl.org/registry/doc/glspec42.core.20110808.pdf


Ok, I didn't notice how few deprecated features there are in the spec (I found only line width and some queries).

Philipp

P.S.: Why is COMPRESSED_TEXTURE_FORMATS not included in the list of deprecated features in E2.1, but mentioned as deprecated in L4.2?

cutting_crew
08-12-2011, 10:15 AM
so Nvidia has an implmentation NOW. AMD will have one soon. Now let's guess on how long it will take Apple to work with both of them to incorporate changes onto their systems.

Ilian Dinev
08-12-2011, 10:26 AM
Correction: AMD also have an implementation NOW :) .

cutting_crew
08-12-2011, 10:39 AM
Correction: AMD also have an implementation NOW :) .

thats nice to know. Not good though if you are wanting to try out things on the mac. I wonder if OpenGL ES 2.0 has more functionality(shader) on the iOS side than the desktop drivers.

Alfonse Reinheart
08-12-2011, 11:03 AM
I wonder if OpenGL ES 2.0 has more functionality(shader) on the iOS side than the desktop drivers.

No, it doesn't. Even the Mac's 2.1 implementation has access to EXT_gemoetry_shader4.

Don't Disturb
08-12-2011, 11:43 AM
ARB_shader_image_load_store is a really big deal! Shaders can scatter as well as gather which is going to enable some interesting techniques.
I'm just wondering how it will perform - has anyone given it a try yet?

Ilian Dinev
08-13-2011, 01:02 AM
ARB_shader_image_load_store ...
- has anyone given it a try yet?

OIT stuff,
and http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=296393#Post2963 93

aqnuep
08-15-2011, 01:38 AM
Wow, I'm just back from holiday and here we have GL 4.2.

Very nice update with a lot of useful features, even though only about half of the features I wanted to see in GL 4.2 were actually added.

Rob Barris
08-15-2011, 04:16 PM
Very nice update with a lot of useful features, even though only about half of the features I wanted to see in GL 4.2 were actually added.

By repeating this process over time, the feature set will asymptotically approach your needs!

aqnuep
08-16-2011, 12:00 AM
I know that. Obviously they had some real tough extensions to discuss this time (I mean here especially the ARB_shader_image_load_store and ARB_shader_atomic_counters, even though the later was already almost complete a half year ago).

Anyway, what maybe we can say at least now with confidence is that GL 4.2 achieved feature parity with DX11 (at least from point of view of exposed hardware capabilities).

Alfonse Reinheart
08-16-2011, 01:42 AM
Obviously they had some real tough extensions to discuss this time (I mean here especially the ARB_shader_image_load_store and ARB_shader_atomic_counters, even though the later was already almost complete a half year ago).

Actually, I'd guess that most of the discussion was around ARB_shading_language_420pack and ARB_texture_storage. The former is really a merger of what seems like a half-dozen extensions, which much have been in development.

And ARB_texture_storage introduces functionality that I'm sure some in the ARB saw as superfluous. After all, there's nothing you can do with ARB_texture_storage that you can't with regular texture creation. And the immutability must have rubbed some of the more conservative elements the wrong way.


Anyway, what maybe we can say at least now with confidence is that GL 4.2 achieved feature parity with DX11 (at least from point of view of exposed hardware capabilities).

Honestly, it's not "feature parity" that interests me so much as "niceness parity". And 420pack really, really helps. Shaders are much more robust and stand-alone. And the last of the horrible 3D Labs-based nonsense is finally expunged from GLSL. It only took 10 revisions of the language and 6 years.

Also, I've come to appreciate why it's one extension instead of a half-dozen. If it were many extensions, then those using GL 3.3 would have to have a giant list of #extension enable lines at the top of every shader. That would be pretty terrible. This way, you just have one extension (or two if you're using pack) and that's it.

aqnuep
08-16-2011, 06:35 AM
Actually, I'd guess that most of the discussion was around ARB_shading_language_420pack and ARB_texture_storage. The former is really a merger of what seems like a half-dozen extensions, which much have been in development.

I agree that ARB_shading_language_420pack is very important as I was also very frustrated by the way how you attach bindings to uniforms as an example. However, atomic counters were even more important, I think, as without it we simply cannot implement OIT and other stuff efficiently. And before anybody tries to argue, atomic read/writes exposed by EXT_shader_image_load_store and now also by the ARB version is not equivalent with atomic counters. Atomic counters are more than 10 times faster than atomic read/writes on AMD hardware as they have special hardware for it, and it is also faster on NVIDIA as well.


Honestly, it's not "feature parity" that interests me so much as "niceness parity". And 420pack really, really helps. Shaders are much more robust and stand-alone. And the last of the horrible 3D Labs-based nonsense is finally expunged from GLSL. It only took 10 revisions of the language and 6 years.

Yeah, that's also important, however I'm more interested first in being able to solve a problem than how nicely I can solve it (no, I'm not saying that solving a problem elegantly is less important, however, functioning software has priority over that).


Also, I've come to appreciate why it's one extension instead of a half-dozen. If it were many extensions, then those using GL 3.3 would have to have a giant list of #extension enable lines at the top of every shader. That would be pretty terrible. This way, you just have one extension (or two if you're using pack) and that's it.

Good point as well, even though the name is kind of funky, it's better to have just a single extension.

Update: Actually I'm also very happy to see ARB_base_instance as this was a functionality that was present in hardware for quite some time but even ARB_draw_indirect didn't expose the functionality earlier. This is one of my favorites, even though the name glDrawElementsInstancedBaseVertexBaseInstance sounds a bit ridiculous :) Btw, I don't know why they didn't simply created two new functions with names like: glDrawElementsDirect and glDrawArraysDirect (analogous to the new indirect draw commands) which does the same like glDrawElementsInstancedBaseVertexBaseInstance and glDrawArraysInstancedBaseInstance. You can do all the glDraw* commands with these two by using proper parameters so people could migrate to the new commands and we could mark all the rest of glDraw* commands as deprecated. Also, it would be great to see glMultiDraw* versions as well (what we have at least for indirect drawing thanks to AMD_multi_draw_indirect).

malexander
08-24-2011, 08:46 AM
Thanks for promoting ARB_shader_load_store and the atomic counters, while adding useful features for older hardware. Expanding the shader bindings is great, though I'm still not a big fan of the layout syntax.

However, the one ARB extension I do take issue with is ARB_internalformat_query - not for what it does, but for how it's named. In all instances of "query" in the registry, the use of query as a noun indicates a query object (ARB_occlusion_query, ARB_timer_query), whereas its use as a verb indicates a synchronous, object-less fetch of the information (ARB_texture_query_lod, OES_query_matrix). So at least it should be ARB_query_internalformat.

Further to this, the extension doesn't actually query the internal format of a texture, which I was really hoping for when I saw it. Rather, it queries the supported multisample counts for a given internal format. In my opinion, the extension should have been called ARB_query_multisample. Sorry if this comes across as a bit pedantic, and I realize it's likely too late to do much about, but it felt misleading enough to me to point out in the feedback thread.

Alfonse Reinheart
08-24-2011, 01:27 PM
If you check the issues for that extension, it was going to be much more ambitious, but they scaled it back for the current release.

The name makes sense because it's providing a query mechanism for internal format information. It just doesn't do much with that mechanism yet.

malexander
08-24-2011, 07:01 PM
I saw that, but that still implies a future extension with a different name. Perhaps ARB_internalformat_query2, 3, etc. are coming, but the name still doesn't do much for the current extension.

absence
08-25-2011, 12:18 AM
Honestly, it's not "feature parity" that interests me so much as "niceness parity".

I wish more people considered this. Direct state access is one of the prequisites for OpenGL to surpass DirectX, and yet there has been a lot of talk about "OpenGL finally catching up" of late.

aqnuep
08-25-2011, 12:44 AM
I wish more people considered this. Direct state access is one of the prequisites for OpenGL to surpass DirectX, and yet there has been a lot of talk about "OpenGL finally catching up" of late.

Direct state access is there at AMD and NVIDIA drivers. I also agree that it would be nice to have it in core, but I'm pretty sure the issue is that additing direct state access would require a lot of language change and editorial work on the spec. I think we can expect DSA to get into core only when the promised restructuring of the whole spec happens.

Groovounet
08-25-2011, 04:33 AM
EXT_direct_state_access is there but the extension have too many issues to be used in production code. Many entry points are missing so that you are stock to OpenGL 2.1. + We are supposed to bind an object to create it... erm... not good.

We need a serious update on direct state access!

kRogue
08-25-2011, 04:44 AM
EXT_direct_state_access is there but the extension have too many issues to be used in production code. Many entry points are missing so that you are stock to OpenGL 2.1. + We are supposed to bind an object to create it... erm... not good.


TexStorage almost did it for textures, but still did not. Time to whine.

Alfonse Reinheart
08-25-2011, 05:14 AM
Many entry points are missing so that you are stock to OpenGL 2.1.

What entry points are missing? You have full DSA control over textures and their parameters, VAOs, program uniforms (programs were DSA before outside of uniform setting), samplers, and program pipeline.

The only missing entrypoints I can think of are transform feedback objects and a couple of the newer FBO features (TextureLayer). Hardly something that stops people from using it in "production code."

Really, what we need is to make state objects for those last bits of non-object state: the post-fragment tests (depth+stencil), blending/masking, and the viewport transform.


+ We are supposed to bind an object to create it... erm... not good.

What are you talking about? The DSA extension specifically says:



Certain commands and queries provide direct state access to named objects ... and perform implicit object initialization when provided unused object names.

For what do you need to bind an object to create it?

aqnuep
08-25-2011, 06:51 AM
What entry points are missing?

As an example, element buffer setting and vertex attrib divisor setting.


For what do you need to bind an object to create it?

Okay, on this point you are right, you don't need to bind an object to create it, but the object is not generated at the time you call glGen*. This *is* an issue.

What I wanted to say is that EXT_direct_state_access is acceptable for now and I can understand why DSA didn't make it into core, actually I rather go on without DSA forever than having the current EXT_direct_state_access in core because it is ill-made (of course, this is just my opinion). I would be happy to see an ARB_direct_state_access extension put into core in the near future though.

przemo_li
08-25-2011, 08:40 AM
I wish more people considered this. Direct state access is one of the prequisites for OpenGL to surpass DirectX, and yet there has been a lot of talk about "OpenGL finally catching up" of late.

Direct state access is there at AMD and NVIDIA drivers. I also agree that it would be nice to have it in core, but I'm pretty sure the issue is that additing direct state access would require a lot of language change and editorial work on the spec. I think we can expect DSA to get into core only when the promised restructuring of the whole spec happens.

I'm in favor of OpenGL 4.3 that will just be reworked specs WITHOUT any new extensions brought into core.

Then they can start on working upon this new spec architecture.

Also I think that while merging refactoring specs with letting new extensions into core may be doable, they should avoid refactoring and releasing next big OpenGL.

OpenGL 3.0 was such a mess because they wanted to do too much in too short time. I hope they have learned something.

Alfonse Reinheart
08-25-2011, 12:42 PM
As an example, element buffer setting and vertex attrib divisor setting.

Fair enough. Though the divisor was more recent than DSA, there was no excuse for not having element buffer attachment in DSA.


but the object is not generated at the time you call glGen*. This *is* an issue.

Is it? What exactly is the problem? You cannot tell the difference between glGen* creating the object and calls to a DSA function doing it.

And even if it were a problem, implementations are in fact allowed to create the object at glGen* time, since there is no possible way for you to detect that this is happening. Indeed, I understand that NVIDIA's implementation does this.

aqnuep
08-26-2011, 12:33 AM
And even if it were a problem, implementations are in fact allowed to create the object at glGen* time, since there is no possible way for you to detect that this is happening. Indeed, I understand that NVIDIA's implementation does this.

You cought me again :)
However, it would be still nice if the spec would explicitly require the object to be generated at glGen* time and to always require objects passed to modify or bind commands to be previously generated with glGen*.

Alfonse Reinheart
08-26-2011, 12:41 AM
However, it would be still nice if the spec would explicitly require the object to be generated at glGen* time and to always require objects passed to modify or bind commands to be previously generated with glGen*.

It already requires the latter. Well, if you use a core context at any rate.

Groovounet
09-07-2011, 07:24 AM
The OpenGL 4.2 and GLSL 4.20 specification has been updated:
http://www.opengl.org/registry/

Closed
09-07-2011, 09:38 PM
Good day! I was found some errors in OpenGL 4.2 (2011.08.22) spec:

1) section 2.14, page 155:

Original:
The state required to implement the viewport transformation is four integers and two clamped floating-point values for each viewport.

Error description:
Wrong! 6 floating values are required (4 - viewport, 2 - depth range), see glViewportIndexed* and GL_VIEWPORT_SUBPIXEL_BITS)

2) section 3.9 (Texturing), page 213

Format RGB565 is missing in table 3.12. So, it is unusable because missed sized internal format.

Sorry! If i'm wrong (:

Closed
10-04-2011, 09:32 AM
Updated NVIDIA/AMD driver status, introduced new bugs not included in article from www.g-truc.net. (http://www.g-truc.net)

www.steelratsoftware.com/index.php?option=com_content&view=article&id=54:op engl42driverstatus&catid=37:articles&Itemid=58#add comments

Stewox
10-19-2011, 01:11 AM
John Carmack of ID SOFTWARE says this about OPENGL

http://twitter.com/#!/ID_AA_Carmack/status/126421181069918208

kyle_
10-30-2011, 07:35 AM
Nice of Carmack to provide some advocacy (took him a while to notice the problem though;)
But what does this have to do with multiple threads?

Groovounet
10-30-2011, 07:23 PM
Because in we could use work threads to process meshs, textures anythings and upload them into the GPU memory. If we have to create a window for each thread, then we are wasting the framebuffer memory attached to this window.

mbentrup
10-31-2011, 12:22 AM
While I don't think that it is a big restriction that you need a window to create an OpenGL context (note that you don't need a window per thread), I sometimes wished that GLX/WGL would have a function that could create a new context, given just another GL context as input (compatible/shareable with the input context of course).

Especially when the original context is created by a library (like GLUT or SDL), it's quite painful to query the PixelFormat etc. of the original context to create a cloned context.

Alfonse Reinheart
10-31-2011, 01:44 AM
Especially when the original context is created by a library (like GLUT or SDL), it's quite painful to query the PixelFormat etc. of the original context to create a cloned context.

That doesn't make sense. If you want to create an off-screen context for doing uploading and so forth, pixel formats are completely irrelevant. You don't want a default framebuffer. You don't even have a window or DC to set the pixel format into. All you want is a new context that is shared with the old one.

One of the early ideas with wglCreateContextAttribsARB was that you would be able to pass NULL for the device context and thus create a display-less GL context. The 3.0 and above specs even have language that previous versions didn't for such eventualities.

Indeed, it may actually work now. You might be able to create multiple contexts from the same DC, but pass NULL for the DC when using wglMakeCurrent. According to the spec, this ought to be able to work. I'm not sure if I buy it though; someone ought to test it out.

mbentrup
10-31-2011, 03:52 AM
Especially when the original context is created by a library (like GLUT or SDL), it's quite painful to query the PixelFormat etc. of the original context to create a cloned context.

That doesn't make sense. If you want to create an off-screen context for doing uploading and so forth, pixel formats are completely irrelevant. You don't want a default framebuffer. You don't even have a window or DC to set the pixel format into. All you want is a new context that is shared with the old one.


Exactly. Unfortunately the HDC is required and WGL specifies that two contexts may only share resources if they use the same pixel format. (You may not even get the same results if you call wglGetProcAddress in contexts with different pixel format).

GLX does not explicitly state this requirement, but the driver may return BadMatch, if the contexts are "incompatible" for whatever unspecified reasons.



One of the early ideas with wglCreateContextAttribsARB was that you would be able to pass NULL for the device context and thus create a display-less GL context. The 3.0 and above specs even have language that previous versions didn't for such eventualities.

Indeed, it may actually work now. You might be able to create multiple contexts from the same DC, but pass NULL for the DC when using wglMakeCurrent. According to the spec, this ought to be able to work. I'm not sure if I buy it though; someone ought to test it out.

That language refers afaik to the case when you pass a NULL DC to wglMakeCurrent, but for the context creation the DC was always required.

In practice you won't find OpenGL apps that use *only* windowless contexts and any windowless contexts are probably for uploading textures or using transform-feedback to fill buffers etc, which are then later used in the 'main' context, so I think a specific function to create a shareable context for a given GL context would be very useful.

Alfonse Reinheart
10-31-2011, 10:20 AM
In practice you won't find OpenGL apps that use *only* windowless contexts and any windowless contexts are probably for uploading textures or using transform-feedback to fill buffers etc, which are then later used in the 'main' context, so I think a specific function to create a shareable context for a given GL context would be very useful.

But that's my point: we already have one. wglCreateContextAttribs. Just pass it the same DC you used to create your windowed context. It also has a parameter for a HGLRC that it will be shared with.

kyle_
11-01-2011, 11:21 AM
If we have to create a window for each thread
This was never the case, though i recall seeing msdn article that says separate HDC's should be used to make contexts current on their threads if you draw to the same window.


But that's my point: we already have one. wglCreateContextAttribs.
wglCreateContext works just as well here (unless you care for, well, context attributes).

Alfonse Reinheart
11-01-2011, 11:35 AM
wglCreateContext works just as well here (unless you care for, well, context attributes).

wglCreateContext doesn't take a HGLRC to share with, so if you want sharing, you have to explicitly call wglShareLists afterwards. It's always good to be up-front about sharing.

Dan Bartlett
11-01-2011, 01:13 PM
One of the early ideas with wglCreateContextAttribsARB was that you would be able to pass NULL for the device context and thus create a display-less GL context. The 3.0 and above specs even have language that previous versions didn't for such eventualities.

Indeed, it may actually work now. You might be able to create multiple contexts from the same DC, but pass NULL for the DC when using wglMakeCurrent. According to the spec, this ought to be able to work. I'm not sure if I buy it though; someone ought to test it out.

If you look at issue 4) in the WGL_ARB_create_context (http://www.opengl.org/registry/specs/ARB/wgl_create_context.txt) extension specification , it reads:


4) Should there be a way to make a context current without binding
it to a window system drawable at the same time?

RESOLVED: Yes, but only in OpenGL 3.0 and later. This results in a
context with an invalid default framebuffer, the meaning of which is
defined in the OpenGL 3.0 specification.

NOTE: Apparently on Windows, opengl32.dll makes use of the drawable
argument to identify the namespace of the driver, so we may not be
able to work around it.

I guess this means that if you have 2 cards from different vendors with different drivers, then the hdc is being used to identify the driver to create the context using, which if you provide NULL it can no longer do (without guessing).

Whether this is something Microsoft can solve, or an unsolvable problem without using a different platform API (EGL or new OpenCL-like platform layer) I'm not sure.

Maybe some extra attribute in the context creation flags would be enough.



wglGetPlatforms(NULL, &num_platforms);
*allocate platforms buffer*
wglGetPlatforms(platforms, &num_platforms);
*choose a platform*
*free platforms buffer*

attributes[0] = WGL_CONTEXT_PLATFORM;
attributes[1] = chosen_platform;
attributes[2] = WGL_CONTEXT_MAJOR_VERSION_ARB;
attributes[3] = 4;
attributes[4] = WGL_CONTEXT_MINOR_VERSION_ARB;
attributes[5] = 0;
attributes[6] = WGL_CONTEXT_PROFILE_MASK_ARB;
attributes[7] = WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB;
attributes[8] = 0;

wglCreateContextAttribsARB(NULL, NULL, attributes);

Eosie
11-02-2011, 02:08 AM
I sometimes wished that GLX/WGL would have a function that could create a new context, given just another GL context as input (compatible/shareable with the input context of course).

It's there as the shareList parameter:

GLXContext glXCreateContext(Display *dpy, XVisualInfo *vis, GLXContext shareList, Bool direct);

AleX AciD
02-06-2012, 03:35 AM
The quick reference card describes non-existent functions: DrawArraysOneInstance and DrawElementsOneInstance.

thokra
02-22-2012, 04:18 AM
The spec clearly states that these functions are not part of the API but are merely used to explain the behaviour of actual functions.

biller23
02-22-2012, 10:32 AM
The spec clearly states that these functions are not part of the API but are merely used to explain the behaviour of actual functions.

This makes sense in the spec, but he's talking about the quick reference card. Why are these functions displayed there?

thokra
02-23-2012, 02:34 AM
On second thought, that's actually unnecesseary. :)

xahir
05-15-2012, 02:11 AM
Need of context creation for multiple threads is because of loading objects from files as I understand. Like 3d model or scene files, or shader files etc. But I have a basic problem about that besides context creation too.

If I want to load a model file containing vertex attributes or indices I'd rather want to save attribute info into OpenGL state...(ie. VAO).
Similarly for scene files there may be some render-to-texture effects so I will need to generate some framebuffers for that need while loading the file...
When I begin to load shader files I need to generate my pipelines...

And here is my problem: None of VAO, framebuffers or pipelines are sharable among contexts. Just because they refer to other objects. I still dont understand why they need to be client state and not server state. Because we are not holding onto object pointers or such. We are holding some object names which are given by the driver and being recognized across threads.

Display lists (ironically core profile is removing lists but DX is introducing lists for multiple threads) might be a solution if using buffers/shaders was valid.