Announcement

Collapse
No announcement yet.

Android Q's ANGLE Offering OpenGL ES On Top Of Vulkan 1.1

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

  • #11
    I think the ANGLE on Vulkan news is really good. I think a lot of vendors' OpenGL ES drivers could be easily bested by ANGLE on the Vulkan drivers packaged with them.

    Comment


    • #12
      Originally posted by dos1 View Post

      That's the point - ANGLE could support it. There's probably little point of doing that though performance-wise, as ES lacks certain GL parts for a reason.
      I think the point was that the hardware doesn't support features that desktop GL requires.

      The ARM gallium drivers in Mesa have just kind of ignored that - most of it can be emulated, and the handful of things that can't are extremely obscure and generally unused, so it doesn't really matter. But they aren't really 100% compliant, and that's probably more of a problem for someone like Google or a manufacturer than it is for an unofficial OSS driver.

      Angle could also just add CPU emulation of such things, I suppose, but at that point you need to ask yourself why you are really adding that at all to a low-powered device that doesn't support the API in hardware.

      Comment


      • #13
        Originally posted by karolherbst View Post

        you only need a stable device driver interface if you want to go through the trouble and support closed source drivers or drivers not being upstream. And in those cases you are already in a world full of pain and the stable driver interfaces just makes it easier for vendors to do nothing.
        Except nearly every Android device ships with closed-source blobs and drivers getting upstream (if they do) takes months if not years. Every Android device has to ship with both a forked version of Linux, and a forked version of Android, it's insane.

        So in the case of Android, a system where a Driver API does exist allows Google to ship one image per architecture including the kernel, as the necessary code to support the devices unique hardware exists outside of it running as a userspace driver. If you read the Fuschia DDK docs, it's pretty much an attempt to solve the Android update problem.

        Comment


        • #14
          Originally posted by skeevy420 View Post
          Now if only they could figure out a way to push system updates to everyone so we don't have to depend on manufacturers and carriers.
          Project Treble

          Comment


          • #15
            Originally posted by karolherbst View Post
            you only need a stable device driver interface if you want to go through the trouble and support closed source drivers or drivers not being upstream.
            Yes that's exactly the point for Fuchsia.

            And in those cases you are already in a world full of pain
            That's not an issue for microkernels, like Fuchsia.

            and the stable driver interfaces just makes it easier for vendors to do nothing.
            they don't do anything regardless. Consumer embedded devices are never updated.

            Comment


            • #16
              If Zink gets finished, we could have full fledged OpenGL on these devices.

              ​​​​It would also be interesting if Zink and MoltenVK could be used to bring OpenGL games to Mac OSX with minimal effort.

              Comment


              • #17
                Originally posted by Britoid View Post

                Except nearly every Android device ships with closed-source blobs and drivers getting upstream (if they do) takes months if not years. Every Android device has to ship with both a forked version of Linux, and a forked version of Android, it's insane.

                So in the case of Android, a system where a Driver API does exist allows Google to ship one image per architecture including the kernel, as the necessary code to support the devices unique hardware exists outside of it running as a userspace driver. If you read the Fuschia DDK docs, it's pretty much an attempt to solve the Android update problem.
                then you never get any driver updates anymore, because obviously if vendors _would_ care, they _would_ already update their driver, but obviously they don't, so with a stable ABI/API you just get crappy drivers shipped with a newer kernel, having to support legacy APIs, because drivers won't get updated.

                So you get windows all over again. and the Windows NT kernel has all kinds of crap inside their API which they can't remove, because driver X is still using it, although the API is just wrong and broken.

                Comment

                Working...
                X