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 1 of 7 123 ... LastLast
Results 1 to 10 of 69

Thread: Toward Version 4.3

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

    Toward Version 4.3

    Rewrite the specification so that the extensions that are used to patch deficiencies in the current API become needless. How? Rewrite some parts of the spec. Which parts? The shader API in particular, get rid of the program pipeline hack, and borrow some good ideas from D3D shader attribute and uniform specification...

    Thanks ARB.

  2. #2
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Toward Version 4.3

    And thank you for trotting out the same tired old ideas that always get trotted out on this forum. Your contribution to the noise in this forum is appreciated.

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

    Re: Toward Version 4.3

    I may be repeating the same ideas...but let me guess something, this forum is for...feature suggestions right? And suggesting something once does not really help much. We need a way to keep the idea active. But it seems that regardless of whatever feature is suggested here, we always get the same noise and panic from someone, negative criticism!

  4. #4
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    152

    Re: Toward Version 4.3

    What do you mean by Program Pipeline hack?

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

    Re: Toward Version 4.3

    http://www.opengl.org/registry/specs...er_objects.txt

    A problem that could have been easily corrected by rewriting a little part of the specification instead.

    You see the problem is that extensions are being abused, so they are now for patching a problem with the core specification instead of only adding features. Some add more complexities to the API pipeline instead of enriching it.

  6. #6
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Posts
    152

    Re: Toward Version 4.3

    Yes, I am perfectly aware of this extension. What do you mean by "rewriting a little part of the specification"? What about backward compatibility? It is not so simple as you may think.

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

    Re: Toward Version 4.3

    What about backward compatibility?
    So sacrifice the proper development of OpenGL for the sake of backward compatibility? I thought backward compatibility is already solved by the compatibility profiles?

    It is not so simple as you may think.
    I don't think it's simple, but it's pretty possible.

  8. #8
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985

    Re: Toward Version 4.3

    Quote Originally Posted by glfreak
    So sacrifice the proper development of OpenGL for the sake of backward compatibility? I thought backward compatibility is already solved by the compatibility profiles?
    No, it's not. What you've suggested would have broken compatibility between OpenGL 4.0 core profile and OpenGL 4.1 core profile which is undesired.

    Quote Originally Posted by glfreak
    I don't think it's simple, but it's pretty possible.
    No, at least not how you imagine.

    I don't say program pipeline objects are the best invention ever but seriously, what makes you think that they are evil?
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

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

    Re: Toward Version 4.3

    No, it's not. What you've suggested would have broken compatibility between OpenGL 4.0 core profile and OpenGL 4.1 core profile which is undesired.
    How undesired? There may be some optimization/performance benefit and therefore there's a need to keep the option available, but if it's not really the case, then correcting a bad design decision should be more desirable over minor compatibility issues.

    I don't say program pipeline objects are the best invention ever but seriously, what makes you think that they are evil?
    Evil? Who said that? They are awesome! But they are a hack

  10. #10
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Toward Version 4.3

    And suggesting something once does not really help much.
    Suggesting it 30 times is also not going to help. It's negatively helpful because it drowns out other, legitimate suggestions.

    Don't you get it? The ARB doesn't listen to anything that happens in this forum. Why? Because of people who constantly suggest the same thing 30 times. Because of people who like to keep their pet ideas "active". This means that the only thing that happens here is people dropping random pie-in-the-sky drivel that has zero chance of ever being implemented.

    Continuing to make these unrealistic demands will only make the ARB continue to ignore anything that gets said here.

    http://www.opengl.org/registry/specs...er_objects.txt

    A problem that could have been easily corrected by rewriting a little part of the specification instead.
    I have no particular love for the ARB_separate_shader_objects specification. But here's a reality check for you.

    ARB_shader_objects, version 1.00 of GLSL, was finalized June 11, 2003. Almost 10 years ago. This is what defined the compilation model that GLSL has.

    When did we get ARB_separate_shader_objects? June 9, 2010: almost 7 years to the day that GLSL 1.00 came out.

    Do you think the GL community was silent about the compilation model? Do you think that ARB_shader_objects came out and everyone was like, "Hurray, we have to link our vertex and fragment shaders together, thus massively increasing compile times as well as the number of programs we need! Yay!"?

    No, the community was against it from day 1. Users were against it from day 1. But ATI had no real power and NVIDIA was to busy trying to shove CG down the ARB's throat, which left 3D Labs to basically get whatever they wanted. It took us SEVEN YEARS to get that undone.

    That was 7 years of complaints. Of OpenGL falling by the wayside. Of various other bad things. Etc. It took that long just to get a minimally functional version of what we should have had from the beginning.

    Here's another reality check for you:

    10 years ago, 3D Labs attempted to get the OpenGL API rewritten, with non-backwards compatible changes. That attempt failed. 5 years ago, NVIDIA and ATI tried to do the same thing. That attempt failed, and it failed at a critical time that OpenGL needed to be succeeding (ie: Windows Vista hurting DX10 adoption).

    Now given these facts, do you honestly believe that your personal request is going to make the ARB say, "You know what? We tried to rewrite this API twice and both failed. But that glfreak fellow makes a good point. So let's stop all work on the API to try to make another rewrite." Or will they simply continue ignoring everything that gets posted in this forum?

    Your suggestion is not going to be acted upon. Ever. No matter how many threads you make, no matter how many times you suggest it.

    OpenGL is what it will always be. It will be a functional but crufty API; the sooner you get over that, the better for everyone.

    You see the problem is that extensions are being abused
    How are extensions "being abused"? It's a core extension; you support it the way you would any core feature, except that you can also use it on hardware that can't support GL 4.x.

    Under what logic is this considered "abuse"?

    I thought backward compatibility is already solved by the compatibility profiles?
    Um, no. Compatibility profiles are for functionality that was removed from OpenGL. You can't just rip stuff out or replace it with new stuff. The point of backwards compatibility is that people can invest time and effort into code and know that it will work with later GL versions. That they can use new features with their older code. If I want to use shader_image_load_store, I shouldn't have to also upgrade all of my texture creation to use glTexStorage, for example.

    Even D3D doesn't haphazardly ransack its API the way you're talking. They only make major API changes at a major version number. And even those are not nearly as radical as they used to be.

    if it's not really the case, then correcting a bad design decision should be more desirable over minor compatibility issues.
    Minor? You're talking about radically altering the GLSL language. That's not a "minor compatibility issue." That's "my shaders don't work with GL X.Y."

Posting Permissions

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