Announcement

Collapse
No announcement yet.

RadeonSI Compute Shader Patches Revised

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

  • #21
    Originally posted by rastersoft View Post
    Am I the only one to have troubles when visiting mesamatrix.net? It says Bad Gateway... (and forces me to use https)
    I've always used https, although when I point browser to http://mesamatrix.net I get the https URL anyways. Anyways, seems to be working for me.
    Test signature

    Comment


    • #22
      Originally posted by bridgman View Post

      AFAIK it's because of that quirk commit (at least on other users' hardware) - revert it and the problem goes away. The problem is that the commit was probably added to solve worse problems on someone *else's* board so just reverting it upstream is probably not a good fix.
      Got it.

      Originally posted by bridgman View Post
      Let's double-check something first though - do your PCI IDs match the quirk (device ID 0x6810, subsystem vendor ID 0x174b "PC Partner", subsystem device ID 0xe271) ?Running lspci -nn will give vendor/device info while lspci -vmm will give the subsystem vendor/device info, not sure if there is an easier way.
      Yes, I think that is exactly right. See:

      Code:
      02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT / Trinidad XT [Radeon R7 370 / R9 270X/370X] [1002:6810]

      Code:
      Slot:   02:00.0
      Class:  VGA compatible controller
      Vendor: Advanced Micro Devices, Inc. [AMD/ATI]
      Device: Curacao XT / Trinidad XT [Radeon R7 370 / R9 270X/370X]
      SVendor:        PC Partner Limited / Sapphire Technology
      SDevice:        Device e271
      NUMANode:       0
      However, note that I'm not willing to use a custom Kernel and revert changes. IMO the Kernel parameter is quite honestly "fast and efficient"

      Comment


      • #23
        Originally posted by bridgman View Post

        I've always used https, although when I point browser to http://mesamatrix.net I get the https URL anyways. Anyways, seems to be working for me.

        Now seems to work again.

        Comment


        • #24
          Originally posted by Qaridarium

          I am 100% sure that they will agree with you in the future.
          And I have the same opinion:

          Bug fixes should always be done at the point were the error is and not by some compatibility profile in the driver.

          This ends up in smaler codebase and less code in every segment and less costs for support old code. In the end everyone benefits in my point of view.

          I know nvidia makes a lot of money on this compatibility profile bullshit but they hurt the hole market by this Bad habit. And for this Bad habit alone i would never buy a nvidia product.
          Compatibility profile is not about working around client bugs; it's an extension that allows you to use legacy OpenGL functionality in 3.2 contexts and up.

          Comment


          • #25
            Originally posted by Amarildo View Post
            Yes, I think that is exactly right. See:
            ...
            However, note that I'm not willing to use a custom Kernel and revert changes. IMO the Kernel parameter is quite honestly "fast and efficient"
            OK, understood. At your convenience, can you please add your info to the bug ticket talking about reverting the patch ? Maybe ask if there is something that can be changed in the quirk that might let the quirk stay in without causing problems on systems like yours and Kevin's (originator of the bug ticket):



            Test signature

            Comment


            • #26
              Second and last patch for compute is llvm:
              …ute unit Summary: For GL_ARB_compute_shader we need to support workgroup sizes of at least 1024. However, if we want to allow large workgroup sizes, we may need to use less registers, as we have ...

              Now it won't be long for the mesa support and OpenGL 4.3!

              Comment


              • #27
                I've been excited to try all the new GL 4.2 / 4.3 stuff in mesa (I have AMD FIJI gpu), but unfortunately compiling the latest code fails

                Tried yesterday, tried again today ...

                Yesterday it was a compiler error in Clover with some LLVM function calls. Today it is gbm:

                /tmp/portage/media-libs/mesa-9999/work/mesa-9999/src/gbm/main/gbm.c: In function ‘_gbm_mesa_get_device’:
                /tmp/portage/media-libs/mesa-9999/work/mesa-9999/src/gbm/main/gbm.c:120:11: error: implicit declaration of function ‘major’ [-Werror=implicit-function-declaration]
                if (major(dev) == major(buf.st_rdev) &&
                ^
                /tmp/portage/media-libs/mesa-9999/work/mesa-9999/src/gbm/main/gbm.c:121:11: error: implicit declaration of function ‘minor’ [-Werror=implicit-function-declaration]
                minor(dev) == minor(buf.st_rdev)) {

                Mesa devs, do you not try to build your own code before pushing it into public repos? I also use the latest git/svn version of xorg-server, xorg drivers, llvm+clang, and many many other things, and all of them have been building just fine every time I have tried to update them.

                Comment


                • #28
                  Originally posted by bridgman View Post

                  OK, understood. At your convenience, can you please add your info to the bug ticket talking about reverting the patch ? Maybe ask if there is something that can be changed in the quirk that might let the quirk stay in without causing problems on systems like yours and Kevin's (originator of the bug ticket):


                  OK, I will as soon as I can.

                  Comment


                  • #29
                    Originally posted by tajjada View Post
                    Mesa devs, do you not try to build your own code before pushing it into public repos? I also use the latest git/svn version of xorg-server, xorg drivers, llvm+clang, and many many other things, and all of them have been building just fine every time I have tried to update them.
                    I apologise. Should not have blamed mesa devs.

                    Turns out the problem was on my (or rather, gentoo's side). After seeing a few other things break with the same errors, I investigated, and it turns out that it is an issue with a patch that gentoo applies to the latest version of glibc, which changes a certain system header slightly. I downgraded glibc and the problem went away. Yay I have the latest mesa now.

                    New OpenGL, here I come!

                    Comment


                    • #30
                      Originally posted by bridgman View Post

                      OK, understood. At your convenience, can you please add your info to the bug ticket talking about reverting the patch ? Maybe ask if there is something that can be changed in the quirk that might let the quirk stay in without causing problems on systems like yours and Kevin's (originator of the bug ticket):


                      Done. In the mean time, I'll keep using the following command that is working fine and gives me full performance (which I'll make executable at boot):

                      Code:
                      echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
                      BTW, by using the command above, will my card consume as much power as if it's on Full-Load?

                      Thank you again for your help, and if you do have any other suggestions please let me know

                      Cheers!

                      Comment

                      Working...
                      X