Announcement

Collapse
No announcement yet.

MESA_tile_raster_order Added To The OpenGL Registry

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

  • MESA_tile_raster_order Added To The OpenGL Registry

    Phoronix: MESA_tile_raster_order Added To The OpenGL Registry

    The new OpenGL extension MESA_tile_raster_order proposed by Eric Anholt at Broadcom has now been merged to the Khronos registry...

    http://www.phoronix.com/scan.php?pag...order-Register

  • #2
    Dang! You open up your hardware for a few months and suddenly people are innovating all over it!

    Comment


    • #3
      Originally posted by LaeMing View Post
      Dang! You open up your hardware for a few months and suddenly people are innovating all over it!
      I can imagine companies like MS and Nvidia totally misinterpreting that being like "I know right!? That sounds so awful!"

      Comment


      • #4
        Originally posted by LaeMing View Post
        Dang! You open up your hardware for a few months and suddenly people are innovating all over it!
        s/months/years

        Eric has been at it for a while now

        Comment


        • #5
          And is officially employed by Broadcom. But yes, good to hear! Although, I'm wondering why people are focusing so much on X11 - IMO just ditch that and work on Wayland support. Not that X11 shouldn't be supported at all, but improvements and new features should focus on Wayland powered desktops.

          Comment


          • #6
            Raspberry Pis will be run with uncomposited X11 for some more years, I guess. If it's that simple to improve its user experience, why shouldn't it be done?

            Comment


            • #7
              Who is working now on the etnaviv OpenGL / Vulkan implementation? It would be relevant for Librem 5.

              Comment


              • #8
                Originally posted by sandy8925 View Post
                And is officially employed by Broadcom. But yes, good to hear! Although, I'm wondering why people are focusing so much on X11 - IMO just ditch that and work on Wayland support. Not that X11 shouldn't be supported at all, but improvements and new features should focus on Wayland powered desktops.
                Because the acceleration stuff underneath both of them are identical.... it is literally the same code and libraries. Wayland is just intend to be a better way of talking to those libraries.

                Comment


                • #9
                  Originally posted by cb88 View Post

                  Because the acceleration stuff underneath both of them are identical.... it is literally the same code and libraries. Wayland is just intend to be a better way of talking to those libraries.
                  In many cases yes, although I don't think that really applies here. This is intended to help speed up Glamor, which is an X driver that only applies to, well, X. But the real key there is that it is intended to help out the uncomposited case, since compositors don't run into the same workload. And Wayland, by it's design, is always composited. So while it's not impossible that this someday might help something else, I think for the moment it's very clearly targeted at X users.

                  The reason should be pretty obvious though. He was trying to get the Mesa driver into an acceptable state to replace the proprietary default for Pi users, and Pi users currently tend to use X for the most part. Many of them use no compositor. In a few years when wayland is more present on that platform, it may not even be in much use anymore if there's a new VC5 platform, and regardless it wouldn't help all the users who'd like to use the OSS driver now and not wait or have to change their entire windowing system.

                  Comment

                  Working...
                  X