lkml.org 
[lkml]   [2014]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences
Am 23.07.2014 09:09, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
> <maarten.lankhorst@canonical.com> wrote:
>>> Can we somehow avoid the need to call fence_signal() at all? The interrupts at least on radeon are way to unreliable for such a thing. Can enable_signalling fail? What's the reason for fence_signaled() in the first place?
>> It doesn't need to be completely reliable, or finish immediately.
>>
>> And any time wake_up_all(&rdev->fence_queue) is called all the fences that were enabled will be rechecked.
> I raised this already somewhere else, but should we have some common
> infrastructure in the core fence code to recheck fences periodically?
> radeon doesn't seem to be the only hw where this isn't reliable
> enough. Of course timer-based rechecking would only work if the driver
> provides the fence->signalled callback to recheck actual fence state.

Yeah, agree. The proposal won't work reliable at all with radeon.

Interrupts are accumulated before sending them to the CPU, e.g. you can
get one interrupt for multiple fences finished. If it's just the
interrupt for the last fence submitted that gets lost you are completely
screwed up because you won't get another interrupt.

I had that problem multiple times while working on UVD support,
resulting in the driver thinking that it can't submit more jobs because
non of the interrupts for the already submitted fence cam through.

Apart from that interrupts on Macs usually don't work at all, so we
really need a solution where calling fence_signaled() is completely
optional.

Christian.

> -Daniel



\
 
 \ /
  Last update: 2014-07-23 10:01    [W:0.207 / U:0.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site