Announcement

Collapse
No announcement yet.

Linux 4.18 AMDGPU Tests: Vega Taking A Hit

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

  • #11
    Originally posted by bridgman View Post

    Display testing is actually one of the hardest areas to automate because you either need custom hardware analyzing signals or a custom rig with a camera looking at the display and figuring if the viewed image is "sufficiently close" in all the noise & pixel mismatch.

    For the former you need a database of what each display vendor/model considers acceptable (which doesn't exist AFAIK, and "industry standards" don't cut it); with the latter you need a lot of displays and a lot of cameras. In the end it comes back to humans with a lot of displays (and a lot of desk space, which is hard to find in these enlightened times) .
    I see. So in practice there is no regression testing at all, or there is "the best we can do" effort?

    Comment


    • #12
      Originally posted by shmerl View Post

      I see. So in practice there is no regression testing at all, or there is "the best we can do" effort?
      Yes, we have testing groups within AMD that do regular testing, but we can't always reproduce all problems due to differences in sw stacks, monitors, board/platform configurations, etc.

      Comment


      • #13
        If you are having issues with DP, please try this patch:

        Comment


        • #14
          Have 4.18-rc4 and a RX480 RX580-tified with bios mod.

          Work with 3 DP monitor (HD/4K/HD)

          Problems :
          * I can turn one or two monitors OFF and turn them back on, it's fine. If I turn the three monitors off, system is alive until I turn them back on then crash.
          * Sleep "work" but system crash when I wake it. Might be another Ryzen/stupid motherboard BIOS related issue

          Workaround for crash on all screens OFF : I can CTRL-ALT-F1 to text tty, then turn the screens off... then on then I can switch back to X then it's still alive, most of the time.
          Last edited by RavFX; 10 July 2018, 03:11 PM.

          Comment


          • #15

            I found the culprit of Vega lost performance: Michael forgot to put a screw that fix the card to the chassis:






            I let myself out...

            Comment


            • #16
              @M@GOid This is actually not even impossible, as my current GTX 1070 Ti ran with just 4x PCIe lanes when I first installed it. I had to reinstall the card to get 16x.

              Comment


              • #17
                Originally posted by bridgman View Post
                Display testing is actually one of the hardest areas to automate because you either need custom hardware analyzing signals or a custom rig with a camera looking at the display and figuring if the viewed image is "sufficiently close" in all the noise & pixel mismatch.
                For bugs of what is displayed - sure. But bugs causing system crashes or no image displayed at all should be possible to detect automatically. And sysfs has rtc/rtc0/wakealarm to allow for automated wakeup-after-some-seconds from S3.

                Comment


                • #18
                  Originally posted by RavFX View Post
                  Have 4.18-rc4 and a RX480 RX580-tified with bios mod.
                  * Sleep "work" but system crash when I wake it. Might be another Ryzen/stupid motherboard BIOS related issue
                  Unlikely, since S3 resumes used to work just fine even with dc=1 until linux-4.13.x

                  Workaround for crash on all screens OFF : I can CTRL-ALT-F1 to text tty, then turn the screens off... then on then I can switch back to X then it's still alive, most of the time.
                  Same here with an RX460, this work-around also helps to avoid some of the S3-resume crashes.

                  I never thought I would use the "chvt" command so often... and a script like
                  /usr/bin/openvt -c 12 -f -s -w -- vlock -a
                  to lock the screen :-(

                  Comment


                  • #19
                    Originally posted by dwagner View Post
                    For bugs of what is displayed - sure. But bugs causing system crashes or no image displayed at all should be possible to detect automatically. And sysfs has rtc/rtc0/wakealarm to allow for automated wakeup-after-some-seconds from S3.
                    System crashes definitely - a watchdog timer can pick that up - but AFAIK "no image displayed at all" is harder because there can frequently still be an image being sent out and page-flip interrupts being generated - it just isn't an image that the display chooses to accept.

                    Were you thinking about checking page-flip interrupts or is there something else I missed ?
                    Last edited by bridgman; 10 July 2018, 07:03 PM.
                    Test signature

                    Comment


                    • #20
                      Originally posted by bridgman View Post

                      System crashes definitely - a watchdog timer can pick that up - but AFAIK "no image displayed at all" is harder because there can frequently still be an image being sent out and page-flip interrupts being generated - it just isn't an image that the display chooses to accept.
                      Harder, but I don't imagine it would be much so.

                      If the goal is to identify "no image displayed at all", why would it take anything more than sending a bright test image to the screen and then checking whether the overall result is bright or dark using an external camera? (After all. I've never seen less than 3/4 of the screen be black when a monitor is keeping the backlight on to display an "Out of Range" or "No Signal" popup.)

                      I don't see why, in a pinch, a proof-of-concept for such an integration test couldn't be concocted using:
                      1. A $10 LCD monitor from a thrift-store with visible scratches marring the image (any model with a suitable sync range)
                      2. A cardboard box or some kind of scrap black-out curtain to isolate from variations in external lighting.
                      3. Any sub-$10 Chinese USB webcam which will obey manual exposure settings specified through v4l2 and the USB Video Class driver.
                      4. A test case which captures a frame with predefined exposure settings, takes the arithmetic mean of the pixels, and considers success to be "the result is above a certain threshold".
                      Last edited by ssokolow; 10 July 2018, 08:40 PM.

                      Comment

                      Working...
                      X