[PATCH hwc v2 1/6] drm_hwcomposer: Remove threading

[Robert Foss]

On Fri, 2017-09-29 at 13:49 +0800, Chih-Wei Huang wrote:
> 2017-09-29 5:29 GMT+08:00 Rob Herring <robh at kernel.org>:
> > On Thu, Sep 28, 2017 at 11:43 AM, Chih-Wei Huang
> > <cwhuang at android-x86.org> wrote:
> > > 2017-09-27 19:58 GMT+08:00 Robert Foss <robert.foss at collabora.com
> > > >:
> > > > From: Sean Paul <seanpaul at chromium.org>
> > > > 
> > > > 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.