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 at amd.com> 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 >
