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

  • karolherbst
    replied
    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.

    Leave a comment:


  • chinoto
    replied
    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.

    Leave a comment:


  • starshipeleven
    replied
    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.

    Leave a comment:


  • starshipeleven
    replied
    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

    Leave a comment:


  • Britoid
    replied
    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.

    Leave a comment:


  • smitty3268
    replied
    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.

    Leave a comment:


  • microcode
    replied
    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.

    Leave a comment:


  • You-
    replied
    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. Android isn't so free and open when you factor in having to buy OS updates every two years due to firmware blobs not being updated and/or the OS not having an if/then compat layer regarding drivers and blobs.
    It is in the beta release announcement, called Project Mainline.

    It will distribute udates for "modules" via Play Store updates.

    Leave a comment:


  • karolherbst
    replied
    Originally posted by Britoid View Post

    That's called Fuschia.

    It has a stable device driver interface.
    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.

    Leave a comment:


  • dos1
    replied
    Originally posted by LinAGKar View Post

    I'm pretty sure most phones don't support full OpenGL anyway.
    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.

    Leave a comment:

Working...
X