Announcement

Collapse
No announcement yet.

Mesa Vulkan Branch Published For Intel Linux Support

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

  • #11


    What window-systems are supported?
    The driver already has window system integration (WSI) support for X11 with DRI3 and Wayland.
    No Mir support, very interesting

    Comment


    • #12
      Originally posted by lucas_ View Post
      Doesn't mean it won't be added. More like now API is out there, Canonical will implement Vulkan support in MIr for Autumn release.

      Comment


      • #13
        Originally posted by lucas_ View Post
        Doesn't MIR consume the same interface of wayland?

        Anyway, as the mesa post says, the intel team spent more or less two years for their driver development, so it was not so easy to do. Considering the radical change done by AMD for their entire linux stack, it is well explained (at least to me) why there were not ready for the first day.

        Comment


        • #14
          Originally posted by boffo View Post

          So what happened the LunarG driver?
          It's probably this one here:
          Tools to aid in Vulkan development. Contribute to LunarG/VulkanTools development by creating an account on GitHub.

          Maybe the only interesting thing about it anymore is
          This directory provides support for the Intel Haswell, Ivy Bridge and Sandy Bridge GPUs

          and intel's driver says The driver currently supports Sky Lake all the way back to Ivy Bridge.

          Comment


          • #15
            Originally posted by Pecisk View Post

            It was used as prototype/test bed for ideas to be fleshed out. That was it's goal. LunarG also used it to develop SDK, while this driver got rewritten from scratch under Intel supervision.

            clueless question here. is this of any use to other vendor OSS drivers? i can figure they would need to replace SPIR-V->NIR with SPIR-V->something_else, but what about the rest?

            still, 36k is amazingly small.

            Comment


            • #16
              Oh yay, more non-OpenGL crap forced under the "OpenGL library" codebase/release schedule. Tell me again why we limit entire drivers to the release schedule of just the OpenGL library part of it? We could just as easily code-share without doing it that way, so that's not the reason.

              Comment


              • #17
                Originally posted by lucas_ View Post

                intel is working with red hat and ubuntu devs and since mir vulkan is not ready yet who cares? only morons like you

                Comment


                • #18
                  Originally posted by justmy2cents View Post


                  clueless question here. is this of any use to other vendor OSS drivers? i can figure they would need to replace SPIR-V->NIR with SPIR-V->something_else, but what about the rest?

                  still, 36k is amazingly small.
                  The entire design point of Vulkan was to have as little superfluous code in the driver as possible. Superfluous = hardware agnostic, can be shared between drivers. So apart from the SPIR-V to NIR, ideally there should be nothing else to share (otherwise the Vulkan committee would have royally screwed up somewhere).

                  Originally posted by Daktyl198 View Post
                  Oh yay, more non-OpenGL crap forced under the "OpenGL library" codebase/release schedule. Tell me again why we limit entire drivers to the release schedule of just the OpenGL library part of it? We could just as easily code-share without doing it that way, so that's not the reason.
                  I mostly agree, although for Intel, they basically have an entire GPU compiler sitting inside their GL driver (thankfully there's been great effort to separate it out lately), so not sharing that with their Vulkan efforts would be kind of bad. I do wish they could keep that stuff externally though like AMD does with LLVM.

                  Comment


                  • #19
                    Originally posted by zanny View Post
                    And then you hear about how open the standard is and how cross platform it is going to be. Linux on the Nvidia and Intel side are looking to be just as good / bad as the Windows side, but then AMD drops the ball with no driver, and only promises a GCN 1.1+ driver... eventually.
                    How did AMD "drop the ball"? No one from AMD said there would be Linux support on launch day nor that it would be GCN 1.1+ only. Moreover, there are very few vk apps available today so it's not like there are a tons of apps just waiting for drivers, plus it's hard to write drivers without applications to test. In general all of the GPU vendors work pretty closely with the application ISVs so lack of a public driver on launch day for specific platform/hw combinations is not exactly the end of the world. Next, there are hw limitations on pre-GCN hw that make vk support sub-optimal. Obviously it could be done, but it doesn't provide much of an advantage over current APIs. Even if all the hw vendors produced drivers for all platforms for all hw that could potentially support vk on day one, it wouldn't magically make tons of vk apps appear instantly. There are still a lot of DX10/GL3 cards out there. Why do lots of ISVs target target GL4/DX11? By your logic, all apps should still target GL3/DX10 or even GL2/DX9. Finally, windows is still where most of the market is at least in the short term, so that's obviously where most of the focus is.

                    Comment


                    • #20
                      Originally posted by agd5f View Post

                      How did AMD "drop the ball"? No one from AMD said there would be Linux support on launch day nor that it would be GCN 1.1+ only. Moreover, there are very few vk apps available today so it's not like there are a tons of apps just waiting for drivers, plus it's hard to write drivers without applications to test. In general all of the GPU vendors work pretty closely with the application ISVs so lack of a public driver on launch day for specific platform/hw combinations is not exactly the end of the world. Next, there are hw limitations on pre-GCN hw that make vk support sub-optimal. Obviously it could be done, but it doesn't provide much of an advantage over current APIs. Even if all the hw vendors produced drivers for all platforms for all hw that could potentially support vk on day one, it wouldn't magically make tons of vk apps appear instantly. There are still a lot of DX10/GL3 cards out there. Why do lots of ISVs target target GL4/DX11? By your logic, all apps should still target GL3/DX10 or even GL2/DX9. Finally, windows is still where most of the market is at least in the short term, so that's obviously where most of the focus is.
                      I don't claim to know even a 10th of what you do, but this just preserves the status quo where AMD hardware doesn't get tested or supported on linux. That is bad news. Hardware support is really important.

                      Comment

                      Working...
                      X