About drm_hwcomposer (Was Re: About the PixelFormat mappings in drm_gralloc)

[Chih-Wei Huang]

Hello Sean / Zach / Dan, ...
This is the android-x86 project. We are trying to
utilize the drm_gralloc and drm_hwcomposer
released in android 6.0 source tree to
enable GPU acceleration for marshmallow-x86 porting.
However, now I got stuck with some technical issues.
Since you are the main developers of drm_hwcomposer,
I hope you can give me a hand.

Here are some questions I have:

* First is about the kernel requirement of drm_hwcomposer.
Seems it uses the new drm atomic interfaces that are
even not enabled by default in the kernel 4.0 we use.
What's the minimum kernel version it need?
Or, do I need to apply some particular kernel patches for it?

* On the other hand, drm_hwcomposer seems to use
old libdrm atomic apis of libdrm. However, we use the
latest libdrm (2.4.65+) which has different atomic api names.
Refer to
https://android.googlesource.com/platform/external/libdrm/+/ba5b0e9d9a3c894673b68b14cc82f53df32bbce8%5E%21/
vs
http://cgit.freedesktop.org/mesa/drm/commit/?id=ed44e0b9585c563905447eceed12af9c1c7ca8d4
(cc to the api author Ville Syrjälä to comment as well)
I have to replace the old apis by the newer like
drmModePropertySetPtr -> drmModeAtomicReqPtr,
drmModePropertySetAdd -> drmModeAtomicAddProperty, ...
Not sure if I did it correctly. But at least it built ok.
Would you like to update libdrm and drm_hwcomposer
to use the latest api?
I could submit a patch for it to AOSP if you want.
(Refer to
https://sourceforge.net/p/android-x86/external_libdrm/ci/marshmallow-x86/tree/
)

* I'm also curious what GPUs have been tested to work
with drm_hwcomposer. Since I saw some Nvidia related
patches, I wonder if it only works with Nvidia GPU?
Would you expect it to work with other vanilla drm drivers
like i915, radeon, and nouveau? If not, why?

* Is there any real target that uses drm_hwcomposer
in android 6.0 now? Grepping the android 6.0 tree
I didn't find any clue.

You may also refer to the following long discussion
below for the problems I encountered...

Look forward to hearing from you!

2015-10-30 14:35 GMT+08:00 Chih-Wei Huang <cwh...@android-x86.org>:
> 2015-10-29 22:25 GMT+08:00 Rob Clark <robd...@gmail.com>:
>> On Thu, Oct 29, 2015 at 3:36 AM, Chih-Wei Huang <cwh...@android-x86.org> wrote:
>>> 2015-10-27 16:56 GMT+08:00 Tapani Pälli <tapani...@intel.com>:
>>>> On 10/27/2015 10:41 AM, Chih-Wei Huang wrote:
>>>>>
>>>>>
>>>>> Hi Tapani,
>>>>> Recently the Mesa developers (Emil and Rob) pointed out
>>>>> there are some funny mapping defined in drm_format_from_hal
>>>>> of drm_gralloc. (see above discussion)
>>>>>
>>>>> Checking the git history, I found you made a change
>>>>> to this mapping at 2012/08/31 (submitted by Daniel Leung):
>>>>>
>>>>>
>>>>> https://sourceforge.net/p/android-x86/external_drm_gralloc/ci/28d19f649f276ed8302a7d3bab078f692a84e6d9/
>>>>>
>>>>> The mapping of HAL_PIXEL_FORMAT_RGB_888 and
>>>>> HAL_PIXEL_FORMAT_BGRA_8888 was silently changed
>>>>> from DRM_FORMAT_ARGB8888 to DRM_FORMAT_XRGB8888
>>>>>
>>>>> Could you explain it? Is there any rationale?
>>>>> Shouldn't it be DRM_FORMAT_BGRA8888?
>>>>>
>>>>
>>>> Sorry, I can't recall what has been the motivation for this. What I do know
>>>> is that some of the code is buggy and some of the fixes we had internally
>>>> were never pushed/released when I stopped working on that project.
>>>>
>>>> Fortunately Google has picked up on this code and has made several fixes +
>>>> updated functionality in to how gralloc+hwcomposer combo is defined today
>>>> (kms pieces should not live in gralloc anymore).
>>>>
>>>> https://android.googlesource.com/platform/external/drm_gralloc
>>>>
>>>> My recommendation is to check if this issue is fixed there.
>>>
>>> Tapani, thank you for the suggestion.
>>>
>>> Originally I prefer not to use google's branch
>>> since it's pulled from an old commit of drm_gralloc
>>> from android-x86 repository.
>>> We have a lot of improvements since that point.
>>> Simply merging them results in many conflicts.
>>>
>>> But I decide to give it a try as you suggested.
>>> However, there are some building errors.
>>> Google's drm_hwcomposer uses an old
>>> drm atomic apis, while we use the (almost) latest libdrm.
>>> I tried to replace the old apis by the new apis
>>> ( drmModePropertySetPtr -> drmModeAtomicReqPtr,
>>> drmModePropertySetAdd -> drmModeAtomicAddProperty, ...)
>>> Not sure if I did it correctly. But finaly it built ok.
>>
>> I think we do want to move to using drm_hwcomposer eventually..
>
> Yes, I think so. But now I stuck.
> Don't know how to proceed.
>
>> although that might be a bigger task. You would want as new a kernel
>> version as possible for i915, but I think atomic is still disabled by
>> default (ie. without i915.nuclear_pageflip=y).
>
> Hmm, OK.
> I wonder what the kernel requirement of Google's drm_hwcomposer.
> Most android devices still use older kernel like 3.10...
>
> Let's ask the help from Google engineers...
>
>>> However, SurfaceFlinger crashed on hwcomposer.drm
>>> initializing. The call failed (in drmresources.cpp):
>>>
>>> ret = drmSetClientCap(fd_, DRM_CLIENT_CAP_ATOMIC, 1);
>>>
>>> Tracing kernel drm and i915 module, seems I need to set
>>> drm.atomic=1 and i915.nuclear_pageflip=1 to make it work.
>>> But then it failed again:
>>>
>>> 10-29 07:26:23.966 1639 1639 E hwc-drm-resources: Failed to get
>>> properties for 19/cccccccc
>>> 10-29 07:26:23.966 1639 1639 E hwc-drm-crtc: Failed to get ACTIVE property
>>> 10-29 07:26:23.966 1639 1639 E hwc-drm-resources: Failed to initialize crtc 19
>>> 10-29 07:26:23.966 1639 1639 E hwcomposer-drm: Can't initialize Drm object -19
>>
>> hmm, maybe the 'ACTIVE' property came in after 4.0?
>
> Oh, I don't know what it is...
>
>
>>> The failed call is (also in drmresources.cpp):
>>>
>>> props = drmModeObjectGetProperties(fd_, obj_id, obj_type);
>>>
>>> Due to my limited knowledge about drm/hwc,
>>> I was unable to debug further.
>>>
>>>
>>> My impression is Google's hwcomposer uses the relative
>>> new drm atomic apis which are not supported well in
>>> our current drm and i915 drivers of kernel 4.0.
>>> Is it true? Should I try a newer kernel, say 4.3-rcX?
>>>
>>> Please advice how to proceed.


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Chih-Wei Huang]

