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(). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
