Page 5 of 5 FirstFirst ... 345
Results 41 to 44 of 44

Thread: The Many Problems With OpenGL

  1. #41
    Join Date
    Mar 2007
    Location
    West Australia
    Posts
    357

    Default

    Quote Originally Posted by Azpegath View Post
    Yes, I guess that's true. But that's beside the issue I stated in my post. The aspect of "A clean API" is not different at all, right?
    Well apparently nVidia support OpenGL ES with their desktop driver. I'm glad there is another option here now.

  2. #42
    Join Date
    Dec 2012
    Posts
    504

    Default

    Quote Originally Posted by b15hop View Post
    Well apparently nVidia support OpenGL ES with their desktop driver. I'm glad there is another option here now.
    They all do, it is a part of the OGL standard to support the same routines as GLES and provide it in the OGL driver. GLES 2 is supported by OGL 4.1+ and GLES 3 is 4.3+.

  3. #43
    Join Date
    Mar 2013
    Posts
    44

    Default

    Quote Originally Posted by berarma View Post
    Wrong, the compatibility problems aren't related to the hardware, it's about the compatibility with software that relies on the legacy features. That software might be 20 years old or maybe written last week.
    What exactly is the nature of the problem? For example:
    - is the issue an inability to have two drivers with the same name (or other such ID) on (some) systems? Can this not be fixed just by renaming the new API --- use the OpenGL SP (or whatever) driver with a different name and different name space...

    - is the issue that even the newest chips do a lousy job of segregating state, so that it's not possible to have two "masters" both submitting orders to the chip because they'll collide and both want to control some non-guarded resource?

    - is the issue sheer laziness? If the problem really IS software that's, say, more than 10 years old then, WTF, why can't you just route that old code to a purely software based renderer [it's not like it's going to demand leading edge performance] and then you can toss the legacy support not just from the driver but also from the HW.

    The details are interesting because of, as always, the existence of Apple which has a demonstrated impatience with legacy stupidity and a willingness to do something about it far beyond the Wintel and Linux (and now orthodox ARM) worlds. If, as seems likely, Apple are going to ship their own GPU soon, there seems scope for both performance (smaller faster chip without legacy crap) and, more importantly, agility (faster design and verification of both the HW and the OGL driver) if they're willing to draw a line in the sand regarding what they support: Everything earlier than, say, GLES 2.0 routes to SW emulation (and gets abandoned in a year, when the line moves to GLES 3.0, or whatever).

    Of course Apple's footling around with a better ARM GPU doesn't affect the Intel GPU world --- yet...

  4. #44
    Join Date
    Feb 2009
    Posts
    158

    Default

    Looks like everyone focused on just the number of API functions and forgot about the other dozens of points stated in Rich's blog.

    There is need for a new crossplatform API, not a revised OpenGL...

Posting Permissions

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