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

[Chih-Wei Huang]

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/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