[Mesa-dev] [android-x86-devel] Re: need-help: how to change to newest mesa in android-x86?

[Rob Herring]

On Wed, Jan 13, 2016 at 12:17 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Wed, Jan 13, 2016 at 12:54 PM, Rob Herring <robh at kernel.org> wrote:
>> On Tue, Jan 12, 2016 at 8:06 PM, Chih-Wei Huang <cwhuang at android-x86.org> wrote:
>>> 2016-01-13 6:29 GMT+08:00 Rob Herring <robh at kernel.org>:
>>>> On Tue, Jan 12, 2016 at 7:05 AM, Chih-Wei Huang <cwhuang at android-x86.org> wrote:
>>>>> 2016-01-12 19:55 GMT+08:00 陈渝 <yuchen at mail.tsinghua.edu.cn>:
>>>>>> hi, Rob, Dave, Zhiwei:
>>>>>>  Thank you all!
>>>>>>
>>>>>> Next I need to update other parts should be in the user level.
>>>>>>
>>>>>> I need to update drm_gralloc? Do I need to update drm_hwcomposer or libdrm?
>>>>>> Are there any other things I need notice?
>>>>>
>>>>> libdrm in marshmallow-x86 is 2.4.66 which is newer enough
>>>>> to support it, I think.
>>>>>
>>>>> drm_hwcomposer is not been used in marshmallow-x86 yet.
>>>>> So don't worry about it.
>>>>>
>>>>> The keypoint is to implement the gralloc_drm_virgil3d.c.
>>>>> You may look at other gralloc_drm_*.c as examples.
>>>>
>>>> Nope, virgl is a pipe driver and support is already there for the most part.
>>>
>>> Rob, thank you very much for the input.
>>> It's the first time I heard the usage of
>>> AOSP's drm_gralloc & drm_hwcomposer from others.
>>> Great!
>>>
>>> Indeed we have tried to enable AOSP's drm_gralloc & drm_hwcomposer
>>> in the beginning of marshmallow-x86 porting but failed.
>>
>> How far did you get?
>>
>>> So we keep to use our implementation.
>>> (AOSP's drm_gralloc was forked from our lollipop-x86 branch
>>> since about Jan 2015)
>>>
>>> I'm excited to know you have succeeded to use them.
>>> Could you please guide us how to enable them correctly?
>>
>> Well, things are not completely working. I've got 1 device config
>> which can build for x86 or arm64 (any arch in theory) and runs on x86
>> KVM, Dragonboard 410c or arm64 QEMU. x86 KVM seems to work the best. I
>> can boot and navigate around a bit until it dies. There's at least 2
>> problems.
>>
>> After a little bit of navigating around I get errors like this from
>> virglrenderer:
>> vrend_set_single_sampler_view: context error reported 6
>> "ndroid.contacts" Illegal handle 112
>> vrend_set_single_sampler_view: context error reported 6
>> "ndroid.contacts" Illegal handle 113
>> vrend_set_single_sampler_view: context error reported 6
>> "ndroid.contacts" Illegal handle 114
>> vrend_set_single_sampler_view: context error reported 6
>> "ndroid.contacts" Illegal handle 115
>> vrend_set_single_sampler_view: context error reported 6
>> "ndroid.contacts" Illegal handle 116
>> vrend_set_single_sampler_view: context error reported 6
>> "ndroid.contacts" Illegal handle 117
>> vrend_set_single_sampler_view: context error reported 6
>> "ndroid.contacts" Illegal handle 118
>> vrend_set_framebuffer_state: context error reported 5
>> "ndroid.systemui" Illegal surface 63
>>
>> Usually the screen get flipped and drawn in about 1/4 of the original
>> screen size after these errors. I can capture a screenshot if
>> interested.
>
> I wonder a bit if refcnt'ing imbalance or something like that..
> accidentally free'ing the last reference to buffer, and then numeric
> handle getting re-used on a different unrelated buffer (for example)
> can cause all sorts of fun.

I've got freedreno mostly working now. I had missed one of the fixes
in your tree allowing prime_fd=0 to be valid. The good news is I don't
see this problem on freedreno, so it seems likely this problem is
specific to virtio-gpu. The question then is ref counting where? I
started with the host side as that is where the error messages come
from. I've added some debug to virglrenderer
vrend_object_insert/remove to try to trace the handles.

Here's a snippet around the error messages.

 create surface obj 1735
destroy sampler view obj 1727
destroy surface obj 1735
create sampler view obj 1736
create surface obj 158
unknown obj 154
vrend_set_framebuffer_state: context error reported 5
"ndroid.systemui" Illegal surface 155
vrend_set_single_sampler_view: context error reported 5
"ndroid.systemui" Illegal handle 156
vrend_set_single_sampler_view: context error reported 5
"ndroid.systemui" Illegal handle 157
create surface obj 1737
destroy sampler view obj 1732
destroy surface obj 1737
create surface obj 1738

The unknown obj is a failed handle lookup on the destroy call. I see
them occasionally in the log. Seems to me that should never happen.

Then much earlier in the log we do see the same handle numbers
destroyed and they are different object types:

create surface obj 154
destroy surface obj 154
create sampler view obj 155
create surface obj 51
destroy surface obj 50
create surface obj 156
destroy surface obj 156
create surface obj 157
destroy sampler view obj 155
destroy surface obj 153
create surface obj 158
destroy surface obj 158
create sampler view obj 159
create surface obj 52
destroy surface obj 51
create surface obj 160
destroy surface obj 160
create surface obj 161
destroy sampler view obj 159
destroy surface obj 157
create surface obj 162

I'll keep digging, but any suggestions on how to debug this more would
be helpful. I'm pretty much fumbling around in the dark.

Rob