00:00 <avaf> hi

00:03 <avaf> I am trying to run Kodi but it crashes. Do i need any patch to be applied in order to build Kodi?

00:05 <avaf> kmscube run fine on my setup. RK3399 with GBM

00:36 <avaf> alyssa: can you give some advice on these? Anything special to build kodi with panfrost?

10:10 <HdkR> Nice, T720 whitelisting

10:16 <tomeu> \o/

10:18 <dhewg> woot!

10:19 <dhewg> so you got your T720s set up for CI?

10:38 <bbrezillon> tomeu, robher: I think panfrost_ioctl_madvise() is racy

10:39 <bbrezillon> if you have 2 threads calling this ioctl on the same handle with different MADV vals, you're not guaranteed that the BO will be queued/dequeued as expected

10:41 <bbrezillon> taking the shrinker lock before the drm_gem_shmem_madvise() should solve that

11:09 <tomeu> bbrezillon: ooc: have you seen this in real life?

11:10 <bbrezillon> tomeu: nope, I was chasing another race and noticed that one

11:10 <bbrezillon> but it's still racy

11:10 <tomeu> sure, just curious

11:10 <bbrezillon> I thing I figured out the pagefaults we had on T760

11:11 <bbrezillon> I wonder how it could work on T860

11:11 <bbrezillon> and the mesa BO cache did great in hiding the problem :)

11:11 <bbrezillon> tomeu: GPU mappings are teared down when the GEM handle is closed

11:12 <bbrezillon> but the GPU might be using those BOs

11:12 <bbrezillon> *might still be

11:12 <bbrezillon> if you keep BOs around in the mesa cache you won't notice the problem

11:12 <tomeu> right

11:13 <bbrezillon> but as soon as you disable the cache, it's the pagefault party

11:13 <tomeu> sounds like the kind of stuff we should be testing in igt :/

11:13 <bbrezillon> same kind of issues with the shrinker

11:14 <tomeu> evil cache papering bugs over

11:14 <bbrezillon> it might start reclaiming BOs that are still used

11:14 <bbrezillon> (by the GPU)

11:17 <tomeu> narmstrong: I'm really curious about https://gitlab.freedesktop.org/narmstrong/mesa/-/jobs/1032914 :)

11:33 <warpme_> team: FYI: finally we (mythtv team) got nicely working s905 video hw decode via v4l2 m2m with EGL_LINUX_DMA_BUF_EXT rendering on current panforst. 1080i playback CPU load is approx 5% so this is fantastic result. All team (especially Maxime, Neil, at all) - You done miracles here. (FYI: my s912 beelink box is practically fully usable mythtv appliance. All works: audio, USB, IR remote). As minimyth2 is zero-touch

11:33 <warpme_> provisioning appliance - i'm almost with target where: user can just get tvbox, plug SD card, power and enjoy mythtv world). Dears: million thx for Yours work!

11:34 <narmstrong> \o/

11:34 <narmstrong> warpme_: with my last vdec serie ?

11:35 <warpme_> ehh: I typed "especially Maxime, Neil, at all". Geez: copy-paste thing :( I was meant Alyssa et.all of course. SSSOOORRYY for that!

11:35 <warpme_> narmstrong: yes sir!

11:36 <narmstrong> warpme_: are you using ffmpeg as backend for mythtv ?

11:37 <warpme_> yes. this is a bit modified copy (for CC support in TV recordings etc).

11:50 <tomeu> narmstrong: running this in a branch of me with two fixups: https://gitlab.freedesktop.org/tomeu/mesa/pipelines/83672

12:14 <daniels> warpme_: woohoo :D

12:28 <tomeu> narmstrong: https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/1033494 :)

12:28 <tomeu> only 5k tests to fix :)

12:38 <narmstrong> Hmmm yeah

12:55 <bbrezillon> tomeu, robher: do we have some guarantee that panfrost_file_priv will live longer that the BOs attached to it?

13:11 <bbrezillon> actually, I'm not sure the panfrost implementation is safe for globally visible GEMs (GEM_OPEN) where the same drm_gem_object can be shared by different FDs (drm_file/panfrost_file_priv)

13:12 <tomeu> narmstrong: if you know of someone who would like to get the readpixels req test fixed on t820, I can give support

13:16 <narmstrong> nobody is specifically interested yet, but maybe @lvrp16 soon will be

13:31 <alyssa> Nothing like not being able to access a web browser because mesa is recompiling and the old version is broken

13:31 <alyssa> #justgfxdevthings

13:31 <alyssa> warpme_: Glad to see things are coming together for you :)

13:33 <urjaman> i've set up to have one mesa build (different prefixes and ld.so.conf) for Xorg and an another one i LD_LIBRARY_PATH apps with for testing mesa ...

13:34 <urjaman> also yeah finally decided to use a prefix other than /usr for the backup/Xorg mesa so it's not fighting with the package manager :)

13:38 <alyssa> urjaman: Sadly sometimes I'm debuggin xorg ;)

13:46 <alyssa> tomeu: Ohhhhhh

13:46 <alyssa> I think the clamps are supposed to work like

13:46 <alyssa> MAX2(MIN2(best_w, ALIGN_POT(width)), 8)

13:46 <alyssa> I.e.

13:47 <alyssa> "the tile size should be no larger than the framebuffer, unless the framebuffer is like 4 pixels in which case it should just default to 8x8"

13:47 <alyssa> Could you try doing that for panfrost_choose_tile_size?

13:48 <alyssa> It shouldn't affect the results, but it should make the code a lot more uniform / eliminates special cases.

13:52 <tomeu> alyssa: you meant something like this? http://paste.debian.net/1118381/

13:54 <urjaman> alyssa: yeah i had a plan to make an ld.so.conf-manipulating script for testing Xorg with the other mesa and then restoring the "stable" configuration but hadnt done that yet

13:55 <urjaman> ... i got a bit interrupted by life :/

13:58 <alyssa> tomeu: yes, but you do *also* need the (1 << (util_logbase2_ceil(height) - 7) clamp, I think

13:59 <alyssa> Also, I now notice that (util_logbase2_ceil(height) - 7) may be negative

13:59 <alyssa> in which case you invoke undefined behaviour in the shift

14:00 <alyssa> so that shift should be clamped positive (MAX2(, 0))

14:01 <robmur01> 8x8 wut?

14:01 <robmur01> https://static.docs.arm.com/101897/0200/arm_mali_gpu_best_practices_developer_guide_101897_0200_00_en.pdf

14:02 <robmur01> tiles are 16x16 ;)

14:02 <alyssa> robmur01: yeah well it makes the code work :^)

20:26 <bbrezillon> robmur01: this branch seems to fix the pagefaults on T760 => https://github.com/bbrezillon/linux/commits/panfrost/5.4-fixes

20:26 <bbrezillon> need to refine the last commit

20:28 <daniels> don't change the commit message, it's perfect as is

20:44 <anarsoul> :)

21:11 <bbrezillon> daniels: I didn't intend to change that part of the commit :)

22:18 <urjaman> oooh interesting (gotta give this a spin on top of my 5.4)

22:41 <alyssa> bbrezillon: FWIW, generally `base` fields should always be first

22:42 <alyssa> That goes everywhere in mesa (gallium anyway)

23:53 <urjaman> bbrezillon: this is nice o/

23:57 <urjaman> changing the size of a video (or using the firefox url suggestion bar thingy) is no longer a scary situation that could lead to a fault-loop-for-a-while :P