ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Company has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: alyssa]
smiles has quit [Ping timeout: 480 seconds]
<airlied> yes only enabling it for gnome-shell because that is all I'm paid to care about
<DemiMarie> airlied: makes sense!
<DemiMarie> To rephrase my original question, is the Xe driver significantly simpler than the parts of i915 used when running on Xe architecture hardware? Simpler code generally has fewer vulnerabilities all else equal, and I have no reason to believe that the Xe driver will be of inferior quality once it does reach mainline.
<airlied> no it's just a different driver, without paying for an analysis there is no vector along which you could say it is "simpler
<airlied> "simpler"
<DemiMarie> ah
* DemiMarie wonders why Intel is paying for it
co1umbarius has joined #dri-devel
<airlied> because the current driver reached a level of unmaintainium
columbarius has quit [Ping timeout: 480 seconds]
<DemiMarie> Is drm_sched the current blocker?
<airlied> I think there's a todo list
<mareko> Marge for libdrm when?
<airlied> do we ever have enough conflicts to require marge?
yyds has joined #dri-devel
alyssa has joined #dri-devel
yuq825 has joined #dri-devel
<mareko> oh yeah I could use the merge button
smiles has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
yyds has quit []
camus has joined #dri-devel
ayaka_ has joined #dri-devel
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
crabbedhaloablut has joined #dri-devel
<YaLTeR[m]> <DemiMarie> "kchibisov: GTK3 used Cairo for..." <- Not sure if my messages come through here, but VTE (the terminal library) still uses cairo even on GTK 4 and has some questionable repaint logic on top, making it this slow
<kchibisov> YaLTeR[m]: the thing is that other gtk apps were not that much faster.
<kchibisov> But yeah, it depends on particular apps, I guess.
<karolherbst> anyway... it seems like even on 4k and iGPUs gtk4 apps aren't necessarily slower or less smooth... so I suspect the sw implementation is just bad or something?
<kchibisov> Could be something like that, pixman is ok on 4k from what I can tell.
<kchibisov> Though, I use A380, which is a bit faster igpu.
<karolherbst> forced sw rendering and it's not _that_ slow
<karolherbst> it's not smooth, but also good enough so it won't matter
<kchibisov> I just use bad gtk apps I guess.
<karolherbst> well.. it burns 5 of my 12 cores though
Mary has quit [Quit: The Lounge - https://thelounge.chat]
Mary has joined #dri-devel
<karolherbst> anyway... cpu rendering is going to be slow
<karolherbst> or maybe something else is going wrong
<karolherbst> maybe it's also a xorg vs wayland thing or something
<DemiMarie> karolherbst: I think the reason that almost nobody else worries as much as I do is because for the vast majority of systems it hardly matters
<DemiMarie> It’s only with the work on virtio-GPU native contexts that one can have GPU ioctls exposed to a VM for example. And that is not even merged upstream yet.
ayaka_ has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
bmodem has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
xzhan34 has joined #dri-devel
xzhan34 has quit []
Leopold_ has joined #dri-devel
xzhan34 has joined #dri-devel
fab has joined #dri-devel
itoral has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.0.4]
Duke`` has quit [Ping timeout: 480 seconds]
<YaLTeR[m]> Hi, so we're debugging the weirdest performance problem in Smithay involving overlay planes. It seems that on my RX 6700M laptop, AMDGPU is taking much longer to move an overlay plane to the right, compared to all other directions. Or something. Enough to start dropping frames left and right on a 165 Hz screen. Does this ring any bells?
<YaLTeR[m]> There's a kworker that runs after submitting a frame to KMS, and it just starts taking 10x more time when a plane is moving to the right
<YaLTeR[m]> The flamegraph shape for that kworker seems the same as normal, just takes longer
sima has joined #dri-devel
lemonzest has joined #dri-devel
ayaka_ has joined #dri-devel
fab has quit [Quit: fab]
mszyprow has joined #dri-devel
f11f12 has joined #dri-devel
An0num0us has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
JohnnyonFlame has quit [Remote host closed the connection]
fab has joined #dri-devel
tzimmermann has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
frieder has joined #dri-devel
<tzimmermann> airlied, hi. will there be another PR from drm-next to upstream before -rc1? i have a patch for a newly added bug in linus' tree
frankbinns has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
frankbinns1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
frankbinns has quit [Ping timeout: 480 seconds]
swalker_ has joined #dri-devel
swalker_ is now known as Guest1704
swalker__ has joined #dri-devel
junaid has joined #dri-devel
Guest1704 has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
mripard has joined #dri-devel
rasterman has joined #dri-devel
suja has joined #dri-devel
alkisg_irc has joined #dri-devel
alkisg_irc is now known as alkisg
junaid has quit [Remote host closed the connection]
<sima> tzimmermann, a -fixes pr in the 2nd week (or maybe two if there's something time critical) is the rule, first week of merge window is kinda like -rc0
<sima> since linus doesn't appreciate if you send big stuff in the 2nd week
bmodem has joined #dri-devel
<tzimmermann> sima, thanks
mchehab has joined #dri-devel
vliaskov has joined #dri-devel
jfalempe has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
suja has quit [Quit: Page closed]
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
Surkow|laptop has joined #dri-devel
flynnjiang has joined #dri-devel
mauld has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
Company has joined #dri-devel
kugel has quit [Remote host closed the connection]
kugel has joined #dri-devel
<airlied> tzimmermann: yes what sima said, thu/fri this week
donaldrobson has joined #dri-devel
<kode54> whoa
<kode54> that Z range limit env var
<kode54> I need to check if that fixes not just one, but two bugs
<kode54> if that fixes anything, does it mean that it ends up in a future copy of the default mesa compat config file?
pcercuei has joined #dri-devel
flynnjiang has quit [Quit: Leaving]
flynnjiang has joined #dri-devel
frieder has joined #dri-devel
alkisg has left #dri-devel [#dri-devel]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
tristan has joined #dri-devel
tristan is now known as Guest1715
ced117 has quit [Ping timeout: 480 seconds]
swalker__ has quit [Remote host closed the connection]
An0num0us has quit [Ping timeout: 480 seconds]
smiles has quit [Ping timeout: 480 seconds]
smiles has joined #dri-devel
Ahuj has joined #dri-devel
<karolherbst> DemiMarie: yeah.. but it also doesn't seem to be a huge issue. I mean, there are other projects/users hit by this as well. Whenever you have delayed upstreaming of acceleration support, e.g. nouveau generally doesn't have day 1 sipport for GPUs. In my experience all that software fallback stuff isn't all that bad. You still notice it, but I wouldn't say that it becomes really slow. On very old hardware it might with not powerful CPUs.
tristan__ has joined #dri-devel
Guest1715 has quit [Ping timeout: 480 seconds]
yyds has quit [Quit: Lost terminal]
yyds has joined #dri-devel
Omax has quit [Remote host closed the connection]
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
Omax has joined #dri-devel
flynnjiang has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
sebastiencs has quit [Quit: Ping timeout (120 seconds)]
samuelig has quit [Quit: Bye!]
samuelig has joined #dri-devel
sebastiencs has joined #dri-devel
sarahwalker has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
smiles has quit [Ping timeout: 480 seconds]
mripard has quit [Quit: mripard]
mripard has joined #dri-devel
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
tristan__ is now known as gtristan
ayaka_ has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
swalker_ has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
swalker_ is now known as Guest1723
junaid has joined #dri-devel
frankbinns1 is now known as frankbinns
<zmike> karolherbst: ok
<zmike> mareko: maybe once it's more robust
ced117 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
yyds has quit [Remote host closed the connection]
<alyssa> DavidHeidelberg[m]: !25030 should have been git pushed to main, not Marged, please
kts has quit [Ping timeout: 480 seconds]
<alyssa> otherwise it's just been extending the length of the outage by $LENGTH_OF_A_CI_RUN for no good reason
<alyssa> Perhaps we need explicit policy for this (trivial patches disabling dead farms / hardware due to unexpected outages/fails rather than planned maint, should be pushed rather than MR'd, at least if the person has been around Mesa enough to make that judgement call)
<alyssa> eric_engestrom: and I have talked about this... The benefits really do outweigh the drawbacks. It just needs to be written down somewhere. And followed.
<alyssa> This is the delay I mean in particular
<alyssa> If the "freedreno is dead MR" is instead git pushed, then there'd be no delay..
<alyssa> git pushing does shoot down a single MR's CI. but if that CI was going to fail anyway (due to running the dead job), this is a net positive.
<alyssa> [I realize that !25030 should have ordinarily been merged 20 minutes ago, and the only reason it hasn't is infra snafu that's causing the build jobs to timeout... but the point still stands. building mesa isn't instant.]
<ccr> Quantum Mesa not here yet?
<alyssa> ~that was a joke, ha ha, fat chance~
<DavidHeidelberg[m]> alyssa: why?
<dottedmag> DavidHeidelberg[m]: it was a reference to Portal's "Still Alive" song
<alyssa> correct
<alyssa> everyone before the last line was serious =)
bmodem has quit [Ping timeout: 480 seconds]
<alyssa> I see !25030 is now merged
<eric_engestrom> +1 to the exception "experienced devs can direct push for emergency-disable of a farm that's unexpectedly down"
<alyssa> which kinda just underscores my point
<alyssa> by going through Marge for this one, turned an outage of length N into an outage of length N + 1 hour
<alyssa> or at least, N + 40 minutes
<DavidHeidelberg[m]> dottedmag: I meant the alyssa mentioning git push X Marge
<alyssa> dottedmag: I think I did explain why?
<alyssa> DavidHeidelberg[m]: ^
<eric_engestrom> btw for the disable MR itself, I have a local change that is almost done to skip containers & builds, so that `sanity` is the only job that runs in farm-disable MRs
<alyssa> TL;DR Forcing farm disables through Marge artifically extends the length of outages, increasing developer unhappiness.
<alyssa> eric_engestrom: That would help! although it doesn't help the "force Marge to prioritize this MR" part
<eric_engestrom> yeah I definitely agree :)
<alyssa> and -- with my UX hat on rather than my dev hat on -- I don't see a reasonable way to teach Marge about priorities without it being abused
<alyssa> The obvious developer answer is "a magic CI EMERGENCY label that forces Marge to pick emergency MRs over all over MRs regardless of assigned time"
<alyssa> That has the extremely obvious UX problem that people will tag their broken driver patches with "CI EMERGENCY" on flaky CI days :~)
<zmike> if people abuse it then their developer access can be revoked
<zmike> not a hard problem to solve
<alyssa> Don't get me wrong.. I am - overall - in favour of good CI. I am very aware of the crap I & others try to merge ;)
itoral has quit [Remote host closed the connection]
<alyssa> The "unassign everything, then reassign" dance requires O(# of assigned MRs) human steps
<alyssa> which -- again from a UX standpoint -- is problematic given that -- on days with a CI outage -- that # is presumably higher on average due to people repeatedly reassigning MRs patiently trying to merge
gtristan has quit [Ping timeout: 480 seconds]
<alyssa> Possibly the UX answer would be a script that does the "disable given farm/job and git push" as a single atomic operation?
<alyssa> That hides the push, to prevent people from abusing it.
<alyssa> and can ensure the change is good and that somebody won't clumsily git push a typo in the .yml and end up making everything worse ;)
<alyssa> sounds like more engineering effort though..
<eric_engestrom> yeah a script for 3 commands (`git mv`, `git commit`, `git push`) seems a bit overkill :]
smiles has joined #dri-devel
<karolherbst> alyssa: could require certain people to ack such MRs, but yeah...
<alyssa> karolherbst: that moves the problem ... time spent waiting for an ack is time that ci is down for everybody
<karolherbst> like have a group of 10? devs and if one of them approve the MR in the GUI, the label takes effect
<karolherbst> but yeah...
<karolherbst> I don't think there will be a technical solution to the problem that devs might abuse that power
<karolherbst> we can only say: if you abuse it, your dev access gets removed
<eric_engestrom> yeah I agree with that
<eric_engestrom> basically "trust until there's a reason not to"
<eric_engestrom> since this is among a pool of people who have already gained enough trust to get there
<karolherbst> I think I see broken communication as the major reason it will cause issues, but...
<eric_engestrom> but I think direct push is much simpler than teaching Marge about some magic labels and such
<alyssa> eric_engestrom: karolherbst: my objection to a "CI Emergency" label is less about trust and more that its UX affordances are wrong... it's begging to be abused by well-meaning people who don't understand the finer points of policy
<eric_engestrom> true
f11f12 has quit [Quit: Leaving]
<alyssa> the concern is good faith actors who will erroneously use the escape hatch when it isn't warranted, at risk to others
<alyssa> not bad faith actors with merge access, they can already git push today
<karolherbst> that's what I meant with broken communication
<eric_engestrom> (the change for making farm-disabling MRs instant: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25032)
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
dviola has joined #dri-devel
<alyssa> eric_engestrom: nice!
smiles has quit []
<dj-death> anybody managed to compile mesa with tsan?
fab has quit [Quit: fab]
yuq825 has left #dri-devel [#dri-devel]
* alyssa tries to figure out how to model non-SM5 shifts in NIR nicely
<alyssa> Apparently it does matter for Dolphin fps.
fab has joined #dri-devel
<dj-death> -ltsan fixed it :)
greenjustin_ has joined #dri-devel
greenjustin has quit [Ping timeout: 480 seconds]
<dj-death> arg
<dj-death> looks like you can't post backtraces in the gitlab comments :(
<zmike> yup
Namarrgon has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
angerctl has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
Namarrgon has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos__ has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
frieder has quit [Remote host closed the connection]
pekkari has joined #dri-devel
mripard has quit [Remote host closed the connection]
kzd has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
tristan has joined #dri-devel
tristan is now known as Guest1741
junaid has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
pekkari has quit [Quit: Konversation terminated!]
Guest1723 has quit [Ping timeout: 480 seconds]
Guest1741 has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
i509vcb has joined #dri-devel
An0num0us has joined #dri-devel
<karolherbst> dj-death: you can't?
<karolherbst> not even if wrapped in a code block?
donaldrobson has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
crabbedhaloablut has quit []
alanc has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
alanc has joined #dri-devel
<dj-death> karolherbst: nope
<karolherbst> odd
<karolherbst> I'm sure I used to do that...
<airlied> yeah I thought the old ``` used to work
<karolherbst> dj-death: maybe some spam protection becuase there are a bunch of "references"
<karolherbst> but anyway.. this used to work
kts has joined #dri-devel
mszyprow has joined #dri-devel
crabbedhaloablut has joined #dri-devel
<dj-death> it used too indeed
<dj-death> not anymore
crabbedhaloablut has quit []
junaid has quit [Remote host closed the connection]
frankbinns1 has joined #dri-devel
invertedoftc09691 has joined #dri-devel
Emantor_ has joined #dri-devel
samuelig_ has joined #dri-devel
aleasto- has joined #dri-devel
evadot_ has joined #dri-devel
vyivel_ has joined #dri-devel
BobBeck9 has joined #dri-devel
larunbe has joined #dri-devel
nashpa has joined #dri-devel
rsalvaterra_ has joined #dri-devel
enunes- has joined #dri-devel
ifreund has quit [Remote host closed the connection]
rosefromthedead has quit [Remote host closed the connection]
ella-0 has quit [Remote host closed the connection]
kchibisov has quit [Read error: Connection reset by peer]
rpigott_ has quit [Write error: connection closed]
sumoon_ has quit [Write error: connection closed]
kennylevinsen has quit [Write error: connection closed]
aleasto has quit [Read error: Connection reset by peer]
rsalvaterra has quit [Read error: Connection reset by peer]
nuclearcat2 has quit [Read error: Connection reset by peer]
ndufresne has quit [Read error: Connection reset by peer]
dliviu has quit [Read error: Connection reset by peer]
Emantor has quit [Read error: Connection reset by peer]
moony has quit [Read error: Connection reset by peer]
vyivel has quit [Write error: connection closed]
shoragan has joined #dri-devel
jernej_ has joined #dri-devel
moony has joined #dri-devel
junaid has joined #dri-devel
robmur01 has quit [Read error: Connection reset by peer]
robmur01 has joined #dri-devel
evadot has quit [Read error: Connection reset by peer]
BobBeck has quit [Write error: connection closed]
fab has quit [Write error: connection closed]
Rayyan has quit [Write error: connection closed]
jani has quit [Remote host closed the connection]
samuelig has quit [Read error: Connection reset by peer]
invertedoftc0969 has quit [Write error: connection closed]
shoragan has quit [Write error: connection closed]
alarumbe has quit [Read error: No route to host]
kchibisov has joined #dri-devel
ella-0 has joined #dri-devel
ifreund has joined #dri-devel
rpigott has joined #dri-devel
Rayyan has joined #dri-devel
sumoon has joined #dri-devel
rosefromthedead has joined #dri-devel
kennylevinsen has joined #dri-devel
jani has joined #dri-devel
vyivel_ is now known as vyivel
nuclearcat2 has joined #dri-devel
enunes has quit [Remote host closed the connection]
ndufresne has joined #dri-devel
bbhtt- has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
bbhtt has quit [Ping timeout: 480 seconds]
jernej has quit [Ping timeout: 480 seconds]
rellla has quit [Remote host closed the connection]
jernej_ is now known as jernej
rellla has joined #dri-devel
ced117 has joined #dri-devel
An0num0us has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
youmukon1 has joined #dri-devel
youmukonpaku1337 has quit [Ping timeout: 480 seconds]
frankbinns1 has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
youmukon1 is now known as youmukonpaku1337
mszyprow has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
jewins has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
<alyssa> airlied: can you look at the llvmpipe fail on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24965 ?
<alyssa> can't tell if this is a preexisting llvmpipe bug being uncovered or a wacko perf regression or just CI bein' CI
<alyssa> either way hopefully it will make more sense to you
<zmike> hit retry and see if it's consistent
<zmike> I don't recognize it as a known issue though
glisse is now known as Guest1812
glisse has joined #dri-devel
mareko_ has joined #dri-devel
Guest1812 has quit [Ping timeout: 480 seconds]
mareko has quit [Ping timeout: 480 seconds]
dri-logg1r has quit [Ping timeout: 480 seconds]
dri-logger has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
<airlied> alyssa: I've seen a traces flake in the last few days
<airlied> so I suspect it's just a infra or llvmpipe slowdown change
<airlied> might want to drop those two traces
<alyssa> ok
<alyssa> it's entirely possible that my patch goes a slow down, though
dottedmag has quit [Quit: QUIT]
exp80 has quit [Read error: Connection reset by peer]
kbingham has quit [Remote host closed the connection]
kbingham has joined #dri-devel
dottedmag has joined #dri-devel
exp80 has joined #dri-devel
<alyssa> otoh.. not super likely either without second order effects
<alyssa> the timeouts do seem to be repeateable https://gitlab.freedesktop.org/mesa/mesa/-/jobs/48512211
<alyssa> I dont know what to make of that
<alyssa> It's not a particularly spicy patch
<alyssa> (now it's 3 traces..)
alyssa has quit [Quit: alyssa]
<zmike> it's a shame trace jobs don't have per-trace timing info more readily available
<zmike> koike: ^maybe another thing for the dashboard, visualizing trace runtimes to track which ones are timing out or near to timing out
alyssa has joined #dri-devel
<alyssa> what really gets me is that it's a different set of traces timing out
<alyssa> at least 4 different llvmpipe-traces timing out across different pipelines for that commit
<zmike> cpu jobs don't have dedicated runners, so all that means is the cpus are under load
<alyssa> right..
<alyssa> I genuinely don't know if this is something wrong with my patch or not
<alyssa> maybe it's causing spilling
alyssa has quit []
<zmike> have you tried running the traces locally
<zmike> should be easy to time them before/after to evaluate
alyssa has joined #dri-devel
<alyssa> fine i'll delete more code
<airlied> yeah I doubt it gets any slower really
<alyssa> If it's spiking register pressure => increasing spilling => LLVM path of doom? could be
<zmike> it could be hitting one of those forever llvm optimizer loops
<alyssa> i sure do love llvm
<zmike> though you'd need to be testing on the same version as ci (14?) to know
* alyssa reconsiders her plan to make llvm a mandatory part of the mesa build process
pcercuei has quit [Quit: dodo]
* alyssa pushed a change that should avoid reg pressure regression, hopefully that fixes llvmpipe
<psykose> love the smell of blown registers in the morning
<alyssa> well, llvmpipe-traces passed this time
<alyssa> so yeah guess it was blowing up reg pressure
<alyssa> congratulations llvmpipe, this is the first time in my memory a -traces job uniquely caught a bug in my code
<alyssa> nice
<alyssa> (I mean, it did it in a ludicrously roundabout way, but,)
<zmike> we did it team
<zmike> handshakes all around
<alyssa> (mind you, it was also not caught by any of the mechanisms -traces was designed around...)
<zmike> successful completion is one of the core competencies of a trace job
* zmike ticks off a buzzword from his yearly chart
mareko_ has quit [Ping timeout: 480 seconds]
dri-logger has quit [Ping timeout: 480 seconds]
glisse has quit [Ping timeout: 480 seconds]
dri-logger has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
<psykose> what's next on the chart
mareko has joined #dri-devel
<zmike> cybersecurity mesh 🤕
glisse has joined #dri-devel
ced117 has joined #dri-devel