[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