On Fri, 2017-09-29 at 13:49 +0800, Chih-Wei Huang wrote: > 2017-09-29 5:29 GMT+08:00 Rob Herring <robh@xxxxxxxxxx>: > > On Thu, Sep 28, 2017 at 11:43 AM, Chih-Wei Huang > > <cwhuang@xxxxxxxxxxxxxxx> wrote: > > > 2017-09-27 19:58 GMT+08:00 Robert Foss <robert.foss@xxxxxxxxxxxxx > > > >: > > > > From: Sean Paul <seanpaul@xxxxxxxxxxxx> > > > > > > > > Since HWC2 doesn't require the use of threads to implement > > > > correct > > > > synchronization, remove some of these threads. > > > > > > May I ask to avoid HWC2 only implementation? > > > The main reason is not all GPUs support > > > drm_hwcompser (as discussed in another thread). > > > > Which thread? Is that because they don't support explicit fences? > > Or > > something else? > > The "drm_hwcomposer moving to fd.o" thread. > For example, see > https://lists.freedesktop.org/archives/dri-devel/2017-September/15358 > 0.html > > > > To continue supporting these GPUs we need to > > > keep using HWC1 version of SurfaceFlinger. > > > > I think that is a lot of complexity to keep which will impact > > future > > changes as well. For example, is keeping it going to make removing > > sw_sync dependency (A non-stable debugfs interface) more difficult? > > drm_hwcomposer is already complex enough IMO with the GL > > compositing > > that removing some complexity would be a good thing. > > > > > So it's better to keep the code compatible with > > > HWC1. At least make it be a compile-time option. > > > > > > Personally I have a patch to make > > > HWC1 vs HWC2 a compile-time choice > > > of drm_hwcomposer. > > FYI, the patch is > https://osdn.net/projects/android-x86/scm/git/external-drm_hwcomposer > /commits/7acc332019d211cb2747fd4068cf41aaa62753fb > > > Perhaps just leave the current state as a separate branch. > > Did you mean we maintain the branch in our repo? > (that's what we do now, but I hope to avoid that) > > Or fd.o could help to maintain the two branches (HWC1 and HWC2)? > Android later than O will not support HWC1 (as far as I understand it), so HWC2 is the way forward. Furthermore I think targeting aosp/master at all time is the right thing to do for drm_hwcomposer. I for one am less than keen on maintaining branch that is incompatible with aosp/master upstream. Ideally we wouldn't maintain a compile time switch either, not on principle but because of the development overhead it causes. We have very finite resources contributing to drm_hwcomposer. If it was cheap&&easy to support old Android versions we should, but I don't think it is. I would suggest maintaining a HWC1 fork downstream as the way forward. But any input is welcome. Rob. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
