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

[Alexandru-Cosmin Gheorghe]

Hi John,

I took your patches for a spin on Hikey960. Some findings:
Even with this patch I'm getting some tearing on Hikey960, not a lot as you
reported on Hikey, still there are some small black squares, less than 10 of
aproximetly 20x20.
So I investigated a little bit through drm_hwcomposer and found some
issues, maybe they could help you somehow, see bellow:
 Wed, Jan 24, 2018 at 01:58:55PM -0600, Rob Herring wrote:
> On Wed, Jan 24, 2018 at 1:26 PM, John Stultz <john.stultz at linaro.org> wrote:
> > On Wed, Jan 24, 2018 at 7:26 AM, Sean Paul <seanpaul at chromium.org> wrote:
> >> On Tue, Jan 23, 2018 at 03:16:39PM -0800, John Stultz wrote:
> >>> When using drm_hwcomposer with the hikey board, the resulting
> >>> display shows lots of tearing.
> >>>
> >>> This seems to be due to EGLcomposition not initializing
> >>> properly, potentially due to I'm guessing limitations of what
> >>> the  utgard mali driver can do. I've noted that with the
> >>> HiKey960 board, this patch is *not* necessary.
> >>>


> >>> Hacking around a bit, I found that since the glworker code
> >>> isn't running properly, we never call glFinish(), which
> >>> is required to fix the tearing.
> >>>
> >>> Ideas for a better way to implement this would be greatly
> >>> appreciated!
> >>
> >> Sounds like you'll have to dig into the gl compositor to fix this. I think
> >> chances are quite good there's a better way than below.
> >
> > Yes, I did spent a little bit of time earlier trying to rewrite the gl
> > shader to try to build for the utgard level hardware, but wasn't very
> > successful. At a deeper level I guess I'm not sure the glcompositor is
> > useful in this case, since we're doing single plane client side
> > compositing (as short of the glFinish bit, not running it doesn't seem
> > to keep things from working).  But I'll look into that again.
> >
> > Again forgive as I really a bit in the dark on most graphics details,
> > but the other more basic question I'm a bit unsure of is, does this
> > patch even make any functional sense?
>
> I'd think not. The only thing that makes me question that is I've seen
> glFinish calls in gralloc (framebuffer) cases. But those cases were
> prior to explicit fence support.
>
> >  If we're not using the
> > glcompositor and are using the atomic commit in ApplyFrame(), why the
> > need for glFinish to avoid tearing?  Is it that the we commit the
> > frame atomically to the display, but if we don't block w/ glFinish()
> > the gpu is still drawing into it?  It seems we'd want a buffer
> > specific fence to wait on rather then waiting for all gl calls to
> > complete (if I'm understanding how glFinish() works).
>
> That seems like the right approach. Are we failing to pass fences
> associated with input layers to DRM?
>
> Rob
> _______________________________________________
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) {

Also, if you track the value of the OUT_FENCE_PTR property, it seems
that it gets lost. As far I was able to track it down it seem that
it should have been used by AddFenceToRetireFence, and then be passed to
SurfaceFlinger through retire_fence parameter of PresentDisplay. But,
that doesn't happen because  AddFenceToRetireFence get's called each
time on a new DrmDisplayComposition object, before calling
ApplyComposition.


Both of this findings should have explained the tearing, however I
hacked something today and it didn't fix it for Hikey960, maybe
you have more luck.

Thank you,
Alex Gheorghe


> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.