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?
<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
<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>
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