ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Nasina has joined #dri-devel
kugel has quit [Ping timeout: 480 seconds]
epoch101_ has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
epoch101 has quit [Ping timeout: 480 seconds]
kugel has joined #dri-devel
kasper93_ has joined #dri-devel
kasper93 is now known as Guest15749
kasper93_ is now known as kasper93
fantom has quit [Ping timeout: 480 seconds]
Guest15749 has quit [Ping timeout: 480 seconds]
Nasina has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
kugel has quit [Remote host closed the connection]
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
The_Company has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Company has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
epoch101_ has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
djbw has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
normalpan has joined #dri-devel
gnuiyl has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
amarsh04 has joined #dri-devel
asrivats has joined #dri-devel
glennk has joined #dri-devel
Nasina has joined #dri-devel
normalpan has quit []
asrivats has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
fab has joined #dri-devel
itoral has joined #dri-devel
FAQ_ has joined #dri-devel
croissant has joined #dri-devel
parthiban has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
fantom has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
sima has joined #dri-devel
tzimmermann has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
rasterman has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
coldfeet has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
dolphin has joined #dri-devel
<daniels> rburton: afraid not
mvlad has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has joined #dri-devel
JTL1 has joined #dri-devel
JTL has quit [Read error: Connection reset by peer]
Calandracas_ has joined #dri-devel
Calandracas has quit [Ping timeout: 480 seconds]
FAQ_ has quit [Remote host closed the connection]
JRepin has quit []
JRepin has joined #dri-devel
hansg has joined #dri-devel
apinheiro has joined #dri-devel
lynxeye has joined #dri-devel
vliaskov has joined #dri-devel
urja has quit [Read error: Connection reset by peer]
oneforall2 has quit [Read error: No route to host]
urja has joined #dri-devel
oneforall2 has joined #dri-devel
The_Company has quit []
Company has joined #dri-devel
jkrzyszt has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
lsntvt has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
hansg has quit [Quit: Leaving]
<mlankhorst> airlied: if still awake, why is evicted memory not accounted?
ybogdano has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
<mlankhorst> seems at least inconsistent how TTM_PL_FLAG_MEMCG Is cleared, since amdgpu_bo_placement_from_domain can set multiple placements with MEMCG flag set
apinheiro has quit [Quit: Leaving]
<mlankhorst> I rebased anyway, but need to test on something other than eviction :)
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<rburton> so today i discovered ninjatrace and the first package i tried it on was mesa. looks like src/intel/perf/libintel_perf.a took over a minute to link...
<psykose> when i tried it there was some intel file that took 60s to build, nothing took that long to link though
<psykose> maybe ld.bfd takes that long
<rburton> the target is src/intel/perf/libintel_perf.a.p/meson-generated_.._intel_perf_metrics.c.o so actually maybe thats the compile
<kode54> I mean, it may take that long to link if you're enabling LTO
<psykose> that is the compile yeah, same one
coldfeet has quit [Quit: Lost terminal]
haaninjo has joined #dri-devel
jsa2 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
<rburton> daniels: see i knew you were useful for something
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
phasta has joined #dri-devel
<kode54> lolol component of ACO taking 52 seconds
<phasta> ever since the URL change my dim setup just seems broken. I now cloned a new instance, but something still seems broken. When updating branches, it asks me for names for the new remotes. https://paste.debian.net/1374457/
<kode54> but I guess that's better than just building the whole of LLVM
<phasta> Do I have to delete the old remotes first?
nerdopolis has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
JRepin has quit [Remote host closed the connection]
JRepin has joined #dri-devel
Nasina has joined #dri-devel
frankbinns2 is now known as frankbinns
Nasina has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
AndrewR has quit [Quit: Leaving]
cef has quit [Ping timeout: 480 seconds]
valpackett has joined #dri-devel
itoral has quit [Remote host closed the connection]
cef has joined #dri-devel
Nasina has joined #dri-devel
Nasina has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
feaneron has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
fab has quit [Quit: fab]
<jani> phasta: add this to your .ssh/config:
<jani> Host gitlab.freedesktop.org
<jani> Hostname ssh.gitlab.freedesktop.org
<jani> after that, the updates should work(tm)
<jani> it's a bit of a chicken and egg situation, and we didn't get a heads up
<phasta> jani, thx!
<phasta> There's nothing more annoying than having to repair your screw driver while you actually have to drive a lot of screws…
<jani> yeah...
<phasta> changing an ssh link is scientific proof for the butterfly effect ;)
<kode54> have to change the ssh link because the web link is a CDN that's behind SNI and does host sharing and therefore can't possibly do SSH forwarding
epoch101 has joined #dri-devel
<phasta> What is the "rerere" cache?
<ukleinek> phasta: that's where git stores merge conflict resolutions
fab has joined #dri-devel
<ukleinek> it stands for "REuse REcorded REsolution"
dolphin has quit [Quit: Leaving]
<phasta> https://paste.debian.net/1374477/ I should have stayed in bed today
pepp_ has quit []
pepp has joined #dri-devel
<phasta> hm, one also needs to reset rerere in the linux tree. Ah well.
epoch101 has quit [Ping timeout: 480 seconds]
fab has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
asrivats has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
valpackett has quit [Ping timeout: 480 seconds]
valpackett has joined #dri-devel
pixelcluster_ has quit []
pixelcluster has joined #dri-devel
kzd has joined #dri-devel
amarsh04 has quit []
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
valpackett has quit [Ping timeout: 480 seconds]
olivial has quit [Read error: Connection reset by peer]
olivial has joined #dri-devel
<karolherbst> it goes without saying, but if you see people instigating or pirating/leaking specifications, please let us (CoC team) know. Can't have anybody do that on our platforms...
epoch101 has joined #dri-devel
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
Duke`` has joined #dri-devel
davispuh has joined #dri-devel
bolson has joined #dri-devel
dsimic is now known as Guest15805
dsimic has joined #dri-devel
Guest15805 has quit [Ping timeout: 480 seconds]
phasta has quit [Quit: Leaving]
<Lynne> reacting in this way and explicitly pointing it out; I'd assume you've just seen the jpeg2000 specifications
<eric_engestrom> mesa devs: please write any (future) news-worthy note about your work that will be in 25.2.0 in this issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13155
<eric_engestrom> (and sorry for taking so long to put something like this in place...)
tzimmermann has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
edolnx_ has quit []
edolnx has joined #dri-devel
<alyssa> karolherbst: can I pirate the vulkan spec
<alyssa> pirates 🤝 dragon
<ccr> :)
<alyssa> eric_engestrom: huge +1 for doing that on the issue tracker instead of in-tree, docs/relnotes.txt are the silliest kind of merge conflicts there are and this should solve that nicely
<alyssa> thank you!
<alyssa> (I just categorically do not use docs/relnotes or docs/features anymore largely because the conflicts are silly and we have vulkaninfo for that)
<eric_engestrom> ❤️
<eric_engestrom> and yeah, putting that in a text file was untenable, having a folder with a bunch of files would solve that but feels over-engineered; this is a much simpler solution and it might get noisy (we'll see how people use it), but with the structure I suggested I think it should work well
<alyssa> nod
<alyssa> meanwhile apparently it's "uprev CTS for unrelated reason and now i have a bunch of new test fails to fix" day
<alyssa> yahoo
djbw has quit [Ping timeout: 480 seconds]
<alyssa> second CTS bug of the day, yippee
rasterman has quit [Quit: Gettin' stinky!]
<karolherbst> Lynne: the jpeg2000 specification?
airlied_ has joined #dri-devel
airlied has quit [Ping timeout: 480 seconds]
<alyssa> how is 'dEQP-VK.pipeline.monolithic.input_attribute_offset.vec2.offset_*.padded.*.*' failing, that wasn't even touched
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<alyssa> rg3igalia: any idea?
<alyssa> the padded/packed ones are failing, overlapping is not
<alyssa> that whole file was last touched in 2023 so I'm.. confused
<alyssa> I'm kinda suspicious of, like, UB in the CTS revealed by bumping to gcc-15 or something? IDK
jkrzyszt has quit [Ping timeout: 480 seconds]
Lyude has joined #dri-devel
<alyssa> is that failing for anyone else that bumped CTS + gcc-15 ecently?
<Lynne> karolherbst: renouned to be the worst written specifications in the world. if it were the script to a hit TV show, the fanbase would trigger riots
asrivats has quit [Ping timeout: 480 seconds]
<alyssa> robclark: gah, thanks.
<robclark> I don't remember offhand _which_ tests were broken.. but it was related to gcc 15 so I guess the same
<alyssa> yeah it's these
<alyssa> can I build cts with clang?
<robclark> I would expect so.. goog/android kinda likes clang
<alyssa> i kinda do too but feel vaguely guilty about it
<cwabbott> just set -O2
<robclark> or that, yeah
<alyssa> maybe there's something to this whole "run debian and let other people hit all the bugs first" thing
<alyssa> :P
coldfeet has quit [Remote host closed the connection]
<cwabbott> I definitely felt like the guinea pig when I hit that
feaneron has quit [Ping timeout: 480 seconds]
<cwabbott> upgraded from f40 to f42 to get vulkan 1.4 headers, and immediately everything is on fire
<alyssa> yeah...
<ccr> insert "this is fine" meme here?
<cwabbott> also I learned from this that CMake uses -O3 by default for Release and -O2 for RelWithDebInfo
<cwabbott> a great CMake moment
<zmike> hahah
feaneron has joined #dri-devel
epoch101 has quit []
<ccr> it was egcs all along
<mdnavare_> Thanks airlied , I was able to use the igt tools dpcd read, that uses the dev/drm_dp_aux0
kasper93 has quit [Ping timeout: 480 seconds]
f_ is now known as funderscore
lynxeye has quit [Quit: Leaving.]
epoch101 has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
coldfeet has joined #dri-devel
kasper93 has joined #dri-devel
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
epoch101 has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
jsa2 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
kasper93_ has joined #dri-devel
kasper93 is now known as Guest15812
kasper93_ is now known as kasper93
gouchi has joined #dri-devel
Guest15812 has quit [Ping timeout: 480 seconds]
funderscore is now known as f_
amarsh04 has joined #dri-devel
fab has joined #dri-devel
kasper93 has quit []
kasper93 has joined #dri-devel
kasper93 has quit []
kasper93 has joined #dri-devel
kasper93 has quit []
kasper93 has joined #dri-devel
kasper93 has quit []
kasper93 has joined #dri-devel
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #dri-devel
kasper93 has quit []
kasper93 has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
airlied_ is now known as airlied
<airlied> mlankhorst: evicted isn't accounted as we can't agree on how that should work, so we've punted on making a decision
<airlied> the problem with accounting eviction is, what do you do if the owner of the object has no space left in their cgroup?
fab has quit [Ping timeout: 480 seconds]
asrivats has joined #dri-devel
<sima> memcg aware shrinker
<sima> which is terrible
<airlied> sima: that is the concept, but it still doesn't really solve the wtf do we do part of the problem
<airlied> like we only evict the clients that have space?
<airlied> though memcg aware ttm pools is already giving me the run away vibe
<sima> airlied, I think we'd evict as usual, but try to shrink in system memory to keep them within limits
<sima> and if that fails, kill them
<sima> blame sysadmin for setting inconsistent limits
<sima> I guess could instead skip to another client, but oh dear does that feel like better running shoes are needed
<airlied> I think I'm in the build what we can, and see if the solutions fall out
<sima> yeah same
bolson_ has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
<mlankhorst> airlied: it can force it into the cgroup and go over limit then kill
<mlankhorst> airlied: I'm having troubles making the code count a non-zero GPU cgroup limit at all though for the normal case
mvlad has quit [Remote host closed the connection]
<airlied> mlankhorst: but killing a misc process due to another process just allocating VRAM seems wrong
<airlied> since we don't want to double account VRAM allocation in main memory as well "just in case"
<mlankhorst> memory.max on the other hand will first set the
<mlankhorst> limit to prevent new charges, and then reclaim and OOM kill until the
<mlankhorst> new limit is met - or the task writing to memory.max is killed.
<airlied> the problem is eviction doesn't happen in the process context of the process that owns the evicted object
<airlied> there is no way to return an ENOMEM to that process to let it handle things
<mlankhorst> Yeah that's the fun part
<airlied> so we could go over the limit, and the next time it calls malloc it will blow up
<mlankhorst> If we go over max (hard limit), you die
<airlied> but if the first thing it does is push the object back into VRAM then the eviction shouldn't have killed it
<mlankhorst> if we go over high (soft limit), new allocations fail in the other process
<airlied> since the eviction was only temporary over commit caused by another process
<mlankhorst> Which it should be able to deal with, or the limit should not have been set
<airlied> like you could have 4GB of VRAM allocated, it seems wrong to cause you to die because another process allocates 1GB
<airlied> now maybe we can solve it via dmem limits
<mlankhorst> That's entirely doable
<airlied> so that you can't overcommit VRAM to cause evictions
<mlankhorst> Exactly :)
<airlied> but I still have trouble just saying evictions should definitely blow up the original process
<airlied> hence why evictions are not being focused on yet :-)
<mlankhorst> They definitely could, but that's why it's recommended to set memory.high, not memory.max
<airlied> the initial series is just to get accounting, so we can know which cgroup is taking all the ram, I haven't really gotten to failing allocs
<mlankhorst> Ooo memcg aware shrinker
<mlankhorst> You could re-use the dmem one probably, perhaps we should just cgroup to unify it
<airlied> I haven't worked out how to use dmem properly yet either :-)
<airlied> I only see a toplevel dmem in /sys/fs/cgroups
<mlankhorst> mkdir igt; echo +dmem > cgroup.subtree_control; cd igt; echo $$ > cgroup.procs; ./xe_evict
<mlankhorst> and watch -n.1 'grep gpu memory.stat; cat dmem.current' somewhere for pretty numbers
gouchi has quit [Remote host closed the connection]
jsa1 has quit [Ping timeout: 480 seconds]
<airlied> ah nice, I should probably write some igts to play around with this a bit more
<sima> airlied, imo the other processes should be sufficiently vram limited if you have system memory limits that are too tight
<sima> like if you set stupid limits, you get to keep the pieces
<sima> I think the only legit use-case would be if you've marked the surplus vram allocations as purgeable
<sima> but in that case we'd just ditch them instead of moving into system memory
<sima> like if you have 2 cgroups A and B and swapping out dmem of A into system memory would push it over memcg limits
<sima> then you need to limit dmem of B to make sure that doesn't happen
<sima> if you don't, it's just a silly misconfig imo
<airlied> sima: yeah but Christian disagreed with that recently, but I think more in the case where we kill B even if it doesn't have a dmem limit because we can't satisfy it's VRAM allocation due to the system configuration
<sima> yeah I think in that case we need to shoot A first and release all it's memory
<sima> which currently we cant
<sima> otoh if B needs more dmem and you didn't configure your limits to make sure that's possible
<sima> again seems like silly misconfig to me?
<sima> essentially "no limit" = "you get what's left"
<sima> and with the dmem/memcg split you need to think a bit harder to make sure it all works out
glennk has quit [Ping timeout: 480 seconds]
asrivats has quit [Remote host closed the connection]
asrivats has joined #dri-devel
<sima> it also depends how we implement limits, but the simplest essentially means that the upper hard limit for all other groups is the minimal amount of dmem you will be left with
<sima> everything above needs to have room for in memcg or it can blow up
<sima> e.g. with 10gb dmem, A and B both have 6gb max you need 2gb of memcg headroom for each for swapout or it could fail in funny ways
<sima> or 2gb of purgeable memory that doesn't need memcg for eviction
asrivats has quit [Remote host closed the connection]
asrivats has joined #dri-devel
<mlankhorst> Dying is also the extreme case, it could be some memory that is madvised could be purged for example, or filesystem caches written
<sima> yeah, we should at least trigger the other memcg shrinking if we don't have a ttm memcg-aware shrinker yett
<sima> no idea how that works though
asrivats has quit [Ping timeout: 480 seconds]
<mlankhorst> the flag should be the other way around then, MEMCG_FORCE for eviction
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
haaninjo has quit [Quit: Ex-Chat]
sima has quit [Ping timeout: 480 seconds]
epoch101 has quit []
epoch101 has joined #dri-devel
asrivats has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
asrivats has quit [Ping timeout: 480 seconds]
valpackett has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
qpla_ has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
qpla has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
parthiban has quit [Remote host closed the connection]
parthiban has joined #dri-devel
guludo has quit [Quit: WeeChat 4.6.1]
epoch101 has quit []
diego has joined #dri-devel
Pie-jacker875 has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
<Pie-jacker875> hey I would like to make a bug report but I'm a bit of a noob and am not sure how to get some of the information. steamvr_room_setup crashes and I'm not sure what would be useful to include. It's a unity application, so I have the player.log file for one.