pours pudman a tall glass of Reality Juice
may or may not taste of fail 
Meanwhile back at the office, Khronos celebrates a job well done:
[Removed as being in-appropriate by webmaster]
They’re not retarded; They’re just glDisabled!
For those that are there in person, please give them hell. Don’t let them sleaze out of this without calling them on their bullsh*t.
The only way I see out of this is if OpenGL is taken away from Khronos and given competent management.
Meanwhile back at the office, Khronos celebrates a job well done:
I’m no fan of what’s happened here (that’s putting it mildly), but that’s probably a little over the line.
This is probably more appropriate:
The only way I see out of this is if OpenGL is taken away from Khronos and given competent management.
You keep talking about Khronos as though the Khronos ARB is not composed of the exact same people who were members of the ARB before Khronos took over governorship.
Khronos as a whole gets stuff done. The OpenGL ARB is disfunctional because they are disfunctional. Don’t blame this debacle on Khronos.
jesus leadwerks, saying f uck is one thing, but putting up pictures of disabled people is quite another.
I’m disgusted with myself that I stifled a laugh. I must need a holiday.
The real problem with GL3 is, that I doesn’t solve any of the problems we have with GL so far… What happend is just the common core promotion.
They promised a clean API that works nice on DX9 herdware. Yes, there is a large market share of DX9 hardware out there I don’t want to miss. The problems of GL2.x persist - no predictable way to hit the fast path besides trial and error, no chance to query features, unpredictable driver behaviour, etc.
GLSL is as unusable as before.
The new API is nothing more than feature-mania. Promote to core, done! A better way would be an GL API, that was more DX9 centric, but with removed fixed function states. The new DX10/DX11 features were nice candidates for extensions in such an API. This is my main problem with the new API, just adding more features to an API doesn’t solve anything. It adds just more and more interactions between core and extensions. Damn, even some kind of ARB_query_hardware_features extension added to GL2.x would be better - this would solve 90% of all the problems I had with GL.
The next thing are the extensions that are promoted to the core… Framebuffers? This makes the core more and more unstable, framebuffers never worked correctly (and yes nVidia, your implementation isn’t correct too). Geometry shaders? For what? Seems like an ill fated stencil shadow generator. I have more CPU cores that I need - I can do any amplification faster on the CPU side.
Anyways… just my two cents about the API. But at the end of the day, this is just an academic discussion. On windows you have the DX9 path (with some D3DCAPS9 checking) and the DX10 path. On Apple you use AppleGL (somehow, the Apple extensions feel like D3D, nice nice nice). On consoles you have the console specific APIs anyways… Linux is just an opt-out for me.
Look what is happening now: Blizzard and id software get the vendor extensions to get their stuff running fast. Some GL3 backdoor for selected parties. I prospose the following extension.
Extension name:
EXT_isv_dependend
New tokens:
- VENDOR_BLIZZARD_EXT
- VENDOR_IDSOFTWARE_EXT
New functions:
- glSetVendor(GLenum vendor);
Interaction with core and extensions:
- None. Just a fast path for selected parties.
ARB or Khronos - or what the new name for the same old gang now is. Shame on you. Just big shame on you.
Anyways… just my two cents about the API.
Since you mentioned geometry shaders being in GL “3.0”, you obviously didn’t read it because geometry shaders aren’t in GL “3.0”.
Okay, this is absolutely the most ridiculous and immature kind of behavior that I have ever seen in these forums. Posting pictures of disabled people and constantly flaming is not really helping anything and is taking the conversation away from the subject itself. I feel truly disgusted, this is unacceptable way to debate and I hope the forum moderator will do something about this.
Look what is happening now: Blizzard and id software get the vendor extensions to get their stuff running fast. Some GL3 backdoor for selected parties.
Um, what? I don’t know why or how I’m defending OpenGL “3.0” here, but I see nothing that suggests anything of the kind. If you’re going to attack this nonsense, then attack it for what it is and isn’t, not due of paranoia about collusion between the ARB and certain game studios.
Thats why i want the binary save/restore as well, thats where i expect to save compile time.
The HLSL/Driver compiler fighting occurs because its bytecode is very low level, the bytecode i want is high level, ie. it still includes all the While/IF/For/Case structures.
The optimisations would just be simple stuff like rewriting
A := (BC)+2(8+(BC))(BC); as T := BC; A := T+2*(8+T)*T;
but i take your point that it doesn’t really matter if this is left to the driver instead as its doing most of the optimisation anyway.
I have read everything i could find on SGIS_texture_lod extension, it looks like it should be possible to do the streaming, i will definately try this out to see if it works.
Although it looks like some drivers pre-allocate the memory for all levels and some dont, so it only saves GPU memory with particular vendors.
This should only be a problem if i have lots of textures on older cards with limited memory.
Although it looks like some drivers pre-allocate the memory for all levels and some dont
If you’re trying to do this to save performance (only upload some of a texture unless you need more), it may work. If you’re trying to do it to save memory, give it up. As you point out, some drivers will allocate all the room necessary for the texture as a whole. But even drivers that don’t will want the texture as a whole to be in one contiguous block of memory. So when you decide to add another level, it will have to copy that memory to a new location. And that’s not good for fragmentation reasons.
So, perhaps they need to either rename this release as OGL 2.2, OGL3-alpha/beta, or hurry up and slap in the missing stuff into OGL3.1 and pretend 3.0 didn’t exist really.
The other option is to fork OGL. It is open source software, after all. If Khronos wants to then merge back in those features, so be it, but certainly no one needs to wait on them to get their act together. They should have been more open to community suggestions to begin with it sounds as it’s developers that need to be catered to here as best as you can, you know, those whom your API directly effects, so as with anything open source this communication is critical.
It sounds like OGL3.0 is an improvement, but that there is clear room to ramp up the improvements and get them out the door. OGL should be ahead of DX10. It’s open source. It literally has a world of help waiting to tackle it’s problems, so I hope that will quickly happen to it’s remaining challenges now, if not by Khronos then by a different group, especially now that these issues are so exposed/hated.
No it’s not.
It is open source software, after all.
For the last time, OpenGL is not open source! The term “Open” in this case referring to the fact that it is an open standard defined by a standards body (rather than one entity, ala Direct3D or IrisGL).
They should have been more open to community suggestions to begin with
That would only be true if the ARB were unaware of the fact that we wanted Longs Peak. Which is errant nonsense. The ARB went dark for a year because they knew the uproar that it would cause to release “not-Longs Peak”. And they waited until now to tell us so that they could at least stick a spec under our noses and get a few of us to say, “Well, at least we have a spec with some core features.”
You think nVidia put out those beta drivers for their health? No, they did it because at least a few of us will “just shut up and code” if they give us the means to do so.
If Khronos needs 6 months to get the next revision out, and promises to keep us in the loop about what’s going on -I’ll be a patient little boy.
Emphasis added. I wouldn’t be too… hopeful if all the Khronos head honcho can do is “hope”.
If they need a little more time, that’s fine. The worst part about the wait wasn’t the wait itself - it was not knowing anything. If communication is an area where Khronos is willing to be a little more flexible, they can take all the time they want to get things right IMO. Leaving the community in the dark was just wrong, and I hope this is a issue gets brought up at Siggraph.
BTW, I was reading the spec, and do I understand it correctly that it is now possible to use feedback loops with FBOs when the filtering mode is set to nearest (4.4.3)? It is a shame that multisample textures are still not supported…
[quote=“Timothy_Farrar”]
FYI, don’t underestimate the work actually involved loading from byte code (GL vs DX, how much time do you actually think is taken in parsing source to tokens [GL only] vs the rest of compile [DX and GL]). And don’t take my word for it, about this from,
http://ati.amd.com/developer/cgo/2008/Rubin-CGO2008.pdf [/QUOTE]
An interesting presentation, thanks.
However, I still think high level bytecode shaders do make a lot of sense. DX9 bytecode is somewhat too low level, sure. I’m thinking more high level bytecode (ala LLVM level), where the front end compiler does preprocessing, lexing, parsing, dead code removal, and basic optimizations (without assuming that registers are 4-wide floats). Just optimize away no-ops and eliminate some common subexpressions.
Some of the issues I’ve had with GLSL that are purely in front-end compiler code (all on OS X, because on Windows we only care about D3D9):
- When used in preprocessor macro, (ab) would produce correct result, whereas (ba) would produce zero. A was a texture lookup, b was a result of calling a function that does some computation. This was on OS X 10.4.x, incorrect behavior was on PPC machines (Intel was correct).
- Array initializers don’t work on OS X 10.5.4 (that’s latest drivers).
- Some sequences of #if … #elif … #endif were not working on OS X 10.4.x, #elif had to be changed to negative #if test.
- Multiplies by 1.0 sometimes are not optimized away. Lots of multiplies by 1.0 result where some certain shader combinations replace complex logic with basically a no-op (e.g. multiplying by shadow term - for non-shadowed shader, replace with *1).
- Accidentally declaring unused uniform samplers in vertex shader code would drop to software rendering (why accidentally? because we put vertex & fragment shaders into one file, with preprocessor guards around two main functions).
- Including functions that are never called would overflow native instruction limits and drop to software or fail compilation.
- Some others that I forgot.
All the above are preprocessor bugs, dead/unused code not being removed, no-ops not being removed.
Sure, a driver internally does a lot of extra compiling, optimizations and whatnot, and it has plenty of chances to be buggy in there. So it’s not like you’d be bulletproof against driver bugs. And yes, that actual compiling takes time, so it’s not like loading shaders would suddenly be lightning fast.
However, splitting out front-end does leave less chances for the driver to be buggy (good!), and makes shader loading somewhat faster (good!). That’s all I want.
it is now possible to use feedback loops with FBOs when the filtering mode is set to nearest (4.4.3)?
What is a “feedback loop”?
It is a shame that multisample textures are still not supported…
You say that as if they would ever be supported.
When used in preprocessor macro, (ab) would produce correct result, whereas (ba) would produce zero. A was a texture lookup, b was a result of calling a function that does some computation. This was on OS X 10.4.x, incorrect behavior was on PPC machines (Intel was correct).
Depending on what “b” is, that may be perfectly correct behavior. IE, calling “b” may put the graphics card in one of those states that makes derivatives unavailable.
Also, what makes you say that this has anything to do with the front-end? The fact that it was in a macro has nothing to do with what the backend compiler does with it being one way vs. another.
Multiplies by 1.0 sometimes are not optimized away. Lots of multiplies by 1.0 result where some certain shader combinations replace complex logic with basically a no-op (e.g. multiplying by shadow term - for non-shadowed shader, replace with *1).
The specification doesn’t guarantee that multiplies by 1.0 will be optimized away.
Emphasis added. I wouldn’t be too… hopeful if all the Khronos head honcho can do is “hope”. [/QUOTE]
What do you want him to do? Tell all the members how to vote?
If he said anything other than “hopes” you’d have immediately called B.S.