Announcement

Collapse
No announcement yet.

The Many Problems With OpenGL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    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.

    Comment


    • #42
      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+.

      Comment


      • #43
        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...

        Comment


        • #44
          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...

          Comment


          • #45
            I'm curiously waiting for my first game to use both my integrated Intel Graphics together simultaneously with my GTX770 via Vulkan.

            Comment


            • #46
              Originally posted by mike4 View Post
              I'm curiously waiting for my first game to use both my integrated Intel Graphics together simultaneously with my GTX770 via Vulkan.
              A game you build or a game you buy?

              Comment

              Working...
              X