02:33 mareko: soreau: yes that's possible
02:36 mareko: soreau: if compositors and toolkits use only Vulkan compute queues, they would be mostly unaffected by GPU hangs because compute queues are mostly independent, so you can have a working desktop while the gfx queue is in a hung state and needs a GPU reset
02:38 mareko: if you are not running any games, i.e. the gfx queue is unused, then all GPU resets don't affect independent processes because compute queues can be reset independently
02:39 mareko: *independent=innocent
02:39 mareko: GL can't be used because it uses the gfx queue for compute shaders
02:47 airlied: I can't imagine toolkits or compositors just using compute shaders
02:48 airlied: would be an interesting experiment
02:49 soreau: mareko: since when did the vulkan stipulation come in?
02:49 soreau: so the gfx queue is the problematic one..
02:50 soreau: but vulkan can use the 'non-gfx' queue and still get the output on screen?
02:50 soreau: but gl(es) can't?
02:51 soreau: would some gl extension make this possible?
02:51 soreau:not really understanding this non-gfx queue
02:53 soreau: and presumably zink doesn't help
03:13 mareko: the queue is the hw ring where commands are written
03:13 mareko: GL always uses the gfx queue, while Vulkan can select from gfx, compute, transfer, and video queues
03:14 mareko: the compute queue doesn't have any draw calls
03:46 DemiMarie: Venemo: Losing VRAM is just a HW limitation that should be addressed in future versions
07:59 Venemo: DemiMarie: I don't work for AMD, so I can't really do anything about what future HW should or shouldn't do. I just thought to share some info