Sorry, I can’t resist.
Will the standard matrices be eliminated? Will there still be
glMatrixMode();
glFrustum();
glOrtho();
glTranslate();
glRotate();
glScale();
or we just make our own uniforms in the shader?
Of course, what about ftransform()?
They said at tha last OpenGL BOF: “No more matrices neither matrices stacks”. That’s part of the fixed pipeline so no reason to keep it. Our own uniforms is the right way to go.
No more ftransform as well.
I’m not entirely sure I agree with that decision. Removing such fundamental information from the hardware such as a modelview/projection matrix and ftransform() has got to be a bad thing. They can remove everything else (light parameters etc.), but this one thing seems to be a backward step.
I agree with knackered. Also i don’t remember them stating it that radical, so i am not sure ALL matrix stuff will be gone.
You will at least need a viewport and depth-range. So, why not tell the API modelview and projection matrix as well. Also, if the new and shiny display lists should actually be able to cull geometry, the API needs modelview and projection matrices and the vertex-shader needs to do ftransform. Otherwise the driver cannot do any culling.
I am pretty sure, that ftransform will stay. And matrices will stay in some form, as well. Stacks will be gone, sure, no problem. Matrix operations like glTranslate, glRotate, etc. will be gone, too. Maybe even glMultMatrix and glLoadIdentity, but doing EVERYTHING through shaders and uniforms would be, IMO a step backwards.
Jan.
I agree that viewport and depth-range have to stay but modelview and projection matrices are in the end just uniform parameters and IMH should therefore not get any special treatment.
Display lists? I was hoping they would go away too. Are you suggesting they will stay in a modified version?
[ www.trenki.net | vector_math (3d math library) | software renderer ]
It would be easy to provide glu functions for all the old matrix functions. Take this together with the implicitly defined “default” uniform block they were talking about a while ago, and you have the same semantics and the same syntax (plus an extra ‘u’ 
) as before, without bothering the spec.
Some geometry-based display lists are rumoured to stay in the new API.
Personally, I see no reasons for keeping the matrix stack. Albeit, arguments of knackered and Jan sound plausible.
I’d rather go 100% matrix free, and have everything done through shader’s uniforms.
I doubt we use those functions much anymore anyway…
We would kiss goodbye to culling of ‘geometry lists’ and any form of optimised transform hardware.
I’m all for a programmable pipeline, but something as fundamental as this should be isolated for possible hardware acceleration opportunities.
And what do you mean “I was hoping display lists would go away”? What harm have they ever done to you? They seem like an eminently sensible acceleration opportunity, they always did and they always will.
Fundamentalists, the whole bally lot of you.
hear, hear.
Removing such fundamental information from the hardware such as a modelview/projection matrix and ftransform() has got to be a bad thing.
Why?
We’re going 100% glslang here. As such, what’s the benefit of having matrix stacks?
And what about those of us who, for example, like the concept of a specific camera matrix and the concept of world space? The only reason to provide fixed-function matrix stacks is if you expect the context or something in the rendering system to actually look at them and infer something from it.
And that means that users of GL 3.0 will gain some benefit in adopting the FF-matrix stack in lieu of a set of matrices that they might otherwise prefer.
optimised transform hardware
There isn’t any; that’s all gone. Once hardware went all shader and dumped the FF stuff, it was all removed.
No, the 3dlabs Realizms were one of the first SM2.0 capable cards, but I know for sure they had dedicated transform circuitry which kicked in when it hit ftransform. I was told that the vertex was transformed in parallel to the vertex shader being executed.
Granted they’re out of the workstation business now, but it at least shows that they appreciated the savings they could make by doing something 99.9% of vertex shaders will do completely in parallel to the rest of the shaders execution - and the API made it possible. You’re going to remove that for no other reason than as part of a clean up operation.
Let’s not throw the baby out with the bath water.
BTW, I’m not advocating the stack, or even the separate matrices, just the ability to declare a single user-defined mat4 uniform as the VertexTransform uniform and the ftransform() function. That’s all I’d suggest.
Actually forget it, after reading back what I’ve written, the argument to keep it is pretty lame.
A modelview and projection matrix are good concepts in the future too, but rendering is in no way tied to such concepts, so the API doesn’t have to know your application uses such a concept. A lot of rendering uses neither modelview nor projection matrix. And for the cases where you do, it’s often better to use a fused MVP matrix, but not always (for instance rendering lots of low-poly objects with different modelview matrices). The developer is most likely in a better position to know which will be faster for his work than the driver.
Adding overhead to every single GL function. With display lists in the API every GL entry point will have to include a check to see if we’re currently assembling a display list.
I also have concerns about the elimination of matrix operations being a mistake, especially for newer developers and code protability/sharing between libs in general, OpenGL ES 2.0 has the same design in this respect. (I don’t really care if your opinion is you can write it in 20 minutes with a strong cup of coffee Mr Trevett).
As for display lists, they were always more abused than used. With drawelements(etc) and VBOs being the preferred path the right thing is elimination of display lists, it is a win for development and validation of drivers, support etc. Clearly the price is worth it. Yep some of us have to port procedural non optimal rendering code that could trivially build a display list for reuse, but when we’re using the driver layer as an allocator and data formatter maybe we deserve and need the exercise. The lack of a trivial glBegin/glEnd style immediate mode for trivial stuff is related and at times more annoying, but the benefits are even more obvious in terms of complexity performance and validation, again well worth it.
In general going to an entirely programmable system has issues for state driven rendering paradigms (ingrained in a lot of higher level rendering apps & middleware) due to the need for on the fly compilation for trivial ‘discovered’ state changes or complex state driven shaders but this is the nature of the beast. The benefits outweigh the problems.
These changes do make OpenGL more difficult to use especially for a beginner, but they also make it more difficult to abuse and significantly easier to deliver robust tested drivers. As a whole it is worth the pain and we can almost certainly expect to see matrix helper functions in a new glu lib.
Well, I only meant the geometry type of display list. Of course you’d bin the state display lists.
Anyway, surely the gl functions have a jump block? In other words, as soon as you hit a glNewList() you’d swap the function pointer table to one that feeds the dlist compiler.
dorbie, it’s not (just:)) about laziness it’s about giving the driver the opportunity to optimise the geometry for its particular implementation. It may want to interleave, or it may want to upcast int8’s to int32’s because it knows they’ll be faster on this particular hardware revision. It may wish to cull.
Anyway, surely the gl functions have a jump block?
The user might have cached that function pointer, so the “jump block” would have to be on the other side of every function call. As such, it’s still overhead; just not a whole lot.
In any case, the point is totally moot because GL 3.0’s API for geometry display lists will be object based like everything else. So creating a display list would involve creating a display list template object, filling out the appropriate parameters (the VAO and draw call you use with it), and then building the object. It’s one entrypoint for building the list, maybe one for deleting it, one for binding a display list to the VAO slot in the context, and one for rendering with a display list instead of a VAO.
The driver is not going to tristrip for index caching. You will still have to do the hard stuff for most if not all the gains. The driver cannot know the shader (well it might I suppose but that’s not always the case) and even so you have arbitrary attribute intent and arbitrary shader code, it can’t cast (no knowledge of intent although I guess promotion would be OK but I’m sure pointless) as for data packing… I dunno, I think the front end of all these pipelines need to support contiguous and strided batched prefetch and are particularly fast from VBOs in VRAM (we’re inevitably talking about non-volatile data here) and they’re very good at this, it’s what they do. I think it may be a dated argument.
Then consider the development cost, not just to IHVs but to everyone in terms of features and driver quality… If you want fast stick some big VBOs as indexed cache coherent tristrips in VRAM, once you do that I’m skeptical you’ll have any more to be gained that’s worth the expense and effort unless you’ve done something assinine like have non interleaved strided data in which case you get what you deserve. Finally is display list support really worth it if there is a marginal benefit that could be gained in an app anyway?
I think we should relegate them to the past.
P.S. on culling you have a point, but only a fool would rely on display list culling for optimization, again IMHO you get what you deserve & this is firmly in the display list abuse category and is a complete misunderstanding of their correct useage. Although in the banchmarketing stakes this has probably happened at times and I know MUCH worse has.
Ask me over a beer which company did a bound box test on display lists and used it to simply drop half of the lines drawn to cheat on the Viewperf CDRS benchmark because they knew they were near degenerate. It’s a sleazy business… Not the culling you had in mind.
The driver is not going to tristrip for index caching.
nVidia’s drivers do.
The only problem with display lists is that you cannot guarantee that an implementation will make it faster.
But you can guarantee that it won’t get slower.
to everyone in terms of features and driver quality
At a bare minimum, they will just take the VAO, copy the data out of the bound buffers into an identical VAO. It’d take maybe 4 hours to implement.
Well, display lists complicate things for the driver writer. If you have them each function has to check if it should be recorded into a display list. Then the display list stuff has to be stored somewhere and the driver would also need to be able to play them back. Life for the driver writer would be much easier if they didn’t exist.
[ www.trenki.net | vector_math (3d math library) | software renderer ]