linux-kernel - Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Jul 2014 11:52:57 +0200
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Christian König <deathsimple@...afone.de>
Cc:	Christian König <christian.koenig@....com>,
	Maarten Lankhorst <maarten.lankhorst@...onical.com>,
	Thomas Hellstrom <thellstrom@...are.com>,
	nouveau <nouveau@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	Ben Skeggs <bskeggs@...hat.com>,
	"Deucher, Alexander" <alexander.deucher@....com>
Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence
 implementation for fences

On Wed, Jul 23, 2014 at 11:47 AM, Christian König
<deathsimple@...afone.de> wrote:
> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter <daniel.vetter@...ll.ch>
>> wrote:
>>>
>>> The scheduler needs to keep track of a lot of fences, so I think we'll
>>> have to register callbacks, not a simple wait function. We must keep
>>> track of all the non-i915 fences for all oustanding batches. Also, the
>>> scheduler doesn't eliminate the hw queue, only keep it much slower so
>>> that we can sneak in higher priority things.
>>>
>>> Really, scheduler or not is orthogonal.
>>
>> Also see my other comment about interactions between wait_fence and
>> the i915 reset logic. We can't actually use it from within the
>> scheduler code since that would deadlock.
>
>
> Yeah, I see. You would need some way to abort the waiting on other devices
> fences in case of a lockup.
>
> What about an userspace thread to offload waiting and command submission to?

That's what your android guys currently do. They hate it. And google
explicitly created their syncpts stuff to move all that into the
kernel. That one does explicit fencing, but the end result is still
that you have fences as deps between different drivers.

The other problem is that dri/prime is running under an implicitly
sync'ed model, so there's no clear point/responsibility for who would
actually do the waiting. You'll end up with synchronous behaviour
since the render sooner or later needs to perfectly align with
client/compositor ipc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/