00:54 <alyssa> greenjustin: a chromeos kernel? why?

09:56 <robmur01> in my experience, X's pretence of auto-detecting is a complete lie and it still needs manually configuring to use anything other than card0 as the modesetting device

09:56 <robmur01> that confused and frustrated me for a very long time

09:57 <robmur01> (also it didn't like /dev/dri/by-path/... entries which is a pain if your devices tend to probe in random order)

10:00 <CounterPillow> lovely

14:30 <greenjustin> alyssa: Not a chromeos kernel, at least I don't think. I'm using that mt8195-tracking-master-rolling branch.

14:38 <greenjustin> One of the main blockers for ChromeOS adoption of panfrost is a possible GL bug that the chrome compositor triggers. I finally have some time, so I'm trying to see if I can repro on upstream :-)

15:28 <greenjustin> robmur01: I think with vgem disabled, card0 actually is the display controller

15:36 <daniels> greenjustin: card1 actually is the display controller

15:36 <daniels> I mean, it depends on bind order right

15:36 <daniels> greenjustin: also Wayland compositors are much better tested on Panfrost than raw X11, so I would very much recommend doing that instead

15:36 <daniels> (X11 clients are still supported via Xwayland0

15:40 <greenjustin> daniels: I'm fairly certain it's card0 based on these Xorg logs, but I take your point about Wayland. Guess it's time for me to make the switch

15:57 <alyssa> greenjustin: Ah, gotcha

16:00 <greenjustin> I realized I've been using the same XFCE/X11 install on my personal computers for like a decade now, I dunno why it never occurred to me that most distros would've switched to Wayland by this point... X11 was ancient even back then

17:04 <greenjustin> Wow, yeah going the wayland route was a ton easier. Works flawlessly, and the performance seems pretty good. Thanks everyone!

18:00 <alyssa> Giggle

18:14 <greenjustin> In fact, it works a little too well. Can't repro my bug :-(

18:14 <alyssa> Oops? o:)

18:22 <ente`> classic bug

18:43 <anarsoul> heisenbug

18:53 <greenjustin> Kinda, except I must've changed about a bazillion variables :-P

18:54 <greenjustin> Just wish I knew which ones in particular were worth exploring...

20:57 <alyssa> What is the bug anyway?

21:05 <daniels> greenjustin: ha! glad to hear! :)

21:07 <greenjustin> alyssa: During my chromeos with panfrost tests, I get some really weird glitchiness where it looks like the last couple of frame buffers are being replayed in a loop. It doesn't repro with e.g. WebGL applications, but even just scrolling on a web page or typing in the omnibar looks very janky

21:08 <greenjustin> I probably have a video somewhere around here...

21:11 <anholt> hmm. kinda surprised that chromeos doesn't require fence fd support. would have expected it to. perhaps it doesn't check? https://gitlab.freedesktop.org/mesa/mesa/-/issues/6502

21:11 <anholt> (android would need it for sure)

21:24 <greenjustin> anholt: Forgive me, I'm still not entirely sure what that means. Does this have something to do with memory coherence?

21:47 <greenjustin> Found it! My apologies for the potato quality: https://drive.google.com/file/d/1FxnCU-6VDaXbDj2wFVMjp-50mPD-nDVj/view?usp=sharing

23:22 <anholt> greenjustin: so, there's protocol used in compositors (android surfaceflinger, I would have expected chrome as well) where you tell the client that they can render to the window system buffer you're finishing up with, but only after a given fence has passed. the ext lets you attach the fence to GPU rendering, and it feeds right into the kernel's gpu job scheduler. no CPU side stalls. but, if chrome was trying to have its client

23:22 <anholt> rendering use those fences, but the fences were getting ignored (because the ext wasn't actually available), you'd get all sorts of weird flickery rendering with the wrong scenes showing up.

23:23 <anholt> but this is just a hunch.