Announcement

Collapse
No announcement yet.

Wine Developers Determining How To Handle Vulkan Loader Support

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

  • Wine Developers Determining How To Handle Vulkan Loader Support

    Phoronix: Wine Developers Determining How To Handle Vulkan Loader Support

    While this week's Wine 3.4 release delivers on working Wine Vulkan ICD support for beginning to allow Windows Vulkan programs to work under Wine assuming the host has Vulkan API support, this current implementation still requires the user to install the Windows Vulkan SDK...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    library that would be rather basic like skip out on supporting Vulkan layers or handling multiple ICD drivers.
    I can understand layers but not handling multiple ICD drivers with the ubiquity of multiGPU systems is not good enough.
    They should at least support multiple ICD drivers.

    Maybe layers are useful to support too. They could help with debugging, always a good thing for wine when software crashes and other failures can be easier to debug.

    Comment


    • #3
      Originally posted by plonoma View Post
      I can understand layers but not handling multiple ICD drivers with the ubiquity of multiGPU systems is not good enough.
      Literally none of that is relevant for a loader inside wine. Wine has one ICD (winevulkan), so why would a loader need to support this?

      Layers might be required to get stuff like the steam overlay to work, debugging layers could just be forwarded to the Linux loader (although that would be rather hacky).

      Ideally, they would just be able to use the default Windows loader, but yeah, licensing issues.

      Comment


      • #4
        Originally posted by VikingGe View Post
        Literally none of that is relevant for a loader inside wine. Wine has one ICD (winevulkan), so why would a loader need to support this.
        Not quite as straight forwards as one would think. A system with 2 video card may see the need for winevulkan ICD to be loaded twice. So plonoma issue is right.

        The licensing issue is a complex one. Remember the upstream in this case has already swapped from BSD to apache so even if wine does change from LGPL 2.0+ to LGPL 3.0+ will they change again and we be back in this same problem.

        I am very inclined to suggest a 4 option have winetricks install it for now and review this in 12 months time to see if the upstream has truly stabilised on a license then possible have debate about if it install like mono and gecko or if wine changes license..

        Comment


        • #5
          Ask Khronos to release a special loader specifically for wine under a compatible license. It's not like Khronos is an enemy that has to be worked around. I'm sure they're all for the best possible Vulkan support in wine.

          Comment


          • #6
            If I'm going for the simple vulkan-1 approach with 1 ICD, there are no issues at all. We only have 1 ICD in wine (winevulkan.dll.so), which can handle multiple devices from multiple vendors. There is no issue. To be exact the Wine ICD sits on top of the native vulkan.so.1. The native vulkan.so.1 is responsible for managing multiple devices and will automatically work for winevulkan.

            Comment


            • #7
              Fork the older BSD licensed release.

              Comment


              • #8
                Originally posted by Etherman View Post
                Fork the older BSD licensed release.
                There is another issue in here. http://en.swpat.org/wiki/Patent_clau...tware_licences

                BSD does not give you patent license coverage. LGPL version 2.1 by court cases does have a patent license protection but as strong apache 2.0 or lgpl 3.0.

                We are dealing with video card makers they have huge pools of patents. So the idea of fork the old BSD branch could be a death trap without understanding exactly what the problem is.

                There are reasons why projects are under particular licenses it does protect against particular problems.

                Comment


                • #9
                  Originally posted by oiaohm View Post

                  There is another issue in here. http://en.swpat.org/wiki/Patent_clau...tware_licences

                  BSD does not give you patent license coverage. LGPL version 2.1 by court cases does have a patent license protection but as strong apache 2.0 or lgpl 3.0.

                  We are dealing with video card makers they have huge pools of patents. So the idea of fork the old BSD branch could be a death trap without understanding exactly what the problem is.

                  There are reasons why projects are under particular licenses it does protect against particular problems.
                  Yes, this is exactly why someone high-up from Wine should ask Khronos for reasoning directly. It *might* be possible also to craft the license to special-case Wine if useful. Not enough information available though currently publicly to have informed recommendations

                  Comment


                  • #10
                    Note also that Apache is plenty open enough that distros could ship this official loader anyhow and offer something like update-alternatives for taking it into use manually

                    Comment

                    Working...
                    X