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
