Announcement

Collapse
No announcement yet.

63 Mesa Patches For Wiring Up One OpenGL 4.3 Extension

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

  • #11
    Originally posted by GreatEmerald View Post

    Haah, I just read this sentence as-is, and it's hilarious. Joking rights, and Intel paying to add zanny's complaining to core Mesa!

    We appreciate your work on Mesa, but do try to work on proper grammar too

    Can you avoid the taunting and ad-hominem? I find that pretty disgraceful.

    Comment


    • #12
      Originally posted by zanny View Post

      Contracted to do work that does not well benefit the Gallium drivers because Intel insists on having their own entirely separate driver stack independent of what everyone else is using. You can simultaneously thank Intel for releasing free software patches for Mesa and simultaneously criticize them for continuing to keep their driver independent of the established ecosystem in Gallium that every other driver is using, thus creating more work for developers to port their work to its architecture.

      Its their choice not to invest the time and money necessary to make the i915g as capable as i915. But I can still be critical of that choice for the long term consequences that decision has on development of free graphics implementations.

      I don't think the stacks are as separate as you think. And either way, once it's in one, there's code which can be freely copied and adjusted in the other stack when it is truly separate.

      How is it that Intel doing their job is never enough, they have to do other people's jobs as well?

      Comment


      • #13
        Originally posted by microcode View Post


        Can you avoid the taunting and ad-hominem? I find that pretty disgraceful.
        That looked more like a light-humored joke to me. Or which part of that was a taunt, or ad hominem?

        Comment


        • #14
          Originally posted by microcode View Post


          I don't think the stacks are as separate as you think. And either way, once it's in one, there's code which can be freely copied and adjusted in the other stack when it is truly separate.

          How is it that Intel doing their job is never enough, they have to do other people's jobs as well?
          Of course they are not completely separate - we have one common generator of Mesa IR in Mesa's ligbgl, that is then consumed by either Intel's driver stack or the Gallium Mesa state tracker. Work Intel does in Mesa core benefits Gallium by generating the internal IR to be then converted to TGSI in Gallium, but the Intel DRI driver is independent and doesn't code share with the rest of the driver ecosystem like Gallium does.

          But for something like compute shaders that were published last month, a huge portion of that work is in exposing the programmable shader pipeline on the GPU to export shaders to. That work can largely be shared in Gallium TGSI, but cannot be shared in Mesa IR (such as NIR) pretty much at all, because they are operating on two different levels of abstraction. That is why it is going to take a long time to see compute shaders on Gallium drivers, because all the work Intel has done in their DRI driver to support them is lost on Gallium, where you get to cheat some of the per-vendor specialty parts with code sharing and a common IR.

          Comment


          • #15
            Originally posted by zanny View Post

            Contracted to do work that does not well benefit the Gallium drivers because Intel insists on having their own entirely separate driver stack independent of what everyone else is using. You can simultaneously thank Intel for releasing free software patches for Mesa and simultaneously criticize them for continuing to keep their driver independent of the established ecosystem in Gallium that every other driver is using, thus creating more work for developers to port their work to its architecture.

            Its their choice not to invest the time and money necessary to make the i915g as capable as i915. But I can still be critical of that choice for the long term consequences that decision has on development of free graphics implementations.
            All of those patches add support needed by Gallium as well, there is nothing Intel specific in the first 59 patch as far as I can see.

            Originally posted by zanny View Post
            Of course they are not completely separate - we have one common generator of Mesa IR in Mesa's ligbgl, that is then consumed by either Intel's driver stack or the Gallium Mesa state tracker. Work Intel does in Mesa core benefits Gallium by generating the internal IR to be then converted to TGSI in Gallium, but the Intel DRI driver is independent and doesn't code share with the rest of the driver ecosystem like Gallium does.

            But for something like compute shaders that were published last month, a huge portion of that work is in exposing the programmable shader pipeline on the GPU to export shaders to. That work can largely be shared in Gallium TGSI, but cannot be shared in Mesa IR (such as NIR) pretty much at all, because they are operating on two different levels of abstraction. That is why it is going to take a long time to see compute shaders on Gallium drivers, because all the work Intel has done in their DRI driver to support them is lost on Gallium, where you get to cheat some of the per-vendor specialty parts with code sharing and a common IR.
            You are very mistaken on the inner working of Mesa. For starters this support has nothing to do with any IR because this is not a shader language extension. Mesa IR is used by Gallium also, and NIR has a NIR to TGSI conversion layer and is being used to optimise shader code for the raspberry pi and freedreno drivers.

            Comment


            • #16
              Originally posted by tarceri View Post

              You are very mistaken on the inner working of Mesa. For starters this support has nothing to do with any IR because this is not a shader language extension. Mesa IR is used by Gallium also, and NIR has a NIR to TGSI conversion layer and is being used to optimise shader code for the raspberry pi and freedreno drivers.
              This is exactly my point - since none of this work is shader generated functionality little of this work benefits Gallium. The work Intel does do in core Mesa that generates IR is valuable to all involved projects, including NIR when consumed by Gallium drivers. When work like this only benefits the Intel DRI driver and the associated hooks in Mesa to advertise it, it means Gallium must also implement this functionality entirely independently.

              Which is my whole point in why I'm critical of Intel continuing to use their own DRI stack. Many projects predated standards that arose in their domains that were then adopted instead - probably most recently is AMD's release and subsequent abandonment of Mantle in favor of Vulkan. Other examples closer to the problem domain include Upstart vs Systemd, or SELinux vs Tomoyo vs Apparmor vs PAX - or even Mir vs Wayland vs X. In the case of init systems, Upstart predated systemd which has been adopted due to consensus everywhere, including by Canonical and RHEL. It took work on the part of every service implementer, of packagers everywhere, to make the switch, but we broadly know as a community shared infrastructure trumps fragmentation. In the middle, we have MAC implementations which still remain divisive and the lack of commonality or interoperability costs us adoption because they are all still PITA and fragmented messes. In the later case, the tables are turned and Canonical started Mir after Wayland and was derived for breaking from the established common core, which is now being implemented in Mutter and Kwin.

              Intel DRI came first, which gave them leeway compared to criticisms of Canonical for making their own display server. But that does not absolve them of criticism for the same reason you criticize Canonical for continuing to push Mir instead of Wayland - if we were working together, Wayland would be much better today than Canonical NIHing everything on their own implementation. In the same way, Gallium would be much further ahead if Intel were not investing dozens of developers into a DRI driver that only improves their GPUs.

              Comment


              • #17
                Originally posted by zanny View Post

                Contracted to do work that does not well benefit the Gallium drivers because Intel insists on having their own entirely separate driver stack independent of what everyone else is using. You can simultaneously thank Intel for releasing free software patches for Mesa and simultaneously criticize them for continuing to keep their driver independent of the established ecosystem in Gallium that every other driver is using, thus creating more work for developers to port their work to its architecture.

                Its their choice not to invest the time and money necessary to make the i915g as capable as i915. But I can still be critical of that choice for the long term consequences that decision has on development of free graphics implementations.
                I'm not saying you can say as you please you realize their i965 driver predates the gallium push? Yes, more code has probabl been pushed into 965 since than probably existed at the time, but this was an uncertain project.
                Also, there's their concern about inherent inefficiencies in gallium, which all devs acknowledge, and it wasn't as though Intel igpus were such powerhouses that they could afford to just give up 3% (or whatever the number maybe).
                Lastly, I firmly believe that the Intel management, at the time this decision was made, didn't want to help the competition anymore than they had to.

                Comment


                • #18
                  Originally posted by zanny View Post

                  Gotta love two independent driver stacks in Mesa... Intel, and everyone else.
                  As Timothy has pointed out, this benefits everybody, not just Intel. Looking at the diff below, the vast majority of this patch isn't Intel specific. I imagine all the non i965 stuff benefits core Mesa, making it (I assume) relatively easy for the other drivers to add the required plumbing to take advantage of it.

                  Code:
                  src/mapi/glapi/gen/ARB_internalformat_query2.xml | 119 ++
                   src/mapi/glapi/gen/gl_API.xml                    |    2 +-
                   src/mesa/drivers/common/driverfuncs.c            |    2 +-
                   src/mesa/drivers/dri/i965/Makefile.sources       |    1 +
                   src/mesa/drivers/dri/i965/brw_context.c          |   40 +-
                   src/mesa/drivers/dri/i965/brw_context.h          |    5 +
                   src/mesa/drivers/dri/i965/brw_formatquery.c      |  131 ++
                   src/mesa/drivers/dri/i965/intel_extensions.c     |    1 +
                   src/mesa/main/dd.h                               |   26 +-
                   src/mesa/main/extensions_table.h                 |    1 +
                   src/mesa/main/formatquery.c                      | 1521 ++++++++++++++++++++--
                   src/mesa/main/formatquery.h                      |    9 +
                   src/mesa/main/formats.c                          |    6 +
                   src/mesa/main/genmipmap.c                        |   50 +-
                   src/mesa/main/genmipmap.h                        |    6 +
                   src/mesa/main/glformats.c                        |   12 +
                   src/mesa/main/mtypes.h                           |    1 +
                   src/mesa/main/multisample.c                      |   10 +-
                   src/mesa/main/shaderimage.c                      |   58 +-
                   src/mesa/main/shaderimage.h                      |   14 +
                   src/mesa/main/tests/dispatch_sanity.cpp          |    4 +
                   src/mesa/main/teximage.c                         |   44 +-
                   src/mesa/main/teximage.h                         |   14 +-
                   src/mesa/main/texparam.c                         |   40 +-
                   src/mesa/main/texparam.h                         |    7 +
                   src/mesa/main/texstorage.c                       |    8 +-
                   src/mesa/main/textureview.c                      |   12 +-
                   src/mesa/main/textureview.h                      |    8 +
                   src/mesa/state_tracker/st_cb_texture.c           |    2 +-
                   src/mesa/state_tracker/st_format.c               |   38 +-
                   src/mesa/state_tracker/st_format.h               |    8 +-
                   31 files changed, 1961 insertions(+), 239 deletions(-)

                  Comment


                  • #19
                    Originally posted by zanny View Post

                    Contracted to do work that does not well benefit the Gallium drivers because Intel insists on having their own entirely separate driver stack independent of what everyone else is using. You can simultaneously thank Intel for releasing free software patches for Mesa and simultaneously criticize them for continuing to keep their driver independent of the established ecosystem in Gallium that every other driver is using, thus creating more work for developers to port their work to its architecture.

                    Its their choice not to invest the time and money necessary to make the i915g as capable as i915. But I can still be critical of that choice for the long term consequences that decision has on development of free graphics implementations.
                    No offense, but it's clear you didn't read these patches and are just venting on some unrelated topic.

                    These patches DO help gallium drivers. 99% of this is shared code that all the drivers will use. I think there was a grand total of 1 driver specific callback, and it currently does basically nothing on the Intel side.

                    There are times when I agree that it's very unfortunate the way things have been split, but this is emphatically not one of them.

                    Comment


                    • #20
                      @Timothy Any plans on wiring up arrays of arrays to the other drivers anytime in the future?

                      Comment

                      Working...
                      X