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 6 of 7 FirstFirst ... 4567 LastLast
Results 51 to 60 of 65

Thread: OpenGL 3.2 support in new nVidia linux beta driver

  1. #51
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: OpenGL 3.2 support in new nVidia linux beta dr

    "At no time do NVIDIA or ATI want anyone to use beta drivers"

    Oh really ? Just yesterday nVidia gave me a beta-driver for my notebook through the general user download-site. I checked no "include beta drivers" box.

    It works fine, though.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

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

    Re: OpenGL 3.2 support in new nVidia linux beta dr

    Quote Originally Posted by Jan
    "At no time do NVIDIA or ATI want anyone to use beta drivers"

    Oh really ? Just yesterday nVidia gave me a beta-driver for my notebook through the general user download-site. I checked no "include beta drivers" box.

    It works fine, though.

    Jan.
    True. nVidia uses public beta's (they probably also have non-public beta drivers, but I don't know about them). AMD uses non-public beta drivers.

    New features in nVidia's beta drivers are also announced (like when OpenGL 3.1 and OpenCL entered the nvidia drivers). It is only because OpenGL 3.2 is not officially announced that there is no documentation for it yet.

  3. #53
    Senior Member OpenGL Pro
    Join Date
    Sep 2004
    Location
    Prombaatu
    Posts
    1,386

    Re: OpenGL 3.2 support in new nVidia linux beta dr

    Quote Originally Posted by glfreak
    No stable GLSL spec...
    Just to follow up... if you notice errors or omissions in the specs you can file a bug report with a Khronos bugzilla account (even the likes of yours truly has one).

  4. #54
    Administrator Regular Contributor
    Join Date
    Aug 2001
    Location
    NVIDIA, Fort Collins, CO, USA
    Posts
    184

    Re: OpenGL 3.2 support in new nVidia linux beta dr

    Quote Originally Posted by bertgp
    Quote Originally Posted by efikkan
    Why isn't it a good idea to release a draft of the new spesification? The driver and the upcoming OpenGL spesification will be more thoroughly tested, and developers will have a chance to send their feedback.
    Indeed! Test early and test often! Less chance of doing something that your customer doesn't want that way too.
    That is an excellent question. I'll answer separately for the specification and drivers.

    The OpenGL ARB is part of Khronos, as you know. Khronos has a set of intellectual property (IP) rules aimed at protecting any member who contributes ideas to the specification and any member who uses the final specification to implement OpenGL. Part of the process of releasing specifications outside of Khronos is a 30 day "ratification period". In those 30 days, all Khronos member companies are supposed to look for any IP that they own that has made it into the specification. After those 30 days, the Khronos board of Promoters votes to ratify and publish the specificiation. If a member company does not say anything during the ratification period, then they have automatically essentially licensed their IP for free to anyone who uses the specification to implement OpenGL. This is called a "reciprocal license". If a member company does not want to license their IP, then the rules spell out clearly what they need to do to keep their IP protected.

    The exact wording, in all its nitty gritty details, you can find here, if interested: http://www.khronos.org/files/member_agreement.pdf

    What this basically means is that no document that the ARB works on, be it an update of the core specification, the Shading Language, or any ARB extension, can be shown to anyone outside of Khronos, until the 30 day ratification period has passed. As I said before, this process is there to protect everyone involved with Khronos. Without this process, Khronos would not be able to function. There are over 100, some small and some very big, companies part of Khronos. They all have IP portfolios, and they value those highly. There has to be a set of rules governing IP involved with the work that Khronos does.

    In the balance, I think the Khronos process works really well. The old OpenGL ARB (before joining Khronos) did not have a good IP framework, and as a result anytime someone even hinted at a patent, the affected feature was put on hold, and not talked about again.

    Feedback from others does make it into the specification, however. Your constructive input on these forums is very valuable. Many ARB members read it. One example of such input is the thread "Talk about your applications" http://www.opengl.org/discussion_boa...133#Post246133 Keep it coming!

    Other ways that input makes it into the specification is through vendor extensions. Those are often written and implemented by a vendor(s) because there is a real developer need. The important and succesfull extensions make it into the core specification eventually. Maybe not the next release, but it can be the release after that.

    Ok, lets talk about drivers. Drivers are released often. Bugs are found, sadly enough. If you file a bug with the driver vendor, or mention it on this forum, there's a good chance it'll be acted upon and fixed in the next driver release. AMD, S3 Graphics and NVIDIA all have provided OpenGL 3 (beta) drivers soon after the specification was released. Thus you, as a developer, do get access to drivers to test out quickly.

    Hope this helps!

    Regards,
    Barthold
    OpenGL ARB WG Chair

  5. #55
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: OpenGL 3.2 support in new nVidia linux beta dr

    Quote Originally Posted by Stephen A
    I would surprised if anisotropic filtering doesn't make it to core in 3.2. This extension has been supported by everyone for over a decade and it's too damn useful.
    If it is supported by everyone, the only benefit to moving it into core would be tidiness, really. There is a stronger value to move something into core when some subset of the vendors are dragging heels on supporting a feature that everyone has in their silicon already (or in the other API) - in those cases it creates pressure for the vendor to add support for it so that they can claim compliance with the latest specification. This isn't the case with aniso filtering.

    i.e. - if it's supported everywhere, then use it and be happy

    There is a corpo-political reason why it hasn't been put in the core specification, it is certainly a topic that has come up more than a few times in working group discussions. It wasn't simply forgotten or overlooked, there was a roadblock to making that change.

  6. #56
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: OpenGL 3.2 support in new nVidia linux beta dr

    Understandable. But maybe, for the sake of tidyness ;-) it could at least be given ARB status some time.

    Anyway, i still think the LP object model is the most important API feature, that needs to be introduced soon. Immutable state-objects and all that stuff would be extremely helpful in reducing buggy code (from both sides, driver writers and application programmers) and ensuring best performance practices.

    Also all shader interfacing is a nightmare in more complex applications (ie. bind vertex arrays, uploading uniforms). VAOs are from the idea a solution to the current mess, but only performance wise (on paper). For fast switches, you need hundreds of VAOs, and so far i have found no one who says, that he could detect a speed up.

    Jan.
    GLIM - Immediate Mode Emulation for GL3

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

    Re: OpenGL 3.2 support in new nVidia linux beta dr

    Quote Originally Posted by Rob Barris
    Quote Originally Posted by Stephen A
    I would surprised if anisotropic filtering doesn't make it to core in 3.2. This extension has been supported by everyone for over a decade and it's too damn useful.
    If it is supported by everyone, the only benefit to moving it into core would be tidiness, really. There is a stronger value to move something into core when some subset of the vendors are dragging heels on supporting a feature that everyone has in their silicon already (or in the other API) - in those cases it creates pressure for the vendor to add support for it so that they can claim compliance with the latest specification. This isn't the case with aniso filtering.

    i.e. - if it's supported everywhere, then use it and be happy

    There is a corpo-political reason why it hasn't been put in the core specification, it is certainly a topic that has come up more than a few times in working group discussions. It wasn't simply forgotten or overlooked, there was a roadblock to making that change.
    From that I read:
    - no anisotropic filtering in the core
    - as what we already figured would be probable: geometry shader will enter the core (AMD is dragging heels on implementing that one...)

  8. #58
    Member Regular Contributor
    Join Date
    Aug 2008
    Posts
    456

    Re: OpenGL 3.2 support in new nVidia linux beta dr

    Check out the extension registry, 3.2 specs are up!!

  9. #59
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Czech Republic
    Posts
    317

    Re: OpenGL 3.2 support in new nVidia linux beta dr

    Thanks God (read: ARB) for ARB_sync extension!

    /marek

  10. #60
    Junior Member Newbie
    Join Date
    Jul 2009
    Location
    Norway
    Posts
    5

    Re: OpenGL 3.2 support in new nVidia linux beta dr

    Great! OpenGL 3.2 and GLSL 1.50 is available, and GLSL 1.50 features geometry shaders.

Posting Permissions

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