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

Thread: Official feedback on OpenGL 3.1 thread

  1. #61
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: Official feedback on OpenGL 3.1 thread

    Quote Originally Posted by Lord crc
    If you read the presentation from when 3.0 was released, you'll see that the indended "retirement plan" for features were "Core -> Deprecated -> Extension -> Gone/Vendor specific extension"

    So they're just following their plan.
    but an extension means you opt-in the features. with the ARB_compatibility the features are just there...

  2. #62
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    666

    Re: Official feedback on OpenGL 3.1 thread

    Why not just prepare your data in some user-defined buffer and then just tell gl "copy this to that", why the extra READ/WRITE buffer semantic?
    Because GL has ugly bind points instead of an "object oriented" API. One buffer object can be bound to several bind points at the same time. So instead of specifying that you have to re-use existing bind points (which already have their own semantic), they decided to introduce two new bind points with a clearly defined semantic. I think, this is ok, because it allows you to copy data between two buffers without disturbing their original current binding.

  3. #63
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 3.1 thread

    Quote Originally Posted by Jan
    The copy-buffer extension looks nice and very useful. However, i have a few questions: The main reason for this is obviously loading data in parallel directly into a gl buffer.
    The central value is in being able to transfer chunks of data between buffers on the GPU efficiently, not necessarily using it as a tool for streamlining upload. Though you may have hit on an interesting idea here that should be tried.

  4. #64
    Member Regular Contributor
    Join Date
    Mar 2001
    Posts
    469

    Re: Official feedback on OpenGL 3.1 thread

    In D3D10, a common pattern is to create a resource with CPU write access, copy data from the CPU (either via mapping or resourcesubdata) and then copy it to a GPU-access-only resource.

    So with the extension, one could have two textures (e.g. with the same size and the same number of bytes per texel), each backed by a pixel buffer object and then we could copy the PBOs into each other? So it would be possible to access a 32-bit float single channel texture as a 4 channel 8 bit fixed point texture to gain access to the individual bytes?

  5. #65
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Germany
    Posts
    293

    Re: Official feedback on OpenGL 3.1 thread

    is there an ETA for the new glext.h and GL3/gl.h header files?

  6. #66
    Junior Member Newbie
    Join Date
    Aug 2008
    Posts
    1

    Re: Official feedback on OpenGL 3.1 thread

    Why exactly are geometry shaders expected to be depreciated soon?

  7. #67
    Super Moderator OpenGL Lord
    Join Date
    Dec 2003
    Location
    Grenoble - France
    Posts
    5,580

    Re: Official feedback on OpenGL 3.1 thread

    OpenCL ?

  8. #68
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,290

    Re: Official feedback on OpenGL 3.1 thread

    Quote Originally Posted by Chris Lux
    is there an ETA for the new glext.h and GL3/gl.h header files?
    Uhm, glext.h version 48 is up there for grabs in the repository. It's just not a clean slate.

  9. #69
    Junior Member Regular Contributor
    Join Date
    Jan 2004
    Location
    Czech Republic, EU
    Posts
    190

    Re: Official feedback on OpenGL 3.1 thread

    I'd like to see the direct state access in the next version, but the question is whether it is performance-wise. I was told that glBind* calls do a hash table lookup, which sort of defends the idea of bind-once-use-many-times.

    Concerning this ARB_compatibility extension, I don't think removing it will have a great impact on the stability of drivers since all important IHVs have implemented it anyway. What OpenGL really needs is extensive unit testing and official certification based on that by an independent authority. Everytime a new bug is found, a new test should be added to make sure the bug will never appear again in any implementation. Using OpenGL games and applications for driver testing is obviously not enough.
    (usually just hobbyist) OpenGL driver developer

  10. #70
    Junior Member Newbie RickA's Avatar
    Join Date
    Sep 2006
    Location
    NL
    Posts
    21

    Re: Official feedback on OpenGL 3.1 thread

    I think there's a small error in the glspec31.20090324.pdf document regarding the Uniform Buffer Objects. On page 50, near the bottom it says:

    Uniform buffer objects provide the storage for named uniform
    blocks, so the values of active uniforms in named uniform blocks may be changed
    by modifying the contents of the buffer object using commands such as Buffer-
    Data, BufferSubData, MapBuffer, and UnmapBuffer. Uniforms in a named
    uniform block are not assigned a location and may <u>be</u> be modified using the Uni-
    form* commands. The offsets and strides of all active uniforms belonging to
    named uniform blocks of a program object are invalidated and new ones assigned
    after each successful re-link.
    I imagine this is supposed to be
    Uniform buffer objects provide the storage for named uniform
    blocks, so the values of active uniforms in named uniform blocks may be changed
    by modifying the contents of the buffer object using commands such as Buffer-
    Data, BufferSubData, MapBuffer, and UnmapBuffer. Uniforms in a named
    uniform block are not assigned a location and may <u>NOT</u> be modified using the Uni-
    form* commands. The offsets and strides of all active uniforms belonging to
    named uniform blocks of a program object are invalidated and new ones assigned
    after each successful re-link.

Posting Permissions

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