<thellstrom>
Yup. I reverted Imres manual fixup which was after the merge of xe-for-CI and instead placed it after the merge of drm-next...
flynnjiang has quit [Remote host closed the connection]
<thellstrom>
So the drm-rerere commit supposed to fix this is 3c92d77045fa9e736cb72bc88b9acdcf1cdc507d
flynnjiang has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
<sima>
thellstrom, hm yeah I have that, maybe git just got confused because the context changed
warpme has joined #dri-devel
<sima>
I had to redo a different xe conflict in drm-tip too after I merged the latest drm-xe-next from rodrigovivi
<sima>
git rerere isn't super smart, and sometimes even incompatible between different git versions
flynnjiang has joined #dri-devel
<sima>
but it's been a while I've seen one of those
daemondragon has joined #dri-devel
<thellstrom>
Hm. Yes, I thought even weirder was how that line got added anyway. It's neither in the merge source nor destination and the result of of an automatic merge..
phire has quit [Read error: Connection reset by peer]
glennk has quit [Ping timeout: 480 seconds]
<sima>
thellstrom, we have rerere enabled, so you need to nuke the wrong stored conflict resolution
<sima>
deleting the fixup alone won't be enough if the issue is in the rerere side
<sima>
so the issue might predate imre's rerere commit, and imre just tried to patch it up with a fixup
<sima>
instead of deleting the root cause
<sima>
and you deleting the fixup means it pops back up
<thellstrom>
Well the fixup wasn't actually deleted but rather moved to where it surfaces. But IIRC I at some point added a conflict resolution to add such a line in an unrelated place so I may have to dig a bit deeper.
<sima>
thellstrom, well I deleted the fixup since it's baked in now
daemondragon has quit [Remote host closed the connection]
daemondragon has joined #dri-devel
phire has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
bmodem has joined #dri-devel
phire has quit [Remote host closed the connection]
<sima>
robclark, bbd9d05618a6d608c72640b1d3d651a75913456a stumbled over this one and it's kinda ... ugh how that went in
<sima>
robclark, if cros/android really wants to push that I think we need to have some uapi docs for it to make it a proper stable tracepoint, like what pepp is doing
<sima>
and maybe more than one driver supporting it 4 years later :-/
<imre>
thellstrom, sima, ftr: the wrong merge result came about already before my 'dim push', see the earlier https://lore.kernel.org/all/20240628085457.21929-1-nirmoy.das@intel.com . After the push and noticing the build failure in drm-tip I also checked drm-rerere/rr-cache, but haven't found any resolution for the given line -> added the fixup (even though not after the correct merge point).
<sima>
imre, yeah it happens, rerere is sometimes a mess
warpme has quit []
<robclark>
sima: it isn't cros/android, it is perfetto
<sima>
robclark, well the original patch that landed the tracepoint in 2020 claimed it's for android
<sima>
msm is the first upstream driver using it
<robclark>
it is because android uses perfetto ;-)
<robclark>
anyways, it is a thing userspace tracing tools need.. and was already there.. so I used it ;-)
<sima>
yeah I just want to avoid a world where we have like android tracepoints (mostly downstream) and other tracepoints used by non-android
<sima>
kinda why I'm pestering pepp so much too
<robclark>
I didn't want to hack on perfetto to add a new thing.. so I used the existing thing
<sima>
robclark, yeah definitely don't want a 3rd thing just to make it even more messy
<sima>
but would be good to at least integrated that tracepoint into the same docs that pepp is working on
<robclark>
anyways, what is there seemed good enough.. anything else would just be more or less the same thing with a different coat of paint
<sima>
yup
<robclark>
fair
<sima>
I don't care about the pain brand, just that we're at least trying to document it and roll it out consistently
<robclark>
I hadn't been following the docs he is working on, but would make sense to have more than just the implicit "how perfetto uses it" docs
<sima>
kinda like the drm fdinfo situation, there's already much better consistency just by starting with some docs and forcing people to jointly bikeshed those
<sima>
robclark, yup
<sima>
also, some docs that we're trying really hard to keep those tracepoints stable across releases
<sima>
and consistent across drivers
<sima>
so that other traces can also use those
<sima>
*tracers
<robclark>
we don't have a choice but to keep that tracepoint as abi.. there is already userspace using it.. the time to bikeshed it has already passed
<sima>
eh, msm is the first one in upstream actually using it
<sima>
so you're the one baking it in
<robclark>
no, I mean perfetto is already using it
<sima>
yeah, but for the upstream no-regressions rule
<sima>
if we do a different one, we'll never break perfetto
<sima>
using the one perfetto uses means we must also pretty much keep it working as-is forever
<robclark>
right, but that is just creating more work for ourselves (ie. having to teach perfetto about a new thing)
<sima>
oh sure
<robclark>
I'm inherently lazy that way :-P
<sima>
bit of docs + some acks would still be good that nothing, because the og patch didn't even go to dri-devel iirc
<sima>
don't need much more, but should be a tad bit more than zero
<sima>
essentially drm uapi doc patch plus commit message that says "perfetto uses it, seems good enough" to dri-devel and I'll ack
<sima>
and maybe poke a few tracing people to make sure there's no violent disagreement
<robclark>
if you've got a pointer to what pepp is working on I'll take a look later and try to add something for gpu memory traces.. (it is holiday atm)
<sima>
it's stable uapi after all
<sima>
robclark, pepp is still very much wip, the uapi is kinda just a filler for now
<sima>
I think just a starting point is already much better, it really seemed to work pretty well to get drm-fdinfo into pretty good shape
<sima>
plus a lot of tursulin staying on top of things
<sima>
robclark, there's also stuff like maybe trying to make sure the ctx for the mem tracepoints has some relation to the ctx of the scheduler events
<sima>
that's probably the area where we're most likely to just make a mess for the dustbin
<sima>
and also whether userspace has any expectation of connecting that kernel ctx id with vk/gl context or not
<sima>
or with fdinfo stuff (but not sure we have those details there already)
<robclark>
sima: the tracepoint is global memory usage, fwiw
<robclark>
so no ctx
<robclark>
well, there is gpu_id
<sima>
yeah, but what do you put in there
<robclark>
but I guess that just maps to "create a different counter line"
<sima>
just want to avoid that one driver puts the drm minor in there, the next the hw engine and the third the logical ctx id
<sima>
fourth probably just goes with 0
<sima>
or that you can't align things with fdinfo output
<robclark>
minor is defn the wrong thing
<sima>
there's lots of ways to screw this up
<robclark>
maybe we should have a unique counter id for each drm device
Mangix has quit [Read error: Connection reset by peer]
<sima>
robclark, minor of the render node doesn't sound wrong to me for something that's gpu_id
Mangix has joined #dri-devel
<sima>
or the primary
<sima>
except accel messes that up ofc
<robclark>
each drm_device should have a unique id
<sima>
maybe?
<sima>
really my aim here is just to get people to ponder these details, and make sure the right folks are connected and we don't end up with fdinfo, sched tp and memory tp doing completely different things
<sima>
I fully expect that there will be at least some messy situations at first
coldfeet has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
tuliom has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
daemondragon has quit [Remote host closed the connection]
sima has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
lanodan has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
Tashtari has joined #dri-devel
mripard has quit [Quit: mripard]
kts has quit [Ping timeout: 480 seconds]
<Tashtari>
Hi all. I upgraded mesa-24.0.7_1 to mesa-24.1.1_2 and Firefox started segfaulting when loading certain websites (Google Maps for one) and PDFs. Downgrading the package resolves the issue, and upgrading to the latest package (24.1.2_1) does not resolve it. I've collected a backtrace here: http://paste.debian.net/1322416/
dliviu has quit [Ping timeout: 480 seconds]
<Tashtari>
Happy to collect any more data that might be needed to help resolve the issue. Can anyone take a look?
<Tashtari>
(I use Void Linux, btw)
tuliom has left #dri-devel [WeeChat 4.3.3]
<pepp>
Tashtari: which GPU are you using?
<Tashtari>
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde PRO / Venus LE / Tropo PRO-L [Radeon HD 8830M / R7 250 / R7 M465X] (rev 87)
coldfeet has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
Simonx22 has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
Simonx22 has joined #dri-devel
Simonx22 has quit []
Simonx22 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
benjaminl has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
nerdopolis has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
LeviYun has joined #dri-devel
feaneron has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
lanodan has quit [Quit: WeeChat 4.2.1]
lanodan has joined #dri-devel
<alyssa>
does glcts have any coverage for indirect draws with tessellation? why would it have that? (-:
<alyssa>
ah, there's KHR-GL46.pipeline_statistics_query_tests_ARB.functional_tess_queries ... so you need full gl4.6 to get coverage for a gles3.2 feature, classic
crabbedhaloablut has quit [Read error: Connection reset by peer]