Announcement

Collapse
No announcement yet.

Open-Source AMD Radeon Linux Graphics In Great Shape For Workstations, Handily Beating Proprietary Driver

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

  • #21
    Originally posted by Mystro256 View Post
    You've obviously never seen the mess that is Windows driver development. Sure Mesa would work on Windows, but there's piles of things that MS needs *cough*DRM*cough* that makes mesa pretty challenging to use. Although, Mesa is MIT I think, so they might be able to fork it and try to carry some non-free patches on a private tree, but it definitely doesn't come for free.
    Things are not the straight forwards. Mesa3d being the OSmesa bit does work on Windows and reactos does use it. This is software rendering using galluim3d. On top you have d3d12 being developed by Microsoft that is opengl on top of dx 12 and we have zink that is opengl on top of Vulkan.

    Yes it would be good to see where the AMD closed source opengl implementations are on performance on windows vs zink and d3d12 implementations.

    DirectX 12, NVIDIA CUDA, OpenGL and OpenCL acceleration are coming to the Windows Subsystem for Linux.


    It is interesting to read this. WDDM D3DKMT is being exported into Linux by Microsoft for WSL2. WDDM of Microsoft has something equal to Direct Rendering Manager under Linux. Mesa does not have a direct WDDM D3DKMT driver support.

    Really I see no particular need for a private fork. Since Mesa is already run on Windows that makes this process simpler. Having the driver to hook straight down to WDDM D3DKMT system is missing.

    This is more the will todo this than anything else. I am not sure if there is a performance reason not to go to the effort of implementing WDDM support in Mesa3d. Yes if AMD or Intel wanted to add WDDM support to their Mesa3d drivers there would be no reason to reject the patches since d3d12 stuff is mainlined.

    This change adds a gallium D3D10 state tracker that works as a WDDM UMD software driver, similar to Microsoft WARP, but using llvmpipe/softpipe. The final deliverable...


    Yes there is work to implement the user mode driver parts of dx10 in the mesa mainline. The reality here is over time more and more parts to implement a Windows graphics driver stack is appearing in Mesa source tree.

    Comment


    • #22
      Originally posted by Lbibass View Post
      That’s embarrassing. I hope they can take some of the optimizations done on the open source side and use it in the windows drivers.

      AMD’s OpenGL is an embarrassment. Both Windows and Linux.
      AMD is an embarrassment.

      Comment


      • #23
        Originally posted by Steffo View Post
        AMD should abandon their proprietary driver and invest their energy in the open source driver.
        If I recall right that exactly what AMD is trying to achieve.

        Comment


        • #24
          Originally posted by obri View Post

          Do I understand you right, that Marek is an AMD dev working on the proprietary driver who helps also in developing the opensource driver?
          Marek works only on the open source drivers. Like I said, we have two teams, one works on mesa, one works on our proprietary driver.

          Comment


          • #25
            Originally posted by obri View Post

            Is it possible to do something like opensourcing the Windows driver and sharing the oss codebase between Win and Linux? AFAI understand, actually the closed source Linux driver shares the codebase with the Windows driver.
            Perhaps it is completely naive, but wouldn't it save ressources and bring more speed to the driver development, when you would do it with one driver oss code base, and work as a team on one driver then?
            It's funny, when we first went to upstream our DC display code, we got a lot of flack for trying to share code across OSes rather than maintaining separate code bases.

            Comment


            • #26
              Originally posted by Steffo View Post
              AMD should abandon their proprietary driver and invest their energy in the open source driver.
              The tricky bit with this is that the AMDGPU-PRO driver is related to a driver that supports more APIs, and more windowing systems, etc. In order for Mesa to take these over, it needs to support those windowing systems and APIs (and some functionalities not exposed by other APIs), and it needs to do so as well as the existing driver... except maybe they could run both, the same way you can run Mesa and AMDGPU-PRO simultaneously (again, the specific way this works is different on Windows).

              Comment


              • #27
                Originally posted by agd5f View Post
                It's funny, when we first went to upstream our DC display code, we got a lot of flack for trying to share code across OSes rather than maintaining separate code bases.
                I know they're being kinda silly about this here, but the flak was not "for trying to share code", it was because there were aspects of the code that would not normally pass review. I think it's unprofessional, and generally pretty lame, to mischaracterize something like this in a self-serving way; there is also zero chance that talking about your colleagues like this will make them more eager to collaborate with you.

                Comment


                • #28
                  Originally posted by agd5f View Post

                  It's funny, when we first went to upstream our DC display code, we got a lot of flack for trying to share code across OSes rather than maintaining separate code bases.
                  I do not want to criticize anything you are doing. I do not have enough information and knowledge to do so.

                  It was truly just meant as a question. And I am also aware, that it must not necessarily be an advantage for the Linux drivers.

                  So no offense from my side, just curiosity.
                  Last edited by obri; 08 March 2022, 10:50 AM.

                  Comment


                  • #29
                    Originally posted by microcode View Post
                    think it's unprofessional, and generally pretty lame, to mischaracterize something like this in a self-serving way; there is also zero chance that talking about your colleagues like this will make them more eager to collaborate with you.
                    I'm not sure what I did that was offensive. I didn't say anything about my colleagues. I was merely commenting about the fickle whims and armchair commentary from the those who comment in this forum.

                    Comment


                    • #30
                      Originally posted by obri View Post

                      I do not want to criticize anything you are doing. I do not have enough information and knowledge to do so.

                      It was truly just meant as a question. And I am also aware, that it must not necessarily be an advantage for the Linux drivers.

                      So no offense from my side, just curiosity.
                      No offense taken, it was meant as a somewhat of a joke I think it will be a challenge since each OS has it's own set of additional requirements. Windows has some pretty crazy requirements that wouldn't fly on Linux. So we'd probably have to fork it if we tried to code share. Resyncing trees would be a lot of work, for little gain. I think if you want to code share, you need to code share directly. Once you fork, it gets harder and harder to stay in sync. Additionally, there would be quite a bit of training required to get internal developers in sync with mesa governance models and what is ok and not ok to discuss in public. So, it's theoretically possible, but it's not that slam dunk it might seem to be.

                      Comment

                      Working...
                      X