unless you start loading/unloading assets during runtime; e.g. some sort streaming world
the inability to load precompiled shaders becomes a major problem then (stalls!)
Well, you could maybe stream content from disk and compile shaders at the same time. Looking down the road a bit I expect we’ll see more of that.
I’m just biding my time till quantum computers hit the shelves. That’s really exciting stuff. 20 or so years from now kids are going to look back on us and laugh uncontrollably.
Well, maybe then you should study more about quantum computing, than hope it solves everything :). QC is only good at finding the path of least resistance. Traveling-salesman type of problems, nothing more.
I don’t know how quantum computing works, but if it only solves the TSP, nothing more, then we shouldn’t waste time on it. 
CatDog
There are many useful/important things, that need the calculation of “path of least resistance”, so that’s why it’s researched: cryptography, finding the natural positioning of atoms in molecules, some NP-Complete probs. So, it’s not something for us to waste hope on.
Anyway, back to the original discussion: I’d suffice with a simple forum-post here instead of a formatted newsletter. Or a text-file somewhere.
I’m shure they would care, if there was some time left for it. But they are very busy in blocking themselves. There are no official representatives here on the board, because every single piece of information has to be nodded through by all members. A more openly discussion between ARB members could solve those issues (including the newsletter), but it also would require them to sing from the same song sheet. Which is obviously not the case.
CatDog
True, but that’s only the “load everything on startup” use case, which isn’t suitable for all apps.
In vis-sim, we stream multi-terabyte databases off disk at run time and render them at 60Hz (16.6ms/frame). During flight, we may need to load a model (and its materials/shaders/textures/etc.) that we haven’t seen before. Having OpenGL freeze up and go out to lunch for 130ms (8 frames!) or more to compile or reoptimize a shader is not an option. In this biz, 60Hz rules over content any day of the week. So content suffers.
GLSL shader compilation imposes these frame rate hits. Cg, while not cross vendor, likely provides a way around it… Cross platform vs. making frame. Former is desirable, but latter always wins. Hopefully the GLSL working group is listening.
Don’t think that helps you with streaming while rendering, does it? Your OpenGL driver can’t be compiling shaders in the background on one core at the same time it’s rendering on another core (AFAIK… please correct me if I’m wrong), and you can’t stream the compiled result between GL contexts (e.g. machines)…
…though if supported, these would otherwise would seem like very logical things to do. Precompiled shaders makes both of these options and others possible (e.g. storing off the shaders with a H/W ID). I’ll take a precompiled shader binary blob to what we have now in a heartbeat.
Dunno, but it seems like in either case it’d be difficult to spec an optimization like that.
DX11 claims improved MT support in the driver, through the use of specialized command buffers geared towards batch assembly. I can image something similar in GL that might also expose opportunities for the driver to compile stuff, so long as the results aren’t needed straight away.
You could in limited sense image the shader compilation itself to be a part of the batch construction, like a vertex buffer, texture or whatever, just another piece of content that may or may not need a “bit” of preprocessing. From where I sit this seems eminently doable, though I’m sitting far from any real responsibility for making it happen 
it wouldn’t be difficult to spec, it would be simple. Whatever command stream the driver ends up pushing to the card once a shader is built should be able to be pushed to a bit of system memory, allowing us to push it to a file. We can then push that binary to the driver through an additional entry point - the driver can validate it, and reject it under whatever criteria it wants (no need to spec this criteria). It’s simple. Two entry points.
you’re right. that’s simple.
It’d just be nice to have something you can eyeball for debugging purposes. I’ve caught a bug or two in DX’s fxc compiler that way, by just inspecting the generated listing. True, some of the vendors have tools of their own for this sort of thing, but it’d be nice if things were a bit more standardized/localized in this regard. Perhaps that’s just asking too much.
Speaking of debugging, it’d be good to hear more about the new debug context in GL3…
You mean that context that was officially added to GL3, but will never be implemented in any sensible way by any vendor whatsoever? In my opinion this debug-context simply shows the naivity of the ARB. If you want debugging, use Mesa or some tool like glIntercept or so.
It’s a new year and ~5 months since the GL3 spec was released. How’s that newsletter coming? Or better yet, how’s anything coming along?
Maybe the newsletter is also one of the “deprecated” features.
The effort within the working group is pretty much focused on completing the GL 3.1 specification at the moment.
As you know the 3.0 spec was completed last July and published in August; NVIDIA now has a released driver with a complete 3.0 feature set (and my understanding is that AMD is making steady progress in the same direction).
Since that time there have been some minor revisions and bug fixes to the 3.0 spec, taking place alongside the 3.1 work.
So in response to the question “how is anything coming along” - the 3.0 spec has the driver writers busy, 3.0 drivers are available to ISV’s to do development work on, and the design of 3.1 is evolving in parallel.
By all means if you have specific problems that you are trying to solve (i.e. feature requests) please bring them up in the “talk about your applications” thread - that will be one of several sources of feedback we look at for 3.1 and revisions beyond that.
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=246133#Post246133
By all means if you have specific problems that you are trying to solve (i.e. feature requests)…
My “feature request” is simply insight into the working group. Rob, you have done an immense about of positive “PR” in this regard with your regular participation in this forum. Thanks!
My personal pet peeve is, as always, the Newsletter. It’s actually what got me posting on this forum in the first place.
AMD still haven’t got it in their drivers even though they’ve had almost 7 months since the spec was finalised?
That doesn’t sound like a great endorsement of GL3 if it’s that difficult to modify a driver.
Yes, I’m sure that point hasn’t been made a gazillion times already.
Well, I’m not sure it makes sense to treat AMD’s progress as a Boolean. A casual examination of the release notes for the Catalyst drivers shows that a noticeable chunk of GL3 functionality was available in September:
http://forums.amd.com/game/messageview.cfm?catid=279&threadid=100240
- ARB_half_float_pixel
- ARB_draw_instanced
- ARB_instanced_arrays
- EXT_texture_compression_3dc
- EXT_texture_compression_rgtc
- EXT_texture_compression_latc
- EXT_texture_shared_exponent
- EXT_depth_buffer_float
- EXT_gpu_shader4
- ARB_map_buffer_range
so…why the delay?
as I say, GL3 is obviously the straw that broke the camels back for AMD. They hardly shone with previous simpler versions of the API.
We need an Obama to head up the ARB, then maybe it can move forward in a more decisive way.
Don’t mind me, just another day working around another driver bug.
Your question isn’t entirely clear to me. AMD indicated at the BOF that Q1 2009 was their target for 3.0 compliant drivers, IIRC. I suppose you could go back in time to the BOF and ask “why will it take that long?” - but from my POV there has not been a change or schedule slip relative to the plan of record. I’ll see if I can get one of the AMD folks to drop in here, if you don’t mind the 15-minute delay that might add to their schedule.