Announcement

Collapse
No announcement yet.

A Word Of Warning When Using AMDGPU-PRO On An Unsupported Kernel

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

  • #41
    Originally posted by Kano View Post
    Back to the AMDGPU kernel module via DKMS, what exactly happened as dkms did not fail? Want to see "dkms status". Usually you would see some override of the original module.
    If module does compile, it does not mean it will work fine in this case ... AFAIU this, basically amdgpu-pro module compile under 4.8 kernel, but makes Vulkan slow it seems.

    Comment


    • #42
      Originally posted by darkbasic View Post
      New driver, old problems. Until PRO will be able to run on a fully open source mainline kernel it will keep being like the old, useless "fglrx". Just let it die and focus on the open driver, we still need decent OpenCL support.
      There is no problem at all, amdgpu-pro supports Ubuntu 16.04 and that have 4.4 kernel... so trying 4.8 is in a land of "user tried something" and on that point it fail to work as expected

      If you follow recommendation, you wouldn't hit the issue Even opensource drivers can have regression once changing kernels so that is about it

      Comment


      • #43
        Originally posted by Kano View Post
        Back to the AMDGPU kernel module via DKMS, what exactly happened as dkms did not fail? Want to see "dkms status". Usually you would see some override of the original module.
        In all our tests DKMS install did fail, leaving the -PRO userspace stack running over the upstream kernel driver with reduced performance; what I'm not sure of is whether the error reporting was sufficiently visible.
        Last edited by bridgman; 14 November 2016, 08:55 PM.
        Test signature

        Comment


        • #44
          Sounds like the same old issue I was running into way back when I had my 390x, WAY BACK.

          Anyway we have seen comparable OGL vs D3D in the past, its just we get bugs and regressions all the time so its hard to get all AIO driver solution atm for Linux. I'm using NVIDIA 375 atm and it works just fine except for problematic SLI functionality... You won't be playing Deus Ex at [email protected] anytime soon thats for sure!

          Comment


          • #45
            PS. Yes I know Deus Ex is a BAD port, but it still stresses the system and also runs somewhat bad under windows also. I can't edit my posts because EDIT button is non-existent for me!

            Comment


            • #46
              Originally posted by theriddick View Post
              PS. Yes I know Deus Ex is a BAD port, but it still stresses the system and also runs somewhat bad under windows also. I can't edit my posts because EDIT button is non-existent for me!
              Actually Deus Ex is running about 70% of Windows performance, which makes it a good port, not a bad one. Or at least a decent, middle of the road port.

              There aren't a lot that are doing better than 70%.

              Comment


              • #47
                Originally posted by dungeon View Post
                But is probably most of the GL slowness came from glx and validation bound, but gallium nine somwhow just avoid hitting these... but that also does not run all games succesfully, and not at all those beyond (and bellow) DX9 level, so there again you are sometimes fast enough and sometimes slow to cry and sometimes it does not even work
                Sounds rational, but my guess is: I don't have Windows ATM, so I can't just compare the OpenGL performance, but given that "nine", being a generic code across many gallium drivers, compares/beats the original Windows DX performance — I'd assume the OpenGL part of that driver, is at least the same in performance as it was on Windows. It's because, from my understanding, both OpenGL and nine are implemented through gallium, which is already pretty good.

                Comment


                • #48
                  Well amdgpu-pro GL implementation is exactly the same like on Windows, but where it runs and how it runs is different.

                  And particulary with amdgpu-pro is different, previously flgrx had its own libGL/GLX setup by default, but now use mesa's one (and have perf regression due to that switch )... well it is probably simpliest to say that it now just behave sort of like mesa's DRI blob driver.

                  Thus i don't think performance is the same anymore like on Windows... even on nVidia it is not the same across Windows/Unix, because of X similarity i would actually guess it behave more similar across unixes than it is similar to Windows

                  Comment


                  • #49
                    bridgman, I just wanted to use the newest AMDGPU-PRO (16.40) with my R7 260X on Ubuntu Gnome 16.04 (so kernel 4.4) but once again I have issues with the Vulkan part. The examples from VulkanSDK fails on vkCreateSwapchainKHR but this time turning on validation does not give any explanation. I failes on assert(!err) where err is the return code from above mentioned function. Some time ago (on the previous version - 16.30.3) I've discovered that this function fails with an error like "imagelayers should be at least 1 and no more then 0". But what is more interesting - all was working when I used lightdm (the error message was the same, but applications where running fine) but when using gdm it was crashing. Because of that I am using lightdm with Gnome (not the best but works) but it seems it is not enough for the current 16.40 version. I even checked with Unity instead of Gnome and vkCreateSwapchainKHR was behaving there the same way. I really would like to use AMDGPU-PRO with Gnome (it already requires patching cogl to work) as I need OpenCL and Vulkan but it is really hard to get it working while I guess it sould work out of the box (Ubuntu 16.04, 4.4 kernel the only thing is the Gnome flavour).

                    Comment


                    • #50
                      Originally posted by faldzip View Post
                      I even checked with Unity instead of Gnome and vkCreateSwapchainKHR was behaving there the same way.
                      Does "behaving there the same way" mean failing ?

                      When you were running Unity instead of Gnome what else would have been different between the system you were running and regular Ubuntu ?
                      Last edited by bridgman; 15 November 2016, 09:06 AM.
                      Test signature

                      Comment

                      Working...
                      X