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/153580.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)? -- Chih-Wei Android-x86 project http://www.android-x86.org _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
