Announcement

Collapse
No announcement yet.

Whoops, Linux 5.5 Missed Some "Critical" Intel Graphics Driver Patches

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

  • #41
    Originally posted by skeevy420 View Post

    Anecdotally, over the years I've seen more random negative posts about the R9 280/285/290 and their 3xx counterparts than any other generation of AMD GPUs.

    For me it has been kind of funny because my cheapo R7 260x was a rockstar on Linux and the more expensive ones weren't and I couldn't help but just feel bad for people who spent $300+ on a GPU that wasn't, and still might not be, very reliable or performing up to its potential.

    In fact, all the posts like yours made me hold off on upgrading until the 5xx Polaris cards came out. By the time the 5xx Polaris cards were released most major Polaris bugs were squashed and the 4xx cards were getting stellar reviews based on random Phoronix posts so it just made sense to go with the rehashed generation.

    Current posts are making me glad I'm kind of broke and unable to buy a Navi. I'd be screwed needing kernels too new to compile ZFS to use my GPU to play my games stored on a Zpool
    With AMD, you should always buy a year later, so you can atleast have half baked support, instead of an unusable GPU.

    ​​​​​Anyway, once that Intel Xe HP dGPU launches, bye bye AMD. Assuming of course that the price/performance/power consumption ratios are reasonable.

    Comment


    • #42
      Originally posted by sandy8925 View Post

      With AMD, you should always buy a year later, so you can atleast have half baked support, instead of an unusable GPU.

      ​​​​​Anyway, once that Intel Xe HP dGPU launches, bye bye AMD. Assuming of course that the price/performance/power consumption ratios are reasonable.
      With the exception of AMD rehashes since they're usually in the same state of the ones their based on.

      The only thing that worries me about the upcoming Intel GPUs are all the current issues around the i915 and random posts I've seen here about people here with 2015+ Intel integrated GPUs that are still having issues under certain conditions, usually multi-monitor or HiDPI related; though my RX 580 is also guilty of that...they go screwy and are unusable when overclocking is enabled and more than one monitor is in use.

      I am excited about a 2nd open source driver GPU and I wonder what all Intel will support...like BSD or more niche stuff like Haiku or Redox since they seem to have a lot more open source resources than AMD combined with how I tend to see more random Intel devs doing weird, niche OSS shit in their free time than people from any other company out there.

      Comment


      • #43
        Originally posted by skeevy420 View Post

        With the exception of AMD rehashes since they're usually in the same state of the ones their based on.

        The only thing that worries me about the upcoming Intel GPUs are all the current issues around the i915 and random posts I've seen here about people here with 2015+ Intel integrated GPUs that are still having issues under certain conditions, usually multi-monitor or HiDPI related; though my RX 580 is also guilty of that...they go screwy and are unusable when overclocking is enabled and more than one monitor is in use.

        I am excited about a 2nd open source driver GPU and I wonder what all Intel will support...like BSD or more niche stuff like Haiku or Redox since they seem to have a lot more open source resources than AMD combined with how I tend to see more random Intel devs doing weird, niche OSS shit in their free time than people from any other company out there.
        Intel hasn't worked on *BSD drivers AFAIK, but I remember reading that they did start contributing to the FreeBSD driver sometime last year.

        Comment


        • #44
          Originally posted by kcrudup View Post
          when the last merge of drm-next went in last week, I lost the ability to run 3 monitors in my particular setup (1080p HDMI/1920x1200 laptop/4K DP) as it wouldn't "fire up" the 4K display (probably some miscalculation of available bandwidth).
          So I finally got around to doing a proper bisect on this, and if anyone cares/has the same issues, it actually turned out to be a non-i915 issue; reverting commit cd82d82cbc0 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") fixes the issue for me (reported to the dev).

          Comment


          • #45
            5.7 looks to be interesting https://gitlab.freedesktop.org/drm/i...01#note_420302

            > According to a post to the ML (https://lists.freedesktop.org/archiv...ry/256831.html) there are over 400 patches queued for 5.7

            On my ICL XPS 7390, currently on 5.5.5, dmesg is full of fun stuff and mini-hangs (esp when playing video), but fortunately it hasn't unrecoverably crashed:

            Code:
            [436106.857409] i915 0000:00:02.0: Resetting rcs0 for preemption time out
            [436141.027300] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=106 end=107) time 155 us, min 2385, max 2399, scanline start 2377, end 2379
            [436560.552677] i915 0000:00:02.0: Resetting rcs0 for preemption time out
            [445062.686629] Asynchronous wait on fence i915:gnome-shell[52728]:2edb0e timed out (hint:intel_atomic_commit_ready+0x0/0x54 [i915])
            [445065.055707] i915 0000:00:02.0: Resetting rcs0 for preemption time out
            [445707.807226] Asynchronous wait on fence i915:gnome-shell[52728]:2f4380 timed out (hint:intel_atomic_commit_ready+0x0/0x54 [i915])
            [445710.047302] i915 0000:00:02.0: Resetting rcs0 for preemption time out
            [445796.382272] Asynchronous wait on fence i915:gnome-shell[52728]:2f5114 timed out (hint:intel_atomic_commit_ready+0x0/0x54 [i915])
            [445798.047321] i915 0000:00:02.0: Resetting rcs0 for preemption time out
            [465377.036676] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_globals_exit [i915])
            [468074.544099] Asynchronous wait on fence i915:gnome-shell[52728]:313050 timed out (hint:intel_atomic_commit_ready+0x0/0x54 [i915])
            [468076.145141] i915 0000:00:02.0: Resetting rcs0 for preemption time out
            [469670.340239] i915 0000:00:02.0: Resetting rcs0 for preemption time out
            [472214.658231] Asynchronous wait on fence i915:gnome-shell[52728]:32c7a4 timed out (hint:intel_atomic_commit_ready+0x0/0x54 [i915])
            [472216.196197] i915 0000:00:02.0: Resetting rcs0 for preemption time out
            [473678.976348] Asynchronous wait on fence i915:gnome-shell[52728]:33811c timed out (hint:intel_atomic_commit_ready+0x0/0x54 [i915])
            [473680.193332] i915 0000:00:02.0: Resetting rcs0 for preemption time out
            [516340.856646] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_globals_exit [i915])
            It's definitely true that the development team seems to struggle with the amount of hardware and logic paths across different gen hardwares they have to deal with.

            Comment


            • #46
              Originally posted by lkraav View Post
              On my ICL XPS 7390, currently on 5.5.5, dmesg is full of fun stuff and mini-hangs (esp when playing video), but fortunately it hasn't unrecoverably crashed:
              ... huh. I have an ICL 7390 (the 2-in-1 too, but essentially the same laptop) and have NONE of those issues no matter what I do (video, KDE compositor, VMWare with 3D accel) (and I'm running the bleeding-edge Linus' master, too). What are your DMC/Huc/GuC FW versions? Mine are 1.9/33.0/9.0, respectively

              Comment

              Working...
              X