Announcement

Collapse
No announcement yet.

Happy Holidays: AMD Finally Pushing Out Open-Source Vulkan Driver

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

  • #41
    Originally posted by artivision View Post
    Depending how you see it. For example you have taken for granted that Amd engineers 'must' building it for Windows.
    Do you mean I am taking for granted that AMD drivers must be building the Windows driver source for Windows (Luke_Wolf was talking about Windows drivers) then yes. I don't think I understand what you are saying.
    Test signature

    Comment


    • #42
      Originally posted by Luke_Wolf View Post
      Well I mean, the thing is you're already opening up the bulk of your Vulkan code, and as soon as it finally drops they can have that zero effort access... if they're targeting Linux. I'm not saying "Open the whole catalyst driver" or anything like that, just open the windows side of the driver enough that game devs can improve and replace the vulkan implementation on their own machines, and send AMD their changes. I kinda doubt that there's much in the way of proprietary secret sauce in the code gluing Vulkan into the Windows driver. I'm sure there's plenty I don't know going into this but strategically it seems like all the valuable stuff related to Vulkan is already set to be opened, and putting proprietary hoops in the way of the Windows game devs may be the status quo but is pointlessly limiting potential development of the driver.
      Once you open up code for other OSes you also pick up code for other APIs which we can not expose publicly. Trying to make an open source Windows Vulkan-only driver would be another big refactoring effort. Remember the internal code supports more than just Vulkan.
      Test signature

      Comment


      • #43
        Originally posted by bridgman View Post

        Once you open up code for other OSes you also pick up code for other APIs which we can not expose publicly. Trying to make an open source Windows Vulkan-only driver would be another big refactoring effort. Remember the internal code supports more than just Vulkan.
        That's a fair point I suppose. Oh well, at least it'll have the possible side effect of drawing more game developers to targeting Linux in order to improve the Vulkan driver for their windows users, which'll have the benefit of giving us better Linux ports.

        Comment


        • #44
          Originally posted by bridgman View Post

          Once you open up code for other OSes you also pick up code for other APIs which we can not expose publicly. Trying to make an open source Windows Vulkan-only driver would be another big refactoring effort. Remember the internal code supports more than just Vulkan.
          You will be using the cleaned Linux version with Windowz kernel bits. I believe you said that the Linux version is cleaned from code that is shared with D3D. After that you can have a VK Dev version with a git source where anyone can contribute and a monthly stable that you can build yourselves and includes all the third party commits.

          Comment


          • #45
            I want to see the UI, Radeon Chill, etc., ported to Linux.

            Comment


            • #46
              Intel's ANV driver isn't gallium based, neither RADV as it was based on ANV, right?

              So this part of not being based on gallium is a non issue AFAIK.

              Once all LLVM patches are upstreamed, can this driver be bundled with mesa or something like what is done for ANV and RADV?

              Comment


              • #47
                Originally posted by andrei_me View Post
                Once all LLVM patches are upstreamed, can this driver be bundled with mesa or something like what is done for ANV and RADV?
                No reason/need to as it doesn't make use of any Mesa infrastructure and would just obstruct AMD's effort for keeping this code easily shareable with their internal/Windows code, etc.

                RADV does make use of some shared code originally introduced by RadeonSI with amdrlib and some other common Radeon items if my memory serves me.
                Michael Larabel
                https://www.michaellarabel.com/

                Comment


                • #48
                  It seems like just last week I was complaining about AMD's Vulkan implementation still not being released when hitting against limitations in RADV when playing Wolfenstein 2 on my Fury X. Feels like AMD dropped this Vulkan code release especially to address my complaints once again (just like how AMD suddenly fixed the Fury X LEDs almost immediately after I complained about it). Perhaps I should complain more often!

                  Thanks AMD. I'll be purchasing a new card from you this week.

                  Comment


                  • #49
                    Originally posted by bridgman View Post
                    It does get discussed from time to time, but so far the conclusion has been that for Windows the competitive advantages of closed source outweigh the efficiency benefits of giving app developers zero-effort access to source code.
                    I wonder what advantage and especially over who that might be.

                    Comment


                    • #50
                      That's great news! Even greater news since it will ease the use of Radeon Graphics Profiler (for the few of us that do graphics development in Linux).

                      Originally posted by juno View Post

                      I wonder what advantage and especially over who that might be.
                      I believe AMD does some fine-tuning for some applications. The Vulkan synchronization model doesn't offer enough granularity for them (which is unfortunate) and that means some (minor I would guess) performance loss.

                      Comment

                      Working...
                      X