Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

From: "Christian König" <deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
To: Jason Ekstrand <jason-fQELhIk9awXprZlt/sZkLg@public.gmane.org>,
	Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>,
	"amd-gfx mailing list"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"Maling list - DRI developers"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)
Date: Wed, 12 Jul 2017 18:45:38 +0200	[thread overview]
Message-ID: <f1375dda-2997-7ed5-dcde-e2fc5e1c44c2@vodafone.de> (raw)
In-Reply-To: <CAOFGe95mj1G_Ap0oOPFyatZWEbEk_Kwo8Wn_E+eYS16Nhz_huQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

[-- Attachment #1.1: Type: text/plain, Size: 707 bytes --]

Am 12.07.2017 um 17:53 schrieb Jason Ekstrand:
> [SNIP]
>
>     Is that easier than just waiting in the kernel, I'm not sure how
>     optimised we need this path to be.
>
>
> I don't think so.  I think it's more-or-less the same code regardless 
> of how it's done.  The advantage of doing it in the kernel is that 
> it's standardized (we don't have to both go write that userspace code) 
> and it doesn't have the problems stated above.

Ok, I'm convinced. The next price question is then how do we do it?

I mean writing an IOCTL to wait for a fence to appear is simple, but do 
we also need to wait for a fence to change?

As long as waits don't consume fences that might be rather tricky.

Christian.

[-- Attachment #1.2: Type: text/html, Size: 1702 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx