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 17 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 166

Thread: Official feedback on OpenGL 3.1 thread

  1. #21
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    352

    Re: Official feedback on OpenGL 3.1 thread

    Can we please have an update for the man sources?

    They were made public a few months ago and we are using them to generate inline documentation for the .Net bindings. Unfortunately the public repository seems stuck with OpenGL 2.1.

    Edit: Also gl.spec doesn't seem to list any "version 3.1" functions, even though "3.1" has been added to the version string. Any timeframe for the update (so we can plan our release accordingly)?
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  2. #22
    Intern Contributor spasi's Avatar
    Join Date
    Feb 2004
    Location
    Greece
    Posts
    67

    Re: Official feedback on OpenGL 3.1 thread

    Great job Khronos!

    I would just like to add that the EXT_copy_buffer extension is missing from the OpenGL registry. I wasn't able to find token values for COPY_READ_BUFFER and COPY_WRITE_BUFFER in the updated header files either (used in the new CopyBufferSubData).
    spasi
    zDimensions

  3. #23
    Advanced Member Frequent Contributor
    Join Date
    Apr 2003
    Posts
    661

    Re: Official feedback on OpenGL 3.1 thread

    I'm horrifed about ARB_compatibility.

    Will that pre-GL3.0 zombie survive forever?

    It means: even though I request a 'pure' GL3.1 context, all the old cruft will be still in the driver!? There won't be any of the performance benefits that a lean-and-mean 3.1 driver promises.
    ARB_compatibility undermines the positive effects the deprecation model should have brought. I demand a possibility to turn it off some way (maybe via a new flag in wglCreateContextAttribsARB). I think, the ones who really need GL_SELECTION (and all that other old suff) in a GL3.1 environment should be forced to deliberately activate it - and then pay for it.

    Why not divert the driver development at this point? Why not provide a GL3.0+extensions and separate GL3.1+new_extensions driver?
    You want developers to take the pain and rewrite their engines for GL3.x? Fine, then reward them with better performance!


    Another thing I'm missing is a proper glPushAttrib/glPopAttrib replacement. The push/pop mechanism made it easy to isolate independend rendering code. There should be some new and efficient way to set/change/restore state in GL3.x without having to do multiple calls to glGetXXX().

  4. #24
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,126

    Re: Official feedback on OpenGL 3.1 thread

    Many thanks to Khronos/ARB and NVidia for their great work on OpenGL 3.1 design and drivers. Impressive comeback after 3.0! Whatever you're doing different now, please stick with it!

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

    Re: Official feedback on OpenGL 3.1 thread

    Quote Originally Posted by spasi
    I would just like to add that the EXT_copy_buffer extension is missing from the OpenGL registry. I wasn't able to find token values for COPY_READ_BUFFER and COPY_WRITE_BUFFER in the updated header files either (used in the new CopyBufferSubData).
    +1 for updated headers.

  6. #26
    Member Regular Contributor
    Join Date
    Mar 2001
    Posts
    468

    Re: Official feedback on OpenGL 3.1 thread

    Btw, are there any plans to have an RSS feed for the registry?

    I tried building one with an external website, but it was all screwbally.

  7. #27
    Junior Member Regular Contributor
    Join Date
    Jun 2000
    Location
    Cambridge, England
    Posts
    190

    Re: Official feedback on OpenGL 3.1 thread

    ARB_compatibility is absolutely necessary, and yes, on NVidia hardware at least, the pre-GL3 zombie will survive a long time. Other vendors don't have to support ARB_compatibility so they're not being held back. A lot of time and money has been invested in writing pre-GL3 code, expecting that will be thrown away just to use uniform buffers is unreasonable.
    Backwards compatibility is one of the main wins for GL vs D3D, throwing away that advantage is a definite no-no.

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

    Re: Official feedback on OpenGL 3.1 thread

    <GL3/gl3.h> : good idea, especially to prevent using the deprecated stuff, but why not <GL/gl3.h> ?
    And where/when can it be downloaded ?

  9. #29

    Re: Official feedback on OpenGL 3.1 thread

    Seeing how much of an improvement the Experimental C++ Bindings for OpenCL are compared to the C bindings. http://www.khronos.org/registry/cl/ (You need to be way less verbose).

    It would be awesome if we had something like those for OpenGL3.

  10. #30
    Intern Contributor
    Join Date
    Feb 2005
    Posts
    90

    Re: Official feedback on OpenGL 3.1 thread

    I'm horrifed about ARB_compatibility.
    I'm must second this.
    We develop medical device that heavily relies on OpenGL: volume rendering(ray casting/Slices), huge meshes, numerous points and lines. We have been refactoring the code to remove some deprecated stuff in anticipation for the next release, but all for vain(maybe not: it will help in the transition to DX), although we use Quadro FX4600(and above, cost many many $$$) the drivers are so shitty that you never know where is the problem.
    We switched recently to a new driver/card and boom the application loses texturing or get stuck, replacing for an older card works, restore old driver works.
    We need working OpenGL, I don't mind loosing selection/wide lines/push-pop/Fixed pipeline etc for a working implementation.
    I must be honest for months others are pushing DirectX and I tell them no, no, GL3+ will be great!!!.
    Well it doesn't seems so. I want two separate implementation: one for pre-gl3 and one for post gl-3. In OpenGL 3.1+ I don't want any old stuff and I want drivers to be rock solid.
    I'm staring to think Korval was right from the start, OpenGL is gone.
    If something dramatically does not happens soon everyone will switch to DirectX: CAD/Medical and Military. Even CAD users need solid drivers(see AutoCAD).

    Ido

Posting Permissions

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