2015-11-05 3:53 GMT+08:00 Sean Paul <sean...@chromium.org>:

> On Fri, Oct 30, 2015 at 4:21 AM, Chih-Wei Huang <cwh...@android-x86.org>
> wrote:
>>
>> Hello Sean / Zach / Dan, ...
>
>

> Hi,
> Sorry for the delayed response.

Thank you for the reply.

>> This is the android-x86 project. We are trying to
>> utilize the drm_gralloc and drm_hwcomposer
>> released in android 6.0 source tree to
>> enable GPU acceleration for marshmallow-x86 porting.
>> However, now I got stuck with some technical issues.
>> Since you are the main developers of drm_hwcomposer,
>> I hope you can give me a hand.
>>
>> Here are some questions I have:
>>
>> * First is about the kernel requirement of drm_hwcomposer.
>> Seems it uses the new drm atomic interfaces that are
>> even not enabled by default in the kernel 4.0 we use.
>> What's the minimum kernel version it need?
>> Or, do I need to apply some particular kernel patches for it?
>>
>

> Right now it works against the chromeos-3.18 branch of
> https://chromium.googlesource.com/chromiumos%2Fthird_party%2Fkernel
>
> As you might guess, this is based on the 3.18 kernel with a bunch of
> cherry-picked patches on top. We needed to grab the atomic patches before
> they were merged, which is why things might slightly differ.

Could you point out what patches are necessary?
Or (maybe simpler), would the vanilla kernel 4.3 or even 4.4-rcX work?
We always prefer the latest kernel for the latest drivers
to support more modern devices.

>> * On the other hand, drm_hwcomposer seems to use
>> old libdrm atomic apis of libdrm. However, we use the
>> latest libdrm (2.4.65+) which has different atomic api names.
>> Refer to
>>
>> https://android.googlesource.com/platform/external/libdrm/+/ba5b0e9d9a3c894673b68b14cc82f53df32bbce8%5E%21/
>> vs
>>
>> http://cgit.freedesktop.org/mesa/drm/commit/?id=ed44e0b9585c563905447eceed12af9c1c7ca8d4
>> (cc to the api author Ville Syrjälä to comment as well)
>> I have to replace the old apis by the newer like
>> drmModePropertySetPtr -> drmModeAtomicReqPtr,
>> drmModePropertySetAdd -> drmModeAtomicAddProperty, ...
>> Not sure if I did it correctly. But at least it built ok.
>> Would you like to update libdrm and drm_hwcomposer
>> to use the latest api?
>
>

> Yes, definitely, this is something we need to do. I grabbed the patches from
> the list and haven't updated them to reflect upstream.

>> I could submit a patch for it to AOSP if you want.
>> (Refer to
>>
>> https://sourceforge.net/p/android-x86/external_libdrm/ci/marshmallow-x86/tree/
>> )
>>
>

> We're actively trying to move things around such that we can accept external
> patches. I don't have a concrete timeline, hopefully soon.

OK. I attach the patch for your reference.

> Word of warning, the version of drm_hwcomposer that's on AOSP right now is
> horribly out of date. It's our goal to get things to a point where we're
> doing development in the open, similar to our Chromium development. Again,
> hopefully soon.

So sounds like the current drm_hwcomposer in
Android 6.0 release is not feasible to use?
Seems I'd better to wait your new release, right?

>> * I'm also curious what GPUs have been tested to work
>> with drm_hwcomposer. Since I saw some Nvidia related
>> patches, I wonder if it only works with Nvidia GPU?
>> Would you expect it to work with other vanilla drm drivers
>> like i915, radeon, and nouveau? If not, why?
>
>

> It _should_ work with any drm display driver, however we've only had limited
> testing.

Good to know!

Thanks a lot!