On Tue, Feb 13, 2018 at 2:03 PM, John Stultz john.stultz@linaro.org wrote:
On Tue, Feb 13, 2018 at 2:45 AM, Alexandru-Cosmin Gheorghe Alexandru-Cosmin.Gheorghe@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@linaro.org wrote:
On Wed, Jan 31, 2018 at 10:51 AM, Alexandru-Cosmin Gheorghe Alexandru-Cosmin.Gheorghe@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