Re: [PATCH libdrm] add libsync.h helper

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 31, 2016 at 11:15 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux