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 7 of 10 FirstFirst ... 56789 ... LastLast
Results 61 to 70 of 96

Thread: Official feedback on OpenGL 4.3 thread

  1. #61
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    The binding part can be moved to a sluggish wrapper around the DSA driver
    You can't move the binding part anywhere, because you still need binding in order to render.

    Also, what is a "core DSA context"? That sounds suspiciously like deprecation, which as previously stated, isn't going to happen again. Indeed, notice how implementations only implemented ARB_debug_output in debug contexts, but KHR_debug is now core. That shows that the ARB doesn't like splitting functionality between different context flags like they.

    They have only one split right now: core/compatibility. They're not going to make compatibility/core/coreDSA.

  2. #62
    Junior Member Newbie
    Join Date
    Jun 2009
    Posts
    18
    Quote Originally Posted by Alfonse Reinheart View Post
    They have only one split right now: core/compatibility. They're not going to make compatibility/core/coreDSA.
    I was thinking compatability/coreDSA. People who can't or won't rewrite can use compatability or previous core versions, and new projects can use DSA. I do concede that such a change may be too radical for a committee to agree on, but something radical is needed if GL is ever going to come close to DX.

  3. #63
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Besides the form of the API (which is generally a stylistic question), in what way is OpenGL lagging behind D3D?

  4. #64
    Junior Member Newbie
    Join Date
    Jun 2009
    Posts
    18
    Quote Originally Posted by Alfonse Reinheart View Post
    Besides the form of the API (which is generally a stylistic question), in what way is OpenGL lagging behind D3D?
    Disregarding the source of the problem wouldn't work. Compare:

    Code :
    void OpenGLEngine::Buffer::Update(PVOID data)
    {
        glBindBuffer(..., mBuffer);
        glBufferSubData(..., data);
        glBindBuffer(..., 0);
    }
     
    void Direct3DEngine::Buffer::Update(PVOID data)
    {
        context->UpdateSubresource(mBuffer, ..., data, ...);
    }

    Notice how the stylistic form of the API affects the number of API calls.

  5. #65
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,215
    Quote Originally Posted by absence View Post
    Disregarding the source of the problem wouldn't work. Compare:

    Code :
    void OpenGLEngine::Buffer::Update(PVOID data)
    {
        glBindBuffer(..., mBuffer);
        glBufferSubData(..., data);
        glBindBuffer(..., 0);
    }
     
    void Direct3DEngine::Buffer::Update(PVOID data)
    {
        context->UpdateSubresource(mBuffer, ..., data, ...);
    }

    Notice how the stylistic form of the API affects the number of API calls.
    It's actually worse because you need to save out and restore the previously bound buffer, otherwise you're potentially going to mess with state used for drawing (e.g. VAO state). That is the single biggest problem here - there's an artificial connection between state used for drawing and state used for creating or updating and each can mess with the other.

    Yes, we all know that this can be abstracted away in your own "UpdateBuffer" routine - that's not the point. This point is: you shouldn't have to. It's putting extra work on the developer, creating bear traps for inexperienced people to get caught in, and building more points where things can go wrong into your program. A good API helps you to use it properly and helps you to avoid this kind of basic mistake.

    Quote Originally Posted by absence View Post
    I was thinking compatability/coreDSA. People who can't or won't rewrite can use compatability or previous core versions, and new projects can use DSA. I do concede that such a change may be too radical for a committee to agree on, but something radical is needed if GL is ever going to come close to DX.
    DSA as it is will never go into core. Much of it relates to deprecated functionality, some of it has been superseded (why use glTextureParameteriEXT when you've got sampler objects?) and some of it is already there (glProgramUniform calls for example). What really needs to go to core as a matter of priority is buffer and texture updates; anything else needed can follow at it's own pace.
    Last edited by mhagain; 09-16-2012 at 03:15 PM.

  6. #66
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Quote Originally Posted by absence View Post
    Disregarding the source of the problem wouldn't work.
    The source of what problem? What problem are you trying to solve with this? Because I don't see one.

    The number of API calls is generally irrelevant to performance. Or if it is relevant, you need to prove that it is in some way. This is even moreso when considering that most of these API calls won't actually touch GPU state directly.

    Quote Originally Posted by mhagain View Post
    A good API helps you to use it properly and helps you to avoid this kind of basic mistake.
    Yes, but nobody's saying that OpenGL is a good API. My claim is that OpenGL does not need anything to "come close to DX". OpenGL is just as functional and performance as Direct3D. Yes, they do things a different way, and OpenGL would be better off if we could magic many of its functions out of existence and magic a bunch more into existence. But that's not going to happen.

    DSA is not a new concept. And as much as NVIDIA keeps trying to push DSA, the ARB seems just as determined to avoid DSA. It's not going to happen, so there's no point in wishing that it would.

  7. #67
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    600
    DSA is not a new concept. And as much as NVIDIA keeps trying to push DSA, the ARB seems just as determined to avoid DSA. It's not going to happen, so there's no point in wishing that it would.
    .. but DSA is slowly happening, for example as you noted that glProgramUniform found it's way into core (you can argue it was needed for SSO, but there was function to make which "sub"-program active for glUniform as well). In addition, sampler objects have a DSA interface. As you stated the big ones are buffer objects and textures.. I'd also argue vao's as well and to a lesser extent FBO's. In the ARB's defense, for editing buffer objects there are already sme bind points that are not related to rendering: TEXTURE_BUFFER, COPY_READ_BUFFER and COPY_WRITE_BUFFER.. indeed TEXTURE_BUFFER as a binding point for a buffer object affects NOTHING. So one can fake DSA's for buffer objects by simply always using TEXTURE_BUFFER as the bind point for modifications.. this is still worse than having DSA, but avoids all those bear traps. This might be why DSA on buffer objects is not happening so quickly... or just the ARB does not like introducing lots and lots of functions at one go.

  8. #68
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,215
    Quote Originally Posted by Alfonse Reinheart View Post
    DSA is not a new concept. And as much as NVIDIA keeps trying to push DSA, the ARB seems just as determined to avoid DSA. It's not going to happen, so there's no point in wishing that it would.
    But the ARB ain't avoiding DSA. Sampler objects have a DSA API (and they're primarily from AMD, so less of the "NVIDIA trying to push" thing because it's just not true). glProgramUniform is in core. Some form of DSA is getting there, slowly but surely, and not the very same as the GL_EXT_direct_state_access spec, but it's getting there.

  9. #69
    Junior Member Newbie
    Join Date
    Jun 2009
    Posts
    18
    Quote Originally Posted by Alfonse Reinheart View Post
    The source of what problem? What problem are you trying to solve with this? Because I don't see one.
    I think mhagain hit the nail on its head:

    Quote Originally Posted by mhagain View Post
    there's an artificial connection between state used for drawing and state used for creating or updating and each can mess with the other.
    Quote Originally Posted by Alfonse Reinheart View Post
    Yes, but nobody's saying that OpenGL is a good API. My claim is that OpenGL does not need anything to "come close to DX".
    That is a contradiction. A good API is exactly what OpenGL needs to come close to Direct3D. As you say, it's not about performance or features.

    Quote Originally Posted by mhagain View Post
    DSA as it is will never go into core.
    Just to be clear, I meant the concept of DSA, not the current implementation of the extension.
    Last edited by absence; 09-17-2012 at 03:57 AM. Reason: typo

  10. #70
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,215
    It's worth noting that back in the old GL 1.1 vs D3D 3 days, the fact that OpenGL was unquestionably a better API was a very significant influencing factor. Both had similar capabilities and could hit similar performance, but OpenGL 1.1 helped the programmer to be productive, D3D 3 didn't. So the importance of an API being good shouldn't be downplayed; a good API lets you focus on productive and useful work that gets stuff done rather than on writing boilerplate and wrappers that should otherwise be needless. A good API lets you iterate more quickly on proof-of-concept work and lets you focus on fixing errors in and adding cool stuff to your own code rather than on dealing with bizarre and outdated design decisions.

    For me at least this is nothing whatsoever to do with any concept of OpenGL coming close to D3D. Each has it's own world-view that's subtly different from the other (and in some ways GL 4.3 is already quite well ahead of D3D 11, so if it were to come close it would involve it getting worse). This is to do with OpenGL becoming a good API again, in it's own right. So "just because D3D does it" is a poor reason to add functionality to OpenGL, but it's also the case that "just because D3D does it" is also a damn poor reason to not add functionality. Ignore what D3D does, look at what OpenGL does, ask yourself "is this screwed?", and if the answer is "yes" then ask "what needs to be done?" That's all.

Posting Permissions

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