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. Sean > > Rob -- Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
