[RFC][PATCH 4/4 v2] drm_hwcomposer: Try to fallback if GLCompisition fails

[John Stultz]

On Tue, Feb 13, 2018 at 2:03 PM, John Stultz <john.stultz at linaro.org> wrote:
> On Tue, Feb 13, 2018 at 2:45 AM, Alexandru-Cosmin Gheorghe
> <Alexandru-Cosmin.Gheorghe at arm.com> wrote:
>> On Mon, Feb 12, 2018 at 08:43:10PM -0800, John Stultz wrote:
>>> On Wed, Jan 31, 2018 at 11:03 AM, John Stultz <john.stultz at linaro.org> wrote:
>>> > On Wed, Jan 31, 2018 at 10:51 AM, Alexandru-Cosmin Gheorghe
>>> > <Alexandru-Cosmin.Gheorghe at arm.com> wrote:
>>> >> It seems that we don't pass any explicit fences to the kernel for
>>> >> IN_FENCE_FD property. This particular line seems wrong.
>>> >>
>>> >> @@ -593,14 +594,17 @@ int
>>> >> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>>> >>        else
>>> >>          rotation |= DRM_MODE_ROTATE_0;
>>> >>
>>> >> -      if (fence_fd < 0) {
>>> >> +      if (fence_fd >= 0) {
>>> >
>>> > I'll give that a whirl.
>>>
>>> So I did give that a whirl after you suggested it, but it ended up
>>> causing nothing to be displayed, and I unfortunately didn't have time
>>> right then to dig much further.
>>>
>>> Rob however re-found this issue today, and I've been digging a bit
>>> more. At least with the HiKey board, it seem the trouble is when the
>>> IN_FENCE_FD is added to the pset, the atomic commit calls start to
>>> fail. I dug in and it seems we're catching in the kernel on the  if
>>> (file->f_op != &sync_file_fops) check in sync_file_fdget().
>>>
>>> I'm now trying to trace back to where the in fence was provided from
>>> to see what might be going wrong there.
>> I would be surprised if this fence is not created by the GPU driver.
>> But, the whole Android stack is new to me, so I might be wrong.
>
> Yes, I went digging on this last night and it ends up the utgard
> driver we use (r7p0) isn't giving us a dmabuf fence, instead we're
> getting a mali_sync_fence.
>
> There's a newer kernel driver release (r8p1), which seems to correct
> this, but it also is version tied to the binary blob, which I don't
> have a matching update for. I spent a bit of time trying to hack out
> just the dmabuf fence bits, but it rarely boots all the way and
> frequently locks the board up, so I'm probably mucking the library
> driver interface in some way.
>
> Its a well known sad song.

So, I took another stab at this tonight and actually got the dmabuf
fence handling transplanted into the older r7p0 driver we're using. So
with that and the recent fence_fd bug that has been fixed in master,
things are working *much* better. No gl_finsh() hacks needed to avoid
tearing and performance is improved nicely.

thanks
-john