Re: [BUG 4.17] etnaviv-gpu f1840000.gpu: recover hung GPU!

[Russell King - ARM Linux <linux@armlinux.org.uk>]

On Tue, Jun 19, 2018 at 01:11:29PM +0200, Lucas Stach wrote:
> Am Dienstag, den 19.06.2018, 12:00 +0100 schrieb Russell King - ARM Linux:
> > No, it's not "a really big job" - it's just that the Dove GC600 is not
> > fast enough to complete _two_ 1080p sized GPU operations within 500ms.
> > The preceeding job contained two blits - one of them a non-alphablend
> > copy of:
> > 
> >                 00180000 04200780  0,24,1920,1056 -> 0,24,1920,1056
> > 
> > and one an alpha blended copy of:
> > 
> >                 00000000 04380780  0,0,1920,1080 -> 0,0,1920,1080
> > 
> > This is (iirc) something I already fixed with the addition of the
> > progress detection back before etnaviv was merged into the mainline
> > kernel.
> 
> I hadn't expected it to be this slow. I see that we might need to bring
> back the progress detection to fix the userspace regression, but I'm
> not fond of this, as it might lead to really bad QoS.

Well, the choices are that or worse overall performance through having
to ignore the GPU entirely.

> I would prefer userspace tracking the size of the blits and flushing
> the cmdstream at an appropriate time, so we don't end up with really
> long running jobs, but I'm not sure if this would be acceptable to
> you...

The question becomes how to split up two operations.  Yes, we could
submit them individually, but if they're together taking in excess of
500ms, then it's likely that individually, each operation will take in
excess of 250ms which is still a long time.

In any case, I think we need to fix this for 4.17-stable and then try
to work (a) which operations are taking a long time, and (b) how to
solve this issue.

Do we have any way to track how long each submitted job has actually
taken on the GPU?  (Eg, by recording the times that we receive the
events?)  It wouldn't be very accurate for small jobs, but given this
operation is taking so long, it would give an indication of how long
this operation is actually taking.  etnaviv doesn't appear to have
any tracepoints, which would've been ideal for that.  Maybe this is
a reason to add some? ;)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel