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 3 of 22 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 212

Thread: Official feedback on OpenGL 3.2 thread

  1. #21
    Junior Member Regular Contributor Heiko's Avatar
    Join Date
    Aug 2008
    Location
    the Netherlands
    Posts
    170

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by dpoon
    Noticed the following whilst reading the GLSL 1.50 specs with changes (GLSLangSpec.1.50.09.withchanges.pfd).

    On page 45:
    The fragment language has the following predeclared globally scoped default precision statements:
    precision mediump int;
    precision highp float;

    The float precision predeclaration is new in GLSL 1.50 and is not marked in magenta.
    Are you sure? I already used that in GLSL 1.30.

  2. #22
    Intern Contributor
    Join Date
    May 2007
    Location
    Germany
    Posts
    50

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by glfreak
    Based on the fact that GL 3.2 is now competent with D3D 10 or 11 and evolving rapidly, but providing there will be reliable drivers soon. D3D will not be abandoned in a day. Will never. But supporting two rendering paths is now possible.
    It was always possible. I could not see why 3.2 should motivate more game developers going this way than before. If you don’t target the Mac or even more unlikely Linux there is simply no good reason to write an additional OpenGL rendering path. While the pure API Spec is getting better there are still so many holes when it comes to the infrastructure.

  3. #23
    Intern Contributor
    Join Date
    Apr 2001
    Location
    Sofia, Bulgaria
    Posts
    65

    Re: Official feedback on OpenGL 3.2 thread

    Are there plans to use ARB_sync with VBOs?

    For instance after calling glBufferData - the data will not be copied immediately, and it can be safely changed or deleted only after the sync object is signaled. Calling ClientWaitSync will copy the data immediately (as is the current behavior of glBufferData ).

    Is there a way to do this with the current API or an extension?

  4. #24
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by GeLeTo
    Are there plans to use ARB_sync with VBOs?

    For instance after calling glBufferData - the data will not be copied immediately, and it can be safely changed or deleted only after the sync object is signaled. Calling ClientWaitSync will copy the data immediately (as is the current behavior of glBufferData ).

    Is there a way to do this with the current API or an extension?
    I'm not certain what you're asking, but if it is whether we would make sync objects affect the behavior of previously existing API calls, there are no plans to do that. BufferData in GL 3.2 does just what BufferData always did before. Placing a fence after a GL command and waiting on the corresponding fence sync object in another context simply provides a (potentially) more efficient way to know that the command has completed from the point of view of the other context.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  5. #25
    Member Regular Contributor
    Join Date
    Aug 2008
    Posts
    445

    Re: Official feedback on OpenGL 3.2 thread

    Are ARB extensions #74 + #75 (at http://www.opengl.org/registry/) meant to be labelled as "WGL_ARB_create_context" and "GLX_ARB_create_context", or "WGL_ARB_create_context_profile" and "GLX_ARB_create_context_profile", or are they a special case because they modify existing extensions?

    Also just noticed that with wglGetExtensionsStringARB, NVidia beta drivers 190.56 display the extension string "WGL_ARB_create_context_profile", but not "WGL_ARB_create_context".

  6. #26
    Intern Contributor
    Join Date
    Apr 2001
    Location
    Sofia, Bulgaria
    Posts
    65

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Jon Leech (oddhack)
    I'm not certain what you're asking, but if it is whether we would make sync objects affect the behavior of previously existing API calls, there are no plans to do that....
    Ok, then lets call it glBufferDataRetained / glBufferSubDataRetained.

    Currently sending data to VBO (or any other buffer data object) works like this:
    1. Allocate and fill the data
    2. Give it to glBufferData
    3. glBufferData immediately makes a copy of the data (or sends it directly to the card which is unlikely)
    4. When glBufferData returns the data is no longer needed and I can delete or modify it

    What I want is to skip #3 to avoid the extra copy done by glBufferData. When using glBufferDataRetained the data will not be immediately copied and it cannot be changed/deleted till OpenGL signals that this data is no longer needed.

    The ARB_Sync API is probably not designed for this case but something similar can be very useful. Using the ARB_Sync semantics this functionality will work like this:

    1. Allocate and fill the data
    2. Give the data and a sync object to glBufferDataRetained
    3. glBufferDataRetained returns immediately without copying anything
    4. The next time I need to change or delete the data I check if the sync object is signaled - and if so I can use it right away. If the object is not signaled - I can either call ClientWaitSync (or whatever) to ensure the data is copied right away or I can allocate the changed data in a new place.

    Currently the only way (that I know of) to avoid the extra copying is to use glMapBuffer. And this is another can of worms...

  7. #27
    Junior Member Newbie
    Join Date
    May 2009
    Posts
    18

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Alfonse Reinheart
    Where anisotropy in core?
    Rob explained this here.
    Waiting OGL4 for features ten years ago? So stupid...

  8. #28
    Junior Member Regular Contributor Heiko's Avatar
    Join Date
    Aug 2008
    Location
    the Netherlands
    Posts
    170

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Executor
    Quote Originally Posted by Alfonse Reinheart
    Where anisotropy in core?
    Rob explained this here.
    Waiting OGL4 for features ten years ago? So stupid...
    There is no need to wait. The functionality is available for any vendor anyway. Just use the extension, why would that be a problem?

  9. #29
    Junior Member Newbie
    Join Date
    May 2009
    Posts
    18

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Heiko
    There is no need to wait. The functionality is available for any vendor anyway. Just use the extension, why would that be a problem?
    I want use core functionality only, but i forced use extension too, because core not have needed functionality. This is sad.

  10. #30
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Dan Bartlett
    Are ARB extensions #74 + #75 (at http://www.opengl.org/registry/) meant to be labelled as "WGL_ARB_create_context" and "GLX_ARB_create_context", or "WGL_ARB_create_context_profile" and "GLX_ARB_create_context_profile", or are they a special case because they modify existing extensions?
    We folded the profile extension into the same documents as the original create_context extensions, largely because it was necessary to get them out on time for SIGGRAPH, for arcane reasons involving the Khronos spec approval process. So they are two extensions, in one file.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

Posting Permissions

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