dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 203111] Unrecoverable GPU crash with DiRT 4
Date: Tue, 09 Apr 2019 01:39:44 +0000	[thread overview]
Message-ID: <bug-203111-2300-KGL8BNa3XY@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-203111-2300@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=203111

--- Comment #6 from Alex Deucher (alexdeucher@gmail.com) ---
(In reply to Thomas from comment #5)
> Thanks a lot for the detailed answer. I'm still not sure if I understand
> everything correctly (shouldn't the kernel driver validate the command
> stream from userspace/mesa and stop bad things before they hit hardware /
> hang the GPU?) 

It's not really feasible.  For one, it adds a lot of CPU overhead.  There is
also so much state in the 3D pipeline it's nearly impossible to validate all of
the possible cases that could cause a hang.  In some cases, you may not even
know that a particular combination is bad until it gets hit.

> 
> Damn, if this wouldn't be the wrong place I would ask for more details about
> your last reply (the thing about the display servers not catching up with
> the GPU reset - aren't there drivers which perform GPU resets just nice
> under X11 already? What about Wayland?). It's so freaking nice, I bet I
> would learn a lot if we wold continue the discussion... Anyway, thanks again
> for explaining and sorry for me going a bit off topic in this reply.

I'm not sure if other drivers silently reset the GPU when they encounter a
hang.  It's generally easier to deal with on integrated GPUs since they operate
on system memory.  On dGPUs, the contents of vram might be lost after a GPU
reset as the memory controller is reset.  If vram is lost, the application that
is running needs to reload it's vram state.  Also for reliability, applications
should really be made aware of a GPU reset so they can validate their data. 
E.g., you don't want a scientific application to silently get bad data because
the GPU was reset silently in the background.

> 
> 
> One last thing... It's exremely off topic but I already derailed this reply
> and it has to be told: Thank you Alex for being the guy you are. I bet AMD
> doesn't pay you to explain technical details to stupid end users like me but
> that's very appreciated. You're a hero, keep on rockin'!

Thanks!  Glad to help.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

      parent reply	other threads:[~2019-04-09  1:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-30  9:29 [Bug 203111] New: Unrecoverable GPU crash with DiRT 4 bugzilla-daemon
2019-04-01 16:02 ` [Bug 203111] " bugzilla-daemon
2019-04-02  7:38 ` bugzilla-daemon
2019-04-05 18:44 ` bugzilla-daemon
2019-04-05 20:31 ` bugzilla-daemon
2019-04-05 21:15 ` bugzilla-daemon
2019-04-05 21:15 ` bugzilla-daemon
2019-04-09  1:39 ` bugzilla-daemon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-203111-2300-KGL8BNa3XY@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).