ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs - <macc24> i have been here before it was popular
bbrezillon has quit [Ping timeout: 480 seconds]
bbrezillon has joined #panfrost
<alyssa> greenjustin: a chromeos kernel? why?
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #panfrost
floof58 is now known as Guest3894
floof58 has joined #panfrost
Guest3894 has quit [Ping timeout: 480 seconds]
davidlt has joined #panfrost
rasterman has joined #panfrost
chipxxx has quit [Read error: Connection reset by peer]
chipxxx has joined #panfrost
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #panfrost
web-41 has joined #panfrost
web-41 has left #panfrost [#panfrost]
<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
<robmur01> that confused and frustrated me for a very long time
<robmur01> (also it didn't like /dev/dri/by-path/... entries which is a pain if your devices tend to probe in random order)
<CounterPillow> lovely
chipxxx has quit [Remote host closed the connection]
alarumbe has joined #panfrost
<greenjustin> alyssa: Not a chromeos kernel, at least I don't think. I'm using that mt8195-tracking-master-rolling branch.
<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 :-)
guillaume_g has quit []
<greenjustin> robmur01: I think with vgem disabled, card0 actually is the display controller
<daniels> greenjustin: card1 actually is the display controller
<daniels> I mean, it depends on bind order right
<daniels> greenjustin: also Wayland compositors are much better tested on Panfrost than raw X11, so I would very much recommend doing that instead
<daniels> (X11 clients are still supported via Xwayland0
<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
<alyssa> greenjustin: Ah, gotcha
<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
rtp_ is now known as rtp
hanetzer has quit [Quit: WeeChat 3.6]
Daanct12 is now known as Danct12
<greenjustin> Wow, yeah going the wayland route was a ton easier. Works flawlessly, and the performance seems pretty good. Thanks everyone!
<alyssa> Giggle
<greenjustin> In fact, it works a little too well. Can't repro my bug :-(
<alyssa> Oops? o:)
<ente`> classic bug
<anarsoul> heisenbug
<greenjustin> Kinda, except I must've changed about a bazillion variables :-P
<greenjustin> Just wish I knew which ones in particular were worth exploring...
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #panfrost
davidlt has quit [Ping timeout: 480 seconds]
indy has quit []
indy has joined #panfrost
<alyssa> What is the bug anyway?
mmind00 has quit [Remote host closed the connection]
mmind00 has joined #panfrost
<daniels> greenjustin: ha! glad to hear! :)
<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
<greenjustin> I probably have a video somewhere around here...
<anholt> hmm. kinda surprised that chromeos doesn't require fence fd support. would have expected it to. perhaps it doesn't check?
<anholt> (android would need it for sure)
<greenjustin> anholt: Forgive me, I'm still not entirely sure what that means. Does this have something to do with memory coherence?
falk689_ has joined #panfrost
falk689 has quit [Ping timeout: 480 seconds]
<greenjustin> Found it! My apologies for the potato quality:
rasterman has quit [Quit: Gettin' stinky!]
CME_ has joined #panfrost
CME has quit [Ping timeout: 480 seconds]
warpme___ has quit []
falk689_ has quit [Remote host closed the connection]
falk689 has joined #panfrost
anarsoul has quit [Quit: ZNC 1.8.2 -]
anarsoul has joined #panfrost
greenjustin has quit [Read error: Connection reset by peer]
<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
<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.
<anholt> but this is just a hunch.
karolherbst is now known as karolherbst_
karolherbst_ is now known as karolherbst
bbrezillon has quit [Ping timeout: 480 seconds]
bbrezillon has joined #panfrost