<anarsoul|2>
Viciouss: you should probably be asking android devs what's going on here :)
<anarsoul|2>
I've no idea how android interacts with display card and render card, so I guess you should check whether it matches whatever regular linux userspace does
<anarsoul|2>
i.e. kmscube/x11/weston
<Viciouss>
going though the kmscube sources is on my todo list because it worked just fine
<anarsoul|2>
I think only MoeIcenowy tried android on lima here
mripard has quit [Ping timeout: 265 seconds]
mripard has joined #lima
buzzmarshall has quit [Remote host closed the connection]
<marex-cloud>
anarsoul|2: shouldn't that drm scheduler crash fix be backported to 5.4 for lts?
<marex-cloud>
Or is that too complex?
<anarsoul|2>
marex-cloud: I'm actually not sure what patches fixed the issue
<marex-cloud>
Oh
<marex-cloud>
I guess git log might help there
<anarsoul|2>
'git log drivers/gpu/drm' is quite massive
<MoeIcenowy>
anarsoul|2 : I backported it
<anarsoul|c>
MoeIcenowy: have you sent it to stable@ ?
<Marex>
MoeIcenowy: thank you :)
Barada has joined #lima
camus1 has joined #lima
kaspter has quit [Ping timeout: 265 seconds]
camus1 is now known as kaspter
<MoeIcenowy>
anarsoul|2: no
Elpaulo has quit [Read error: Connection reset by peer]
kaspter has quit [Ping timeout: 265 seconds]
Elpaulo has joined #lima
kaspter has joined #lima
<anarsoul|2>
rellla: for !4126 only last 2 commits need to be reviewed. First 4 are from different MR (!4125)
<anarsoul|2>
so don't get scared, last 2 commits are trivial :)
<rellla>
anarsoul|2: but we need to get the first one's reviewed, too :)
<anarsoul|2>
yeah, but I can rebase 4126 onto master
<anarsoul|2>
technically most of 4125 aren't mine commits and I already reviewed it
<anarsoul|2>
but I'll wait for someone to look into it once again
monstr has joined #lima
<anarsoul|2>
btw better ftrunc lowering fixed int tests only by accident. We likely still have a bug somewhere in GP compiler
_whitelogger has joined #lima
dddddd has quit [Ping timeout: 265 seconds]
yann has quit [Ping timeout: 268 seconds]
<cwabbott>
anarsoul|2: I've been working on infinite loop stuff on and off, after looking at some regressions in my optimization series, and it's really tricky
<cwabbott>
if you read the comments at the beginning, there's a proof that the algorithm will always converge, but I realized that there's a gap
<cwabbott>
I proved that it's always possible to schedule the first node on the ready list by spilling things, but the current algorithm doesn't guarantee that this always leads to an original (not-scheduler-created) node being scheduled eventually
<cwabbott>
so there are various ways that we can get stuck in a loop spilling and unspilling things without getting anywhere
<cwabbott>
I think it's possible to modify the ready list priority and the code that chooses what to spill so that it always terminates, but it's hard coming up with the right order so that the proof goes through
<cwabbott>
of course you can always hack it to fix individual cases, but I'd like that we have a good solid reason that it *should* always work
<cwabbott>
anarsoul|2: I think I see what's going on in nir_convert_from_ssa... in your example it created a temp reg r7 to implement a cycle (r0 -> r3 -> r2 -> r1 -> r0) in block_4
<cwabbott>
but really this should be an SSA value
<cwabbott>
it's just that no one else really relied on it being one
<cwabbott>
if you search for copy_temp in nir_convert_from_ssa you should find the code that does this