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
    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
    Alien Isolation on up-to-date Arch Linux install using the RadeonSI OSS driver, mesa 11.0.4-1PC Specs : i5 core 7507970 1GHz edition8GB RAM


    Comment


    • #32
      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


      • #33
        "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.


        AMD Bonaire, 1100 MHz, 896 Cores, 56 TMUs, 16 ROPs, 2048 MB GDDR5, 1625 MHz, 128 bit

        AMD Hawaii, 947 MHz, 2560 Cores, 160 TMUs, 64 ROPs, 4096 MB GDDR5, 1250 MHz, 512 bit

        Comment


        • #34
          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; 21 July 2017, 01:41 PM.

          Comment


          • #35
            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


            • #36
              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


              • #37
                bridgman et al: As has been discussed in the relevant places before, we cannot switch CIK to amdgpu by default until there is feature parity with radeon. The main missing piece being DC for HDMI/DP audio.

                Comment


                • #38
                  @Bridgeman I didn't intend to blame AMD. I love AMD and their devs for their open source efforts and am currently using AMD gpu and I understand that soon when things will start settling we will not have headache of installing multiple drivers. I was lot confused with AMD stack and so I said it.
                  PS. Will soon Mesa drivers and windows open gl share same code in near future?? Is it even possible?

                  Comment


                  • #39
                    Originally posted by KRiloshart View Post
                    PS. Will soon Mesa drivers and windows open gl share same code in near future?? Is it even possible?
                    No worries, it was a good question... and I was glad I could answer with "we are already in the process of merging..." rather than "we are talking about merging..."

                    Originally posted by KRiloshart View Post
                    PS. Will soon Mesa drivers and windows open gl share same code in near future?? Is it even possible?
                    It's going to depend on whether it becomes practical to add OpenGL compatibility profile support to the Mesa drivers (the ability for an application to use new and deprecated OpenGL functions at the same time with somewhat vendor-specific interaction). OpenGL usage is mostly used on Windows for CAD workstation applications these days, where compatibility profile support is a fairly common requirement. Right now there are more people opposed to allowing compatibility profiles into Mesa than people in favor of it.

                    In the meantime we are pushing hard on Mesa OpenGL as a gaming solution and the devs have been making really good progress. Past that, it's a lot less clear what to do.

                    Are there any serious Windows games that would benefit from a faster OpenGL these days ? My impression was that all the OpenGL users of old had hopped across to Vulkan, so the closest thing to a "legacy API" these days was DX11.
                    Test signature

                    Comment


                    • #40
                      It's not workstation customers who want compatibility profiles - it's the major ISVs who write the applications that want them, with encouragement from a GPU vendor who benefitted from the "vendor-specific" nature of compatibility profile implementations.
                      Test signature

                      Comment

                      Working...
                      X