Am 23.07.2014 11:38, schrieb Maarten Lankhorst:
op 23-07-14 11:36, Christian König schreef:
Am 23.07.2014 11:30, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:27 AM, Christian König
<christian.koenig@xxxxxxx> wrote:
You submit a job to the hardware and then block the job to wait for radeon
to be finished? Well than this would indeed require a hardware reset, but
wouldn't that make the whole problem even worse?
I mean currently we block one userspace process to wait for other hardware
to be finished with a buffer, but what you are describing here blocks the
whole hardware to wait for other hardware which in the end blocks all
userspace process accessing the hardware.
There is nothing new here with prime - if one context hangs the gpu it
blocks everyone else on i915.
Talking about alternative approaches wouldn't it be simpler to just offload
the waiting to a different kernel or userspace thread?
Well this is exactly what we'll do once we have the scheduler. But
this is an orthogonal issue imo.
Mhm, could have the scheduler first?
Cause that sounds like reducing the necessary fence interface to just a fence->wait function.
You would also lose benefits like having a 'perf timechart' for gpu's.
I can live with that, when it reduces the complexity of the fence interface.
Christian.
~Maarten
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
