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

[Rob Clark]

On Fri, Jan 15, 2016 at 12:50 PM, Rob Herring <robh at kernel.org> wrote:
> 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.

well, nothing specific, but for example early on we had some confusion
in drm_gralloc (when adding dmabuf fd support) about who close()d the
fd's.  Resulting in same fd getting closed twice (although some
completely unrelated file handle might have snuck into that slot
between the two close()s).

Or you could end up w/ the same sort of thing for gem handles (which
are unique to the drm device fd, so if you open() the device multiple
times..).  I did initially have some confusion about this, w/ multiple
fd_bo's (or pipe_resource's) being created for a given gem handle, and
first one that gets deleted takes away the backing store that both
userspace references where using.

You might want to look at freedreno_drm_winsys.c and the crazy things
it does..  I suspect virgl might need similar hacks.  That is really
one part of two, that ensures that we share the same pipe_screen, and
therefore (from libdrm) fd_device, for a given drm device fd.  The
other part is that fd_device has hashtables to deal w/ double import
of gem buffers.

BR,
-R

> 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