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 161 of 173 FirstFirst ... 61111151159160161162163171 ... LastLast
Results 1,601 to 1,610 of 1724

Thread: OpenGL 3 Updates

  1. #1601
    Member Regular Contributor
    Join Date
    Nov 2003
    Location
    Czech Republic
    Posts
    317

    Re: OpenGL 3 Updates

    Quote Originally Posted by HAL-10K
    Quote Originally Posted by mfort
    Please calm down. I really understand CAD-like companies. Making new API with no backward compatibility would brake it all.
    No. Why do you think that?
    You could still use drivers written against the old API spec.
    I think that IHVs would continue driver support for quite some time even for future hardware.
    Why? It is simple. CAD like companies want to add few new OpenGL features to their renderer once a while without rewriting it all from scratch. Imagine they freeze OpenGL 2.x and offer new features only in OpenGL 3.0. Then the new features will never appear the large older applications.

    Please also keep in mind that OpenGL is used for many non rasterizing graphical tasks, like GPGPU. (I am one of them as well). OpenGL is so wrong API for this but don't blame OpenGL for that. We have CUDA now, may OpenCL is coming. Raytracing rendering will probably replace all OpenGL/DX*. can you imagine OpenGL twisted for a ray tracing API?


    /Marek

  2. #1602
    Intern Newbie LogicalError's Avatar
    Join Date
    Sep 2004
    Location
    Rotterdam, the Netherlands, Europe
    Posts
    48

    Re: OpenGL 3 Updates

    Quote Originally Posted by Timothy Farrar
    GL3 is a better match for current hardware
    Oh really? which part of the gazillion different extensions?

    Quote Originally Posted by Timothy Farrar
    GL3 has much of DX10 level functionality.
    And DX10 had full DX10 level functionality since.. well.. when it was released several years back!

    Quote Originally Posted by Timothy Farrar
    Personally I could care less what the API looks like as long as it is fast, it supports the hardware features, and all vendors actually provide drivers.
    wait.. are you talking about DX10 now?
    because that certainly doesn't sound like opengl!

    Edit: yeah. sorry, i'm pissed off, please don't take it personally.

  3. #1603
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: OpenGL 3 Updates

    Quote Originally Posted by Timothy Farrar
    Personally I could care less what the API looks like as long as it is fast, it supports the hardware features, and all vendors actually provide drivers.
    Except you are already dropping speed as the hardware drifts away from the API (the D3D10 model, what GL3.0 looked like before this... thing... is closer) and reliable drivers are harder to write because the new features have to interact with the old.

    The fact of the matter is right now Intel's GL drivers suck and with more complication I don't expect this to improve. Even AMD's drivers have problems and a lack of features, which will delay their GL3.0 release as well and god knows how stable it will be.

    For OpenGL2.2 it would have been a nice release, for a GL3.0 it's just another GL2.0 sized blunder and compromise.

  4. #1604
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: OpenGL 3 Updates

    One feature of GL 3.0 is a mechanism for requesting a context where the deprecations are enforced - this was put in to give developers a way to run their apps in this mode early on.

    There is a lot of alignment between the feature set marked deprecated in GL 3.0 and the set of features that Long's Peak was slated to remove.

  5. #1605
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: OpenGL 3 Updates

    Quote Originally Posted by mfort
    Why? It is simple. CAD like companies want to add few new OpenGL features to their renderer once a while without rewriting it all from scratch. Imagine they freeze OpenGL 2.x and offer new features only in OpenGL 3.0. Then the new features will never appear the large older applications.
    And as I recall there was ALWAYS plans to allow a crossover of GL2.x and Longs Peak features via the same context for just this sort of thing so companies could migrate. I guess the plans weren't good enough.

  6. #1606
    Member Regular Contributor
    Join Date
    May 2002
    Posts
    269

    Re: OpenGL 3 Updates

    Quote Originally Posted by Rob Barris
    One feature of GL 3.0 is a mechanism for requesting a context where the deprecations are enforced - this was put in to give developers a way to run their apps in this mode early on.
    What are supposed short term/long term benefits of running GL app in the deprecated mode?

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

    Re: OpenGL 3 Updates

    Quote Originally Posted by Rob Barris
    There is a lot of alignment between the feature set marked deprecated in GL 3.0 and the set of features that Long's Peak was slated to remove.
    Great, where can I download a GL 3.0 pdf spec without all the deprecated features now ?
    Because currently it means "read the spec" - "skip to the end to check if this or that feature is deprecated" - "loop" and is very messy to read totally useless stuff.

  8. #1608
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: OpenGL 3 Updates

    As work is already underway for the next release, this is exactly the right time to bring up functionality that you want either as an OpenGL 3.0 extension or for the next core release.
    OK, if you want. I mean, I don't care about OpenGL anymore, and I'll be abandoning OpenGL in the future, but if you insist:

    GL "3.0" is not Longs Peak. It doesn't align with all (or even most) of the features of Longs Peak, even if you ignore the lack of the new object model. Here's a "short list" of features that Longs Peak promised that GL "3.0" doesn't deliver:

    - Getting rid of GL_FRAMEBUFFER UNSUPPORTED. That is, providing a mechanism that makes this impossible, that allows a user to know beforehand whether a particular combination of images and state is allowed by the implementation. Without this, FBO still has the same problems it always did.

    - Instancing programs. GL "3.0" program objects are still bound directly to their data. It is often the case that you want to use the same code, but with completely different sets of data. This requires constantly respecifying uniforms and attributes every time you want to use it. This is not conducive to performance. Longs Peak had "Program Environment Objects" which stored the state for a program. This also had the benefit of preventing stupid implementations (I'm looking at you, nVidia) from recompiling your program just because you changed a uniform.

    - The ability to "mix&match" programs of different types. That is, the ability to use a vertex program that you did a full compile/link on and a fragment program that you did a full compile/link on that were not explicitly linked together. GL "3.0" still uses the 2.x model.

    - Image Formats. These were supposed to be the way that you could ensure that images of a specific format could be created and used as you wanted. If you wanted to create a floating-point texture that required bilinear filtering, you needed an image format first. And if the image format creation failed, then you know you couldn't do it because the implementation didn't support it. GL "3.0" doesn't have this.

    - Decoupling of Image from TexParameter. Longs Peak had "Texture Filter" objects that represented TexParameter stuff. Much like the program instance Program Environment object, this allowed a decoupling of data (Image, Program) from its use (TexParameter, uniforms and attributes).

    - Forced "Hints". Buffer objects in particular were supposed to get hints that weren't actually hints; they were forced. Attempting to do certain operations with buffer objects that were set up incorrectly would produce non-functional code. GL "3.0" still has you able to map from any kind of buffer object and other nonsense.

    - The ability to use it on 2.x hardware (Radeon 9700+/GeForceFX+). That was an explicit feature of Longs Peak: it could all be used on older DX9-compatible hardware. GL "3.0" requires DX10-class hardware, even though it doesn't even provide access to the main DX10 features (geometry shaders, uniform buffers, etc).

    These were not minor features of LP; they were vital. They characterized what LP was: a way to do graphics while taking out the guesswork and needless weirdness. No "deprecated context" nonsense will bring these features back. And they weren't bound to the new object model; they were features that were introduced because API cleanup was happening.

  9. #1609
    Junior Member Newbie
    Join Date
    Mar 2004
    Posts
    22

    Re: OpenGL 3 Updates

    Quote Originally Posted by mfort
    Why? It is simple. CAD like companies want to add few new OpenGL features to their renderer once a while without rewriting it all from scratch. Imagine they freeze OpenGL 2.x and offer new features only in OpenGL 3.0. Then the new features will never appear the large older applications.
    That some decade old CAD application won't be able to use state of the art tesselation programs or whatever without rewriting the API interface at some point, is no rational reason to keep backwards compatibility on an API that is now going to be SEVEN years behind it's competitor in a very fast-pased market.

    This is reason enough for us to abandon the 7% of our costumers on the MacOS platform.

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

    Re: OpenGL 3 Updates

    I think some of us need to read the new specifications again. I think there's more to this deprecation model than first meets the eye ;-)

    On point, I don't see what's preventing a new object model - or new anything else for that matter - from being introduced and deprecating the relevant parts as needed. If the driver only has to support the context version requested, it's pretty much all gravy.

Posting Permissions

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