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 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 59

Thread: Official feedback on OpenGL 4.2 thread

  1. #31
    Junior Member Newbie
    Join Date
    Jun 2009
    Posts
    18

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by Alfonse Reinheart
    Honestly, it's not "feature parity" that interests me so much as "niceness parity".
    I wish more people considered this. Direct state access is one of the prequisites for OpenGL to surpass DirectX, and yet there has been a lot of talk about "OpenGL finally catching up" of late.

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

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by absence
    I wish more people considered this. Direct state access is one of the prequisites for OpenGL to surpass DirectX, and yet there has been a lot of talk about "OpenGL finally catching up" of late.
    Direct state access is there at AMD and NVIDIA drivers. I also agree that it would be nice to have it in core, but I'm pretty sure the issue is that additing direct state access would require a lot of language change and editorial work on the spec. I think we can expect DSA to get into core only when the promised restructuring of the whole spec happens.
    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/

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

    Re: Official feedback on OpenGL 4.2 thread

    EXT_direct_state_access is there but the extension have too many issues to be used in production code. Many entry points are missing so that you are stock to OpenGL 2.1. + We are supposed to bind an object to create it... erm... not good.

    We need a serious update on direct state access!

  4. #34
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    591

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by Groovounet
    EXT_direct_state_access is there but the extension have too many issues to be used in production code. Many entry points are missing so that you are stock to OpenGL 2.1. + We are supposed to bind an object to create it... erm... not good.
    TexStorage almost did it for textures, but still did not. Time to whine.

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

    Re: Official feedback on OpenGL 4.2 thread

    Many entry points are missing so that you are stock to OpenGL 2.1.
    What entry points are missing? You have full DSA control over textures and their parameters, VAOs, program uniforms (programs were DSA before outside of uniform setting), samplers, and program pipeline.

    The only missing entrypoints I can think of are transform feedback objects and a couple of the newer FBO features (TextureLayer). Hardly something that stops people from using it in "production code."

    Really, what we need is to make state objects for those last bits of non-object state: the post-fragment tests (depth+stencil), blending/masking, and the viewport transform.

    + We are supposed to bind an object to create it... erm... not good.
    What are you talking about? The DSA extension specifically says:

    Quote Originally Posted by DSA
    Certain commands and queries provide direct state access to named objects ... and perform implicit object initialization when provided unused object names.
    For what do you need to bind an object to create it?

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

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by Alfonse Reinheart
    What entry points are missing?
    As an example, element buffer setting and vertex attrib divisor setting.

    Quote Originally Posted by Alfonse Reinheart
    For what do you need to bind an object to create it?
    Okay, on this point you are right, you don't need to bind an object to create it, but the object is not generated at the time you call glGen*. This *is* an issue.

    What I wanted to say is that EXT_direct_state_access is acceptable for now and I can understand why DSA didn't make it into core, actually I rather go on without DSA forever than having the current EXT_direct_state_access in core because it is ill-made (of course, this is just my opinion). I would be happy to see an ARB_direct_state_access extension put into core in the near future though.
    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/

  7. #37
    Junior Member Newbie
    Join Date
    Feb 2011
    Posts
    20

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by aqnuep
    Quote Originally Posted by absence
    I wish more people considered this. Direct state access is one of the prequisites for OpenGL to surpass DirectX, and yet there has been a lot of talk about "OpenGL finally catching up" of late.
    Direct state access is there at AMD and NVIDIA drivers. I also agree that it would be nice to have it in core, but I'm pretty sure the issue is that additing direct state access would require a lot of language change and editorial work on the spec. I think we can expect DSA to get into core only when the promised restructuring of the whole spec happens.
    I'm in favor of OpenGL 4.3 that will just be reworked specs WITHOUT any new extensions brought into core.

    Then they can start on working upon this new spec architecture.

    Also I think that while merging refactoring specs with letting new extensions into core may be doable, they should avoid refactoring and releasing next big OpenGL.

    OpenGL 3.0 was such a mess because they wanted to do too much in too short time. I hope they have learned something.

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

    Re: Official feedback on OpenGL 4.2 thread

    As an example, element buffer setting and vertex attrib divisor setting.
    Fair enough. Though the divisor was more recent than DSA, there was no excuse for not having element buffer attachment in DSA.

    but the object is not generated at the time you call glGen*. This *is* an issue.
    Is it? What exactly is the problem? You cannot tell the difference between glGen* creating the object and calls to a DSA function doing it.

    And even if it were a problem, implementations are in fact allowed to create the object at glGen* time, since there is no possible way for you to detect that this is happening. Indeed, I understand that NVIDIA's implementation does this.

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

    Re: Official feedback on OpenGL 4.2 thread

    Quote Originally Posted by Alfonse Reinheart
    And even if it were a problem, implementations are in fact allowed to create the object at glGen* time, since there is no possible way for you to detect that this is happening. Indeed, I understand that NVIDIA's implementation does this.
    You cought me again
    However, it would be still nice if the spec would explicitly require the object to be generated at glGen* time and to always require objects passed to modify or bind commands to be previously generated with glGen*.
    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/

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

    Re: Official feedback on OpenGL 4.2 thread

    However, it would be still nice if the spec would explicitly require the object to be generated at glGen* time and to always require objects passed to modify or bind commands to be previously generated with glGen*.
    It already requires the latter. Well, if you use a core context at any rate.

Posting Permissions

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