[PATCH libdrm] add libsync.h helper

Rob Clark robdclark at gmail.com
Mon Oct 31 15:21:20 UTC 2016


On Mon, Oct 31, 2016 at 11:15 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Mon, Oct 31, 2016 at 10:57:16AM -0400, Rob Clark wrote:
>> On Mon, Oct 31, 2016 at 10:38 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> > Which discards the synchronisation on the new fence if there's an error,
>> > are we meant to flag a GL_ERROR?
>>
>> The error checking should already be done at the egl level.  The same
>> eglCreateSync() has two modes, one where you pass in -1 and are asking
>> the driver to create a fence, and one where you pass in a valid fd
>> which you want to sync on.  For at least the gallium bits, these turn
>> into different code paths into the driver.  So the fd2<0 case would be
>> an assert().  I'm not entirely sure what behaviour you'd want for
>> i965.
>
> Either path could reasonably err with ENOMEM, ENFILE. Disregarding the
> fence (so we keep on bumbling on) and logging the error for later
> inspection. As far as the backend is concerned, it looks like we just
> have to ensure we don't lose the current fences and return NULL/-1.
>
> Check dri2_dup_native_fence_fd() for error handling of its
> dup(sync->SyncFd), only some paths set the _eglError().

yeah, I guess spec doesn't really define what happens if EMFILE..
although really quite a lot of things will start falling over at that
point.  I guess we could set EGL_BAD_PARAMETER although that isn't
really the perfect error.

BR,
-R


> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre


More information about the dri-devel mailing list