On Thu, May 3, 2018 at 9:32 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: > On Thu, May 03, 2018 at 09:14:41AM -0500, Rob Herring wrote: >> On Thu, May 3, 2018 at 8:47 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: >> > On Wed, May 02, 2018 at 04:56:29PM -0700, Alistair Strachan wrote: >> >> Use of the sw_sync API is not allowed any more. Until drm_hwcomposer is >> >> weaned off of sw_sync, build our own copy. >> > >> > I don't think it is used any longer. AFAICT, with 2 seconds of grep, it's >> > referenced in drmcompositorworker.cpp, virtualcompositorworker.cpp, and >> > hwcomposer.cpp >> > >> > I think these are all HWC1 legacy files, so they can probably just get cleaned >> > up. >> >> Are you sure? Doesn't the GL compositor have to wait on the fences of >> the input buffers and create new fences for the GL compositing output >> buffer(s) to pass into the kernel? It looked to me like sw_sync fences >> are used in the latter case and that needs to be converted to use >> eglCreateSyncKHR. > > Hmmm, yeah thanks for pointing that out. It does look like drmdisplaycomposition > is using sw_sync to handle the GL compositor release fences. > > I'm pretty confident that despite the known issues causing GLC to not work on > open stacks, there are probably a bunch of unknown issues that have been > introduced while we try to tiptoe around it. > > If anyone wants to remove it, I'd certainly be interested in reviewing that > patch :-). I'd do it myself, but unfortunately the amount of time I have > to dedicate to drm_hwc at this point is just enough to perform [incorrect] > reviews. Removing GL compositor or sw_sync? I've already written a patch to do the former. Rob _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
