Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 5 of 17 FirstFirst ... 3456715 ... LastLast
Results 41 to 50 of 166

Thread: Official feedback on OpenGL 3.1 thread

  1. #41
    Junior Member Regular Contributor
    Join Date
    Mar 2007
    Location
    Latvia
    Posts
    225

    Re: Official feedback on OpenGL 3.1 thread

    Heiko: you are not wrong. ATI drivers do not expose geometry shaders to OpenGL.

  2. #42
    Super Moderator Frequent Contributor Groovounet's Avatar
    Join Date
    Jul 2004
    Posts
    934

    Re: Official feedback on OpenGL 3.1 thread

    Quote Originally Posted by skynet
    ARB_compatibility is absolutely necessary
    No, its not. You want to use ARB_uniform_buffer_object in immediate mode? No problem, ARB_uniform_buffer_object written against the GL2.1 specs. Just open a GL2.1 context and use them together.
    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".

    @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.

  3. #43
    Advanced Member Frequent Contributor
    Join Date
    May 2001
    Posts
    566

    Re: Official feedback on OpenGL 3.1 thread

    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.

  4. #44
    Advanced Member Frequent Contributor
    Join Date
    Nov 2002
    Location
    Latvia
    Posts
    626

    Re: Official feedback on OpenGL 3.1 thread

    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.

  5. #45
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    665

    Re: Official feedback on OpenGL 3.1 thread

    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.

  6. #46
    Junior Member Regular Contributor
    Join Date
    Apr 2001
    Posts
    180

    Re: Official feedback on OpenGL 3.1 thread

    *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?

  7. #47
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 3.1 thread

    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.

  8. #48
    Advanced Member Frequent Contributor
    Join Date
    Nov 2002
    Location
    Latvia
    Posts
    626

    Re: Official feedback on OpenGL 3.1 thread

    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>

  9. #49
    Junior Member Regular Contributor
    Join Date
    Apr 2001
    Posts
    180

    Re: Official feedback on OpenGL 3.1 thread

    Quote Originally Posted by Rob Barris
    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.
    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.

  10. #50
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 3.1 thread

    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

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •