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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 24, 2018 at 7:26 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> 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?  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).

Thanks again for your review feedback!

thanks
-john
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux