Heiko: you are not wrong. ATI drivers do not expose geometry shaders to OpenGL.
Heiko: you are not wrong. ATI drivers do not expose geometry shaders to OpenGL.
I agree and I thing it's just a marketing issue. "We want our software being the lastest OpenGL version compliant to write it on our software feature list".Originally Posted by skynet
@glfreak: 1 What need you do have of Geometry Shader? 2 What need do you have that the tessellator unit won't improve?
And the list is ... short!
+ geometry shader are not really efficient on current hardware, nVidia a least it seems better with ATI hardware.
What gonna happen to big software like Lightwave 3D, Maya, Softimage, Quake/doom engines, and many others? Are they gonna port it to the compatibility extensions?
OpenGL is supposed to be a CAD oriented graphics API, and now it's missing most important features.
I would like to see ARB taking care of implementing these deprecated features since they are heavy burden on IHVs that can make their implementation unstable, and let the IHVs implement the rest of core functionality. Remind you that most of the deprecated core can be implemented on top of the current specification core, the rest don't need hardware specific drivers either.
Just don't screw it up more please.
Why the compatibility thing?!!!! WHHHHYYYY?
I so loved the idea that strict GL3.0 has all of the legacy stuff stripped, and that in 3.1 there could be a separate driver and separate header files if need be. And now?
If the extension is there in the specs, it means there is no way we will be able to remove all the legacy stuff, EVER!
The forward compatibility flag and new context creation function plus an old 2.1 context was the right way to go.
Arrrghh, I just can't hear it anymore!
THESE POOR CAD COMPANIES DON'T NEED TO WIGGLE THEIR LITTLE FINGER IN ORDER TO KEEP THEIR CURRENT SW WORKING. It will just work as always, even if the driver provides an _additionnal_ GL3.1 context. Nobody ever wanted pre-GL3.0 drivers to disappear from one day to another. And it won't happen in years, it would not have happened with Longs Peak either. You software developer are not forced to do anything just because a new GL spec appears.
We understand that; its ok.
We just DONT want to let pre-GL3.0 'features' to poisen the lean-and-mean GL3.1 driver. WGL_ARB_create_context allows us to specifically decide to use a GL3.1 context over an older version. By doing that I _deliberately accept_ that the deprecated features are gone. But I also _expect_ that the reduced driver complexity pays out in form of better stability and performance. With ARB_compatibility in background (which basically enables all old features by default) the driver _has_ to assume that I may use one of the old features and therefore can't enable any optimization that would be possible without the old cruft.
This is what actually real CAD companies think about OpenGL today: http://www.mcadforums.com/forums/fil..._evolution.pdf
Admitted, some of the arguments are a little off (they didn't evolve their rendering backend in ten years?!), but most of them are credible.
*scratches head* So all the "goodies" from 3.0 are available as extensions in 2.1, and 3.0 still allows basically everything from 2.1. Now comes 3.1 which uses the deprecation mechanism to remove a lot from 3.0, except it doesn't, so in reality, the deprecation mechanism is currently just smoke and mirrors. Or?
The reason I stopped coding OpenGL stuff was because I never knew if it would run on anything but my machine (especially GLSL shaders). Has anything changed in this regard?
Take some time to consider the possibilities. For example, the default downloadable GL driver could be the base 3.1 version without ARB_compat. It's already commonly the case that vendors provide basic GL drivers as well as "workstation optimized" GL drivers as two separate things. Prior to 3.1, both such drivers had to have the whole enchilada, including all the legacy code. Post 3.1, this is no longer the case because the legacy functionality has been defined as optionally present.
The key message of 3.1 is highlighting / emphasizing the feature set you should code to going forward. It's yet to be seen what the adoption rate of 3.1 + ARB_compat will be - since that would only apply to ISV's upgrading their apps to use 3.1 features, while resisting elimination of legacy code. The answer for those apps might be "you need the workstation class drivers with the extra ARB compat support if you want to run that app." Not every such app ships to a wide audience, some are internal / custom apps.
This is all off the top of my head, but it's completely doable. Don't be distracted by the ARB_compat extension; focus on learning the 3.1 core feature set.
I think once you step back from the assumption that an IHV can only ship one flavor of their driver, you might see where I am coming from.
If you aren't in the group described above (migrating a legacy app up to 3.1 while wanting to continue using legacy func) then the story is very simple - focus on the core feature set and code to that. The spec is shorter, the coding choices are fewer. The driver will never spend any cycles wandering between fixed func and shader mode because your app won't be asking for that type of behavior any more.
It just takes one lazy game developer to use compat extension in their game and the good idea is ruined. We will have to support them forever, and no more lightweight gl3 drivers.
By the way, are those gl3.h headers available somewhere? And yes, why <GL3/gl3.h> not <GL/gl3.h> like <GL/glaux.h>, <GL/glu.h>
I must admit I have no idea about how many flavors the various IHV keep, however I'm assuming that a driver is a non-trivial thing to write, and as such you'll want to minimize the number of parallel implementations. Is there really incentive enough for any significant number of IHV's to write optimized 3.1 only drivers?
In any case, 3.1 looks like a good step in the right direction. Most importantly however is, imho, that you managed to release it within the claimed timeframe.
Was thinking about this some more and just wanted to point out that all us developers want a few key things:
a - correctness - features work as advertised
b - performance - things run fast
c - simplicity - how much spec material to wade through.
Spec writing can directly influence 'c', but really only has an indirect effect on 'a' and 'b'. Improving 'a' and 'b' requires a healthy and active feedback loop between the providers of the implementation and its clients.
i.e. if you are running into problems with some code of yours that doesn't work right, or has some performance quirk, etc - the first stop really needs to be the dev relations department of the affected implementor. This is a process we participate in on an ongoing basis, it takes time and elbow grease but we get results that help our products work better.
Plainly most developers would prefer it if everything was perfect out of the box - that said, bugs do exist, so a developer that encounters a problem and doesn't circle back to the implementor with a bug report, breaks the feedback loop. But that loop provides the mechanism to really make progress on 'a' and 'b' for your app, you have to make that contact and speak up if something isn't right for you.
Posting Permissions
