Announcement

Collapse
No announcement yet.

AMDGPU vs. Radeon DRM On Linux 4.13 For AMD GCN 1.0/1.1 GPUs

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

  • #31
    I've been using AMDGPU on kaveri for a a long time. Six months? Other than things getting messed up when a bad patch went in for initializing uvd I've never had a problem.

    Comment


    • #32
      Originally posted by bridgman View Post
      We don't - the core ROCm support has been integrated into AMDGPU-PRO starting with 17.20 release (initially used for OpenCL only but that's a function of validation bandwidth), and we are in the process of pushing the same code upstream which gets it into the all-open Mesa+radeonsi stack.

      We are still recommending the ROCm stack for large scale HPC (and will probably continue to do so) but HPC-specific out-of-tree drivers have always been the norm for HPC.
      what is the problem of bringing all ROCm functionality to the all-open stack ? why not just put the best in 1 driver stack instead of confusing people with 2 different stacks ?
      Phantom circuit Sequence Reducer Dyslexia

      Comment


      • #33
        I should try running my HD7770 from a vanilla kernel + AMDGPU again, to make sure all bugs/regressions remain gone. I'm not going to use it regularly before DAL/DC is integrated, I'm using sound over HDMI with it.

        Comment


        • #34
          Originally posted by schmidtbag View Post
          It wouldn't surprise me if r600 is a higher priority than that.
          R600 works great except that it do miss ARB_compute_shader so Alien Isolation won't render correctly.
          I thought they would add extensions when games needed them but that's not true for r600g.
          This is what Alien: Isolation still looks like on R600g
          https://www.youtube.com/watch?v=n35hwmN3VmQ
          https://www.youtube.com/watch?v=ueoELXXduvk

          Comment


          • #35
            Originally posted by mitch074 View Post
            I should try running my HD7770 from a vanilla kernel + AMDGPU again, to make sure all bugs/regressions remain gone. I'm not going to use it regularly before DAL/DC is integrated, I'm using sound over HDMI with it.
            That's an SI card, it won't use DC, so waiting on that will offer no benefit.

            Comment


            • #36
              "With regards to the RADV Vulkan experience, it was working for me with the GCN 1.1 R7 260X and R9 290"

              R7 260x and R9 290 are GCN 2 gpus.

              https://en.wikipedia.org/wiki/List_o...FR9_200_Series
              https://www.techpowerup.com/gpudb/2465/radeon-r7-260x
              https://www.techpowerup.com/gpudb/2397/radeon-r9-290

              Comment


              • #37
                Originally posted by Holograph View Post
                Also, so far, the 290x is still pretty high-end for an AMD card.
                https://www.techpowerup.com/gpudb/2460/radeon-r9-290x
                Oct 24th, 2013
                TDP: 290W

                It is a good and old house heater. Otherwise is not modern at all. Sure you would have less problems with rx580. I would say that sell it ,but even windows users are not that stupid that would buy a four year old power hungry hardware. With a low price selling might succeed. I hope my kid replaces 750ti with rx570, I am fed up patching the nvidia driver for new kernels and working without X running and without easy way to rollback if the driver fails to work.

                Comment


                • #38
                  Originally posted by debianxfce View Post
                  It is a good and old house heater. Otherwise is not modern at all.
                  The 290(X) can still keep up with modern games and is Vulkan compliant. Therefore, it is literally modern.
                  Sure you would have less problems with rx580. I would say that sell it ,but even windows users are not that stupid that would buy a four year old power hungry hardware. With a low price selling might succeed. I hope my kid replaces 750ti with rx570, I am fed up patching the nvidia driver for new kernels and working without X running and without easy way to rollback if the driver fails to work.
                  Are you using repo drivers or have you decided to take the hard way out and install them manually? Distros (such as Debian) are pretty good at handling the Nvidia drivers without causing complications.
                  Last edited by schmidtbag; 07-21-2017, 01:41 PM.

                  Comment


                  • #39
                    Originally posted by bridgman View Post
                    Has anyone with Kaveri or Kabini tested with amdgpu recently and run into problems that would justify not flipping the switch for all of CI ?
                    As Kaveri+Hainan hybrid laptop user running on amdgpu, the Kaveri part is working fine aside vulkaninfo that still fails with RADV despite being Vulkan complain. It is a matter of optimization.

                    Comment


                    • #40
                      Besides that, any progress on OpenCL support for Tahiti based GPU like Radeon HD 7950?

                      AMD's support for Tahiti's OpenCL functions on systems running kernels newer than 4.3 have been abandoned for two years.

                      It's definitely not a good sign for GPU shoppers, if AMD can drop support to HD 7950, it can drop support to 480/580 cards any time soon.

                      Providing solid support to existing customers is the best advertisement to attract new customer, however, it seems that AMD does not think in that way.



                      Originally posted by bridgman View Post

                      We don't - the core ROCm support has been integrated into AMDGPU-PRO starting with 17.20 release (initially used for OpenCL only but that's a function of validation bandwidth), and we are in the process of pushing the same code upstream which gets it into the all-open Mesa+radeonsi stack.

                      We are still recommending the ROCm stack for large scale HPC (and will probably continue to do so) but HPC-specific out-of-tree drivers have always been the norm for HPC.



                      Quick reality check - we write a Vulkan driver, we start work on open sourcing it, Dave & Bas start working on a different driver and *we* are wasting resources ?

                      Just to be clear, Dave started work on radv for all the right reasons and radv may still end up being the primary Vulkan driver depending on how efficiently we end up being able to integrate community contributions back into our in-house driver, but blaming *us* for having two different drivers seems like a bit of a stretch.

                      There are still a number of features that need to be added to radv plus the ongoing effort of supporting new HW, so "dropping our driver for Linux and going with radv" is not the obvious slam-dunk that people would like to think... it's one of those nasty "both options suck in different ways" things instead.

                      Comment

                      Working...
                      X