OpenGL 3 Updates

[Dark Photon]

>> fps deltas mean absolutely nothing without a reference point.

true, I've seen this mentioned quite a bit.
but also milliseconds ( or whatever time unit ) also mean nothing without a reference point, thus they are equally invalid as using fps...percentage OTOH is a valid measurement

I guess it depends what your goal is. If % improvement is it, % makes sense. Otherwise I'd much rather see "I implemented this specific change to this specific algorithm and saved 5.5ms of draw time. That's real and tangible. That's useful. Unlike: "I got 10fps improvement", which means absolutely nothing other than ,maybe, "better". How much? No clue.

[CatDog]

"I got 10fps improvement", which means absolutely nothing other than ,maybe, "better". How much? No clue.

Ah, yes. Thats exactly the reason why I prefer talking about fps.

CatDog

[knackered]

I always seem to use batches-per-second and million-tris-per-second. If I'm tuning a pixel shader I draw a full-screen quad and work out the million-pixels-per-second.
FPS or even % are pretty meaningless unless you have information about the data being rendered, and the spec of the card (tri-throughput, fill-rate etc.)

[Brolingstanz]

True, if you have enough information you can infer a good bit from most any measure; however speaking in general terms with no such information can and often does produce a simoon of speculation ;-)

[Stephen A]

http://opengl3.org

A little lacking in the marketing department (the photo is, well, awful), but otherwise great!

Edit; Oops, this was mentioned several days ago. The comment on the photo still stands though.

[Korval]

# OpenGL 3.0 Specification Overview
# OpenGL hardware and driver plans - AMD, Intel, NVIDIA
# Developer's perspective on OpenGL 3.0
# The new Khronos Compute Working Group and how that affects OpenGL

#2 is probably the most important thing that they'll be discussing (except for the stuff that they won't be discussing). How committed they are, specifically Intel with its millions of low-end graphics chips that provide the worst support ever for OpenGL, to supporting OpenGL 3.0 will be key to its future utility.

It'll be interesting to see how they apologize for/cover up/gloss over the lengthy 1 year delay of GL 3.0. Personally, I'm expecting that they simply won't address it, instead taking their usual tactic of complete and total disdane for the GL community by ignoring the fact that this should have been done last year.

[Rob Barris]

Regarding presentation content being drafted for the OpenGL BOF at SIGGRAPH this year; if you had a top-10-or-more list of specific topics you'd like touched on, what would some of them be ?

For brevity, maybe we could agree to sweep all of the "why has it been so quiet since Oct-07" related questions into a single topic, maybe call that one "the path that has been taken" - plainly that's an important one to touch on.

[Korval]

Regarding presentation content being drafted for the OpenGL BOF at SIGGRAPH this year; if you had a top-10-or-more list of specific topics you'd like touched on, what would some of them be ?

OK, then I'll condense it into one query:

#1: Why is this 1 year later than you said, and why did everything go quiet for 9 months? And (depending on the answer. ie: if it isn't really good or something entirely out of their control) how can you possibly expect us to every trust you guys again, after your track record?

After that:

#2: What assurances do we have that GL 3.0 will be supported with mature, compliant implementations, unlike the support for GL 2.x? That is, can we assume that GL 2.x support will be how GL 3.0 is supported, or do we have any assurances that it will be compliantly supported? Will drivers be tested against a conformance test suite, and will this test suite be comprehensive?

#3: What is the minimum "hardware level" for GL 3.0 support? Will there be any mechanism for detecting "levels" of support? The original GL 3.0 was broken in 3.0 (DX9.0), 3.1 (DX9.0), and Mt. Evans (DX10+), which potentially made detecting the level of minimum hardware support a simple GL version check. Or testing for certain extension functions. Does GL 3.0 have anything similar?

#4: If GL 3.0 does not follow the basic design that was described to us in previous newsletters, why doesn't it? What was wrong with that design?

#5: Will there be some mechanism for compiling a "binary blob" of a shader and then reloading it into the driver at a later date? This was on-deck for consideration in Longs Peak Reloaded.

#6: We on this board have often discussed a particular feature for vertex rendering. The short term for this is "attribute offset indexed rendering". This allows you to pass a number to glDrawElements that is an offset to be applied to each index before dereferencing that index into a pointer. Will GL 3.0 provide this (which D3D has previously provided for quite some time)? This was likewise on-deck for consideration in Reloaded.

Can't think of others. I may add to it as I think about it.

[Rob Barris]

Thanks Korval, those are great questions.

[Brolingstanz]

I really like the reflected OpenGL logo.