On 4/25/23 14:08, Christian König wrote: > Well signaling that something happened is not the question. We do this for > both soft as well as hard resets. > > The question is if errors result in blocking further submissions with the > same context or not. > > In case of a hard reset and potential loss of state we have to kill the > context, otherwise a follow up submission would just lockup the hardware once > more. > > In case of a soft reset I think we can keep the context alive, this way even > applications without robustness handling can keep work. > > You potentially still get some corruption, but at least not your compositor > killed.
Right, and if there is corruption, the user can restart the session. Maybe a possible compromise could be making soft resets fatal if user space enabled robustness for the context, and non-fatal if not. > Am 25.04.23 um 13:07 schrieb Marek Olšák: >> That supposedly depends on the compositor. There may be compositors for very >> specific cases (e.g. Steam Deck) that handle resets very well, and those >> would like to be properly notified of all resets because that's how they get >> the best outcome, e.g. no corruption. A soft reset that is unhandled by >> userspace may result in persistent corruption. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
