979712 - hangs in gralloc_lock() during scrolling with new tiling

Status: NEW

(Core :: Graphics: Layers, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

I noticed this while scrolling: https://github.com/vvuk/gfxapp/blob/master/tests/virtual-list-demo-new.html

Not sure if it's a recent regression or not.

Comment 1

[Chris Lord [:cwiiis]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #0)
> I noticed this while scrolling:
> https://github.com/vvuk/gfxapp/blob/master/tests/virtual-list-demo-new.html
> 
> Not sure if it's a recent regression or not.

What device did you notice this on? While fine on buri and peak, it seems our locking code is not fine on Keon, for example. I added layers.overzealous-gralloc-unlocking that enables a hack that appears to work everywhere, but is sub-optimal. It'd be good if we could figure out a reliable, non-hacky solution though...

Comment 2

[Jeff Muizelaar [:jrmuizel]]

(In reply to Chris Lord [:cwiiis] from comment #1)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #0)
> > I noticed this while scrolling:
> > https://github.com/vvuk/gfxapp/blob/master/tests/virtual-list-demo-new.html
> > 
> > Not sure if it's a recent regression or not.
> 
> What device did you notice this on? While fine on buri and peak, it seems
> our locking code is not fine on Keon, for example. I added
> layers.overzealous-gralloc-unlocking that enables a hack that appears to
> work everywhere, but is sub-optimal. It'd be good if we could figure out a
> reliable, non-hacky solution though...

I saw this on a buri/hamachi

Comment 3

[Jeff Muizelaar [:jrmuizel]]

It's also worth noting that checkboarding seems worse on this page than with simple tiling.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I also get things like this:

E/libgenlock( 3242): perform_lock_unlock_operation: GENLOCK_IOC_DREADLOCK failed (lockType0x1, err=Connection timed out fd=47)
E/msm7627a.gralloc( 3242): gralloc_lock: genlock_lock_buffer (lockType=0x2) failed
W/GraphicBufferMapper( 3242): lock(...) failed -22 (Invalid argument)

Comment 5

[Andreas Gal :gal]

This is a locking problem. We are likely trying to take a read lock while holding a write lock. Can you add printfs around all the locking? (you won't see some of it since its in the driver). This absolutely explains performance problems since it will delay the compositor until the lock times out.

Comment 6

[Chris Lord [:cwiiis]]

Jeff confirmed on irc that this is 'fixed' by enabling layers.overzealous-gralloc-unlocking - I can't reproduce on my buri, so possibly this is driver-revision specific?

I can reproduce on Keon though, so I'm going to try a couple of things there. We at least have a work-around in the worst case (the aforementioned pref), but it'd be nice to not have to do that.

Comment 7

[Andreas Gal :gal]

What does overzealous-gralloc-unlocking do?

Comment 8

[Chris Lord [:cwiiis]]

(In reply to Andreas Gal :gal from comment #7)
> What does overzealous-gralloc-unlocking do?

Where as normally we'd let the upcoming buffer flip release the gralloc lock and delete any unused textures, overzealous mode deletes *any* gralloc-bound textures immediately at the end of the frame. (see CompositorOGLBackendSpecificData::EndFrame in CompositorOGL.cpp)

Comment 9

[Andreas Gal :gal]

Can you link? on what branch? This is not on central.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

http://hg.mozilla.org/users/bschouten_mozilla.com/tiling/

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Guessing this is a dupe of 984618 and all of its dupes...