NiGaR has quit [Remote host closed the connection]
davispuh has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
NiGaR has joined #dri-devel
valpackett has joined #dri-devel
lplc_ has quit []
lplc has joined #dri-devel
itoral has joined #dri-devel
JamesidowuToyin[m] has joined #dri-devel
jsa1 has joined #dri-devel
fab has quit [Quit: fab]
dolphin has joined #dri-devel
sima has joined #dri-devel
glennk has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
<MrCooper>
mareko: technically I'm in a different team now (focus on mutter & Xwayland), as is ajax, so you rather need to ask airlied or José Exposito; AFAIR we do support amdgpu with acceleration on ppc64el in RHEL in principle though, so not having any CI coverage isn't great
kts has joined #dri-devel
JamesidowuToyin[m] has quit [autokilled: This host violated network policy and has been banned. Mail support@oftc.net if you think this is in error. (2025-01-30 07:45:39)]
vliaskov has joined #dri-devel
rasterman has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
tzimmermann has joined #dri-devel
phasta has joined #dri-devel
jkrzyszt has joined #dri-devel
kaiwenjon_ has joined #dri-devel
kaiwenjon has quit [Read error: Connection reset by peer]
<sima>
dakr, good mail, thanks for doing the wrestling
<sima>
also chatted with airlied and we're at 15+ years of dma-api maintainers randomly nacking stuff gpu drivers want/need
dsimic is now known as Guest7449
dsimic has joined #dri-devel
Guest7449 has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
jsa1 has joined #dri-devel
lynxeye has joined #dri-devel
kaiwenjon_ has left #dri-devel [#dri-devel]
kaiwenjon has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
oppagangnam has joined #dri-devel
oppagangnam has quit [Remote host closed the connection]
heuristicsman has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<heuristicsman>
what i indeed assume , but do not have so much experience yet on doubly compressed intrinsics alike, is: + - are compatible only if the subtrahand before adding is enough big yet always smaller than the one subtracted from (naturally the case), so in other words, i do not think single operand meets the requirement, so the data banks scaffold of selection needs to be decoded from
<heuristicsman>
compilers work and operand needs to be added to that bank and then again encoded together back to double encoding to yield needed result, since the banks answer selection logic is enough big it has both views decode and encode which are compatible. I think there are only minor such rules, but saviour is that multibank data access can be done and batched add for operands, which should be
<heuristicsman>
compatible with say non-illformed output. Needs a bit confirming, i kinda recall those rules from the past testings.
heuristicsman has quit [Remote host closed the connection]
feaneron has joined #dri-devel
mvlad has joined #dri-devel
feaneron has quit [Remote host closed the connection]
<sima>
DemiMarie, on the amd/virtio discussion, all these issues you point out is why I think there's either pup(FOLL_LONGTERM) or real hw support so that the iommu/gpu handles page faults/invalidations at the hw level
<sima>
and the mmu notifiers just pass tlb flush commands forward as needed
feaneron has joined #dri-devel
<sima>
anything else indeed just falls apart everywhere at the seams
distrohumiliation has joined #dri-devel
distrohumiliation has quit [Remote host closed the connection]
tangoentanglement has joined #dri-devel
guludo has joined #dri-devel
<tangoentanglement>
so maybe it is possible to pad operands, to stay at required size, i.e that it would not yield bigger value from smaller so it would be able to pass dependecies down the line to later instructions sort of like coalesce to subtract, if this is not possible than only constants can be compiled in and passed forward at compile time straight as deps to later instructions, but anyways
<tangoentanglement>
taking the bank of selection scaffolds and decoding them is not so high overhead either. I am testing all that on this month February, but i think i did make sense at least i vaguely remember so from calculator times.
Company has joined #dri-devel
tangoentanglement has quit [Remote host closed the connection]
kode548 has joined #dri-devel
kode54 has quit [Ping timeout: 480 seconds]
feaneron has quit [Remote host closed the connection]
kode548 has quit []
kode54 has joined #dri-devel
jinglearoundstars has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
Omax has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
<jinglearoundstars>
it much looks like the transition values with padding would indeed function, so you pass startingfrommaxvalue_as_anyconstant+singlepackedvalue and consistently receive as such from double encoded scaffolds, so receiver slots would be decoded properly, can be defined as offset which otherwise would not be used. As if only operands were decoded with offset appended i think then they
<jinglearoundstars>
can be received well in double encoded slots of receive or arrival slots. But those parts in the logs i can not remember where they landed, the execution itself is easy, but still a number of lines of work to do, as i said -- i am not interested in sharing that work anymore. That is very reactive or say invasive code to the world, but i assume many parties of rich people actually
<jinglearoundstars>
have it to print money to back up their manufacturing losses. I mean i am not able to compete without leveling up there, otherwise it much looks like i would get eaten for breakfast. But if the value is double encoded from subtract, it needs no offset anymore, cause compiler already filled it. I am in a war with many terrorists however i am not likely in conflict with the successful
<jinglearoundstars>
people, due to those other morons bothering me with teams , i need to push better code to my own, that is appearing as stereotypical side effect, people have asked why do i need to go there, well those are interesting questions. Answer is stereotypical targeted envy by leftovers at me, which you do not get , so it is rather strange to you as to why i work so hard.
JRepin has quit []
JRepin has joined #dri-devel
Omax has joined #dri-devel
<jinglearoundstars>
but there is no triple encoding anywhere in compiler anymore (so this simplifies), only addressing, since triple encoding is a side of adding two double encoded hashes addressed naturally.
<jinglearoundstars>
that is because i succeeded in data banks access
<jinglearoundstars>
so triple encodings and above is not anymore needed.
feaneron has joined #dri-devel
kzd has quit [Quit: kzd]
sguddati has joined #dri-devel
<zmike>
mareko: is LINEAR really not supported for RGBA32F formats?
apinheiro has quit [Quit: Leaving]
<zmike>
cuz it seems to work...
itoral has quit [Quit: Leaving]
kzd has joined #dri-devel
vliaskov has quit [Read error: No route to host]
pcercuei has joined #dri-devel
sarnex has quit [Read error: No route to host]
jsa1 has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
jinglearoundstars has quit [Remote host closed the connection]
sguddati has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
sandiorboiko has joined #dri-devel
nashpa has quit []
dliviu has joined #dri-devel
hexa- has quit [Quit: WeeChat 4.4.3]
<sandiorboiko>
maybe i explained it again not as sharply overall, but you see double encodings are simpler to be done as address mappings imo, there is no need to do full encoding if the form is already some bank that is only at 3000digits, so it can be now addressed from table, but overall i am screwed, my timeline on the works is starting to get tight , grandmother wants to kick me out, and wolves
<sandiorboiko>
are as much against me as they ever were. I DO NOT KNOW, WHERE they let me live like a real human it's entirely hippocratic like what is happening. I get overthe line after months, but i do not have that time. It is very difficult last effort that i am trying, and i need it to happen, but can not work at all in such environments they cheat me in.
hexa- has joined #dri-devel
sandiorboiko has quit [Remote host closed the connection]
jsa1 has quit [Ping timeout: 480 seconds]
Omax has quit [Ping timeout: 480 seconds]
Omax has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
heat has joined #dri-devel
<DemiMarie>
sima: In this case pup(FOLL_LONGTERM) is even more attractive because device memory is just virtual memory.
<DemiMarie>
sima: Can the forced migration to device memory be done reliably?
<DemiMarie>
Also, time to bypass the DMA API maintainers and send something directly to Linus?
<phasta>
You should think long-term. Are then fixes and reworks also to be sent directly to him 3 years down the road?
dolphin has quit [Quit: Leaving]
<sima>
DemiMarie, I didn't really follow that part since it was about virtio specific things
<sima>
the kernel really can't, because if you do this like hmm you again need hw support for pagefaults
<sima>
plus hmm cannot guarantee migration to device memory
<DemiMarie>
sima: the idea I had is to move the pages to device memory and leave them there
<sima>
anon memory probably freaks out to no end if it's suddenly device memory without a struct page
<DemiMarie>
If you don't have HW support for pagefaults then it's up to the host kernel to fail the operation.
<DemiMarie>
What about device memory with a struct page?
<sima>
you could do it as coherent device memory, then anon memory works in your device memory (unlike device private memory that hmm uses)
<sima>
but you're again stuck on the core mm's inability to guarantee migration
<sima>
migration is all best effort
<DemiMarie>
stop_machine()? Only half joking.
<sima>
not enough
<DemiMarie>
Why can't migration be reliable?
<sima>
linux core mm does a lot of randomly grabbing a page/folio reference, and those all block migration
<sima>
with enough whacking it mostly works for stuff like cma or memory hotunplug with zone_moveable, but it's brittle
<DemiMarie>
What about make_device_exclusive_range() or similar, but without the exclusive part?
fab has quit [Quit: fab]
<sima>
pup(FOLL_LONGTERM) is one of the pieces to make it less brittle, so that you know whether an elevated refcount is temporary and more retrying should help
<sima>
or a permanent pin, and more retrying is only going to heat the world
<sima>
DemiMarie, that doesn't move anything
* heat
the world
<sima>
DemiMarie, I guess you could try with coherent device memory and just migrating really, really hard
<sima>
then you're at the same peril like cma or memory hotunplug
<DemiMarie>
sima: could there be a way to lock out anyone who tries to grab a reference?
<sima>
but for per critical stuff like hmm migration it's fundamentally fallible
<sima>
DemiMarie, disable all the cool features like transparent hugepages
<sima>
numa load balancing
<sima>
ksm
<sima>
writeback too iirc
<sima>
constantly more getting added
<sima>
defo direct i/o
<DemiMarie>
sima: I meant "grab a mutex so they block"
<heat>
in theory you could do that but you'd create "heating the world" on the opposite, refgrabbing direction
<DemiMarie>
Why is that?
<sima>
see link but tldr is the linux core mm is designed on the principle that quicksand is awesome
<heat>
because if there was a refcount lock-out you'd spin on folio_get
<heat>
because there isn't, you spin on page migration (or fail)
<heat>
it's way easier to fail page migration than failing a normal-ass refcount
<sima>
it's also that core mm is lockless to the max
<DemiMarie>
For performance reasons?
<heat>
yes
<sima>
so even if you hold a reference and the lock for something, it's really surprising how little guarantees that often gives you
<sima>
like the entire pte walking is just pure yolo, and it happens absolutely everywhere all the time
<DemiMarie>
Why does it not crash? RCU?
<heat>
hey it's not pure yolo it's homebred RCU
<sima>
some of the best people in the world banging their heads at it for decades
<heat>
gup_fast generally just disables interrupts and doesn't use RCU
<sima>
heat, oh yeah it's a work of art
<heat>
to free a page table you need to do a TLB shootdown thus IPI thus if your IRQs are disabled it's safe to traverse
<heat>
it is in effect homebred RCU
<sima>
there's also so much fun due to locking inversions
<sima>
where you lookup a thing, grab the locks and then recheck whether you got the right one
<sima>
and there's fundamentally no way to just take a lock to make things stable
<sima>
and it's getting worse every year, like with lockless vma traversals and page faults
<DemiMarie>
I wonder at what point it would actually have been faster (dev time wise) to formally prove the whole thing correct and not have to do the debugging.
<sima>
DemiMarie, open random file in mm/ and stand back in awe at the if ladders
<sima>
especially anything handling pagetable entries
<sima>
but yeah formal proof probably good idea
<sima>
but the issue is also, what do you even want to proof
<DemiMarie>
"no memory corruption"
<sima>
because some things look very, very fish from a "will it livelock" pov
<sima>
not even close to enough
<DemiMarie>
no deadlocks, no livelocks, etc
<sima>
the livelocks are real pain
<sima>
and often stochastic stuff
<sima>
like the race windows align such that you win often enough to never pile up, but if you'd have consistently bad luck you'd pile up
* DemiMarie
wonders if past a certain point people should just be using multiple machines, rather than trying to make mm scale to huge machines
<sima>
yes
<sima>
cloud didn't happen just for fun
<heat>
this is not just about making mm scale to huge machines
<heat>
small machines are also heavily impacted
<heat>
big locks suck
<sima>
yeah small cros tend to really thrash mm
<heat>
the per-vma locking patches address problems <checks notes> in android when apps create like 80 threads at startup
<DemiMarie>
Big locks suck unless you care about reliability and security way more than performance. I suspect that is why OpenBSD is so full of them.
<heat>
OpenBSD is full of them because it's a hobby kernel
<sima>
yup
<heat>
they would like to get rid of them and are slowly doing so
<sima>
that too
<sima>
like I think core mm is probably one place where rust wont help
<sima>
like some of the memory barrier comments in there are just pure nightmare fodder
<DemiMarie>
ATS might, though. That's full dependent & linear types.
<sima>
since it's not just about your cpu code, but also about stuff like how tlb fetches actually walk pagetables on your machine
<heat>
like, yes big locks make for simpler code, which is nice for security and reliability. but they also make you prone to suffer terrible choking on those huge locks, thus a reliability problem (and in effect, probably a security one, depending on what you're running)
<sima>
DemiMarie, I think more formal proofing would be good, afaik only rcu in upstream linux is fully formally proved
<DemiMarie>
sima: I was thinking of extracting core mm from F* or Coq.
JRepin has quit []
JRepin has joined #dri-devel
<DemiMarie>
heat: I think safety critical systems prefer to use multiple components that are individually single-threaded. They can scale by having many cores that don't share memory.
<sima>
device-exclusive was added, but not everywhere, boom in way too many places
<DemiMarie>
Honestly I think userptr is rather cursed.
<DemiMarie>
Can migration be reliable enough to make uAPI depend on it?
<DemiMarie>
I also wonder if this could be dealt with using hypervisor magic: "hey, that page of mine is a blob object now"
riteo has joined #dri-devel
<mareko>
zmike: why wouldn't it be supported?
<zmike>
mareko: I have an MR to fix
fab has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
JRepin has quit []
JRepin has joined #dri-devel
davispuh has joined #dri-devel
sguddati has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
vanjasaroda has joined #dri-devel
vanjasaroda has quit [Remote host closed the connection]
haaninjo has joined #dri-devel
traditionalwiki has joined #dri-devel
traditionalwiki has quit [Remote host closed the connection]
mbrost has joined #dri-devel
neverthelessmaniac has joined #dri-devel
Duke`` has joined #dri-devel
jsa1 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
phasta has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
anholt has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
<neverthelessmaniac>
how to explain here, well encoding to compressed format deploys encoder from the big value from i-cache and result scaffolds virtual cache from structures, the last which is the most overheadish operation, the data loop isn't perfect either but slimmer by say 3fold perhaps? So it's hence cheaper in the compiler to embed state as remainder of whole buffer of banks which compiler
<neverthelessmaniac>
lifted anyways already once, but we do not want to do that so often. then you can say things like, i want the first bank, and remove all of the other banks of trillion options in the register, and that since decoding is done in lookup table ends up as being faster. That is also lot faster for IO. Now you write intrinsics say you want to access some tiled set of answer banks, you
<neverthelessmaniac>
have toppest largest state, and when you remove first state you get everything but first etc. This option became possible cause of this simple fs hack i posted which is not as heavy as encoding from full initial value to packed. So now you can address say you want to bring together bankset1 and bankset2 and hit to execute them, so deps would go from first set to second and as to
<neverthelessmaniac>
however you need. so remember decoding is cheaper than initial encoding, so you want to go more this way for perfectionism on performance.
JRepin has quit []
JRepin has joined #dri-devel
<jenatali>
Ugh. Meson 1.5.1 can't use CMake to find LLVM 19
<jenatali>
What a mess
<daniels>
jenatali: ...
<jenatali>
Means I need to rebuild the primary Windows container too to get a new meson apparently
* daniels
twitches
<daniels>
that was a deeply unpleasant time of my life
mbrost has quit [Ping timeout: 480 seconds]
<daniels>
the bit where I broke up with my long-term girlfriend was probably way less damaging than Windows + Meson + LLVM + CMake + CI
<jenatali>
Yeah... I got the build working locally with llvm19 so at least I'm pretty confident that just bumping meson should work
<daniels>
heading out now, fingers crossed for you tho :)
<dj-death>
daniels: and you do this for work...
mehdi-djait3397165695212282475 has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Kayden has quit [Quit: -> JF]
neverthelessmaniac has quit [Ping timeout: 480 seconds]
rz_ has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
simplestofsuch has joined #dri-devel
<jenatali>
Aaaand new meson doesn't install without long paths enabled
<jenatali>
I hate dependency updates
<mareko>
wouldn't it be nice if LLVM wasn't required by Mesa
<jenatali>
Mhmm
<jenatali>
LLVM as a runtime dependency is terrible
<kisak>
mareko: hypothetically, how would you feel about delaying pulling llvm<18 support until after mesa 25.0-branchpoint and hopefully radeonsi/ACO is good to go for the newer AMD gfx generations by the time 25.1 rolls around? ~non-sequitor~ If the mesa build sees llvm 15 is around, but not usable with radeonsi/llvm, will it automatically build radeonsi/ACO or will it fail the build as requirements not met
<kisak>
for radeonsi/llvm?
<kisak>
jenatali: llvm being too new for meson autodetect is a chronic issue. Over in Debian land, the build system adds in the equivilent to
<jenatali>
And I was wrong it's not meson it's numpy :(
<jenatali>
Oh it's meson's tests running as part of numpy's install. Gross
<dcbaker>
jenatali: of course it’s cmake… and of course it’s in numpy which has a vednored copy of meson while we get some of their stuff upstream…
<dcbaker>
I wonder if I can ask the numpy folks to not run our tests on install
<jenatali>
Seems like the right call
<dcbaker>
Although that’s also an old version of numpy and numpy >=2.0 should work
<mareko>
kisak: I can delay that. LLVM isn't required by AMD drivers and ACO is used when LLVM is disabled at build time, but it's also not a tested or optimized configuration on RDNA 1-4. It's possible that when you enable llvmpipe, it also enables LLVM for radeonsi.
<mareko>
radeonsi+ACO likely won't be ready by 25.1
<jenatali>
dcbaker: There's an issue with some of Mesa's scripts that prevent it from working with >= 2.0
ohogb has joined #dri-devel
<dcbaker>
Sigh. I guess i only fixed piglit. I probably fix that
<jenatali>
Oh maybe it was piglit, I don't remember. That same container gets used to build both
<jenatali>
Should've checked if that constraint could be removed. Oh well
Kayden has joined #dri-devel
feaneron has quit [Remote host closed the connection]
jkrzyszt has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
tobiasjakobi has joined #dri-devel
mbrost has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
phasta has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
Duke`` has joined #dri-devel
<simplestofsuch>
what intrinsics i meant address of bankset, then address of a bank, then address of cellset, address of a cell which are all address of programset. So four 3000digit worth values are enough, you do not need mul for this. Now you add those fields with accessor routines, so first two bankssets to be accessed is some index and from them first two banksets you target three banks, then four
<simplestofsuch>
cellssets then 9 cells. and what happens next they were double encoded already, you reindex them according to access and run the lookup table on it as you got them from a data bank, since it was dependency tree, so that index yields you enourmous bunch of instructions which you can subindex again or not etc, but the compiler itself did only two rounds however from which the last was
<simplestofsuch>
inexpensive, in other words what compiler did was encode once a very expensive loop then add together some single encoded values and encode them into a tiled address. due to the data access routine i posted it can be done, but there is only one catch the intrinsic like showed on the paper of Cornell's library hindi genius needs inexpensive lookup tables cause addends or second operator
<simplestofsuch>
needs to be decoded differently, since the compiler would anyways hide the latency, you end up doing the sets transitions in whatever batch with addressing, you want to add 4 12 or 23 of them together it's upto you. simplest is two , not very hard is 20 you just shift the operands like adder intrinsic is shown in the paper, but i knew this too tbh. i figured out similar things.
ohogb has quit []
ohogb has joined #dri-devel
ohogb has quit []
ohogb has joined #dri-devel
phasta has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
simplestofsuch has quit [Remote host closed the connection]
paulk-bis has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
diacibenuci has joined #dri-devel
JRepin has quit []
JRepin has joined #dri-devel
jsa1 has joined #dri-devel
bolson has quit []
<diacibenuci>
so all i tried to say is from the moment of encoding the first big value, it's saner not to use that loop anymore, since if you permute two double encoded values the curve is already polynomialy larger set, now if you do 20 of them you are already at millions of qubits etc. without any performance loss, since the lookup table is just a small magic value. all you do is read the bits then
<diacibenuci>
change 62 if present to say 69 and if not no access done, and this goes very fast, lot faster than the full dma or loop encoder. More performance is not possible it's military grade scheme what i develop but i do not want to work with military if they kill wrong people.
ryanneph has joined #dri-devel
<jenatali>
Uh... glsl compiler warnings test is failing with access violation (segfault) and I don't repro it :(
<DemiMarie>
sima: Actually, there is another option: try to migrate the pages, and if that is not possible, either return an error to userspace or leave the pages on the CPU and try again later.
mbrost has quit [Ping timeout: 480 seconds]
<jenatali>
Uh... and passed on re-run. That's not good
diacibenuci has quit [Remote host closed the connection]
ledookyn has joined #dri-devel
<ledookyn>
I started the rant with, that you would not see that full encoder anymore in real code, cause there is no point for this anymore, so you would not able to understand any of the actual code if i was not speaking about it. And with that i try to finish the story too. You can change the depth of vision by just using a magic value, back and forth by adding say 1000bank values together together
<ledookyn>
trilliontimestrilliontimes20trillions, i do not have access to such calculator yet, i am choosing something. so that is something like millions of qubits likely, whatever i do not know, i am tired now. Such men as you dwfreed should be fucking dropped to sharks or crocodiles food, fucking annoying shitbag you are.
<ledookyn>
one after another (shifting their operands), and encoding that to smaller number back but on the fly with logics in magic value. so now a set has in every cell 20times 64bit etc. That is though real mathematics however i must say i am not very good mathematician, however when every cell has 20times 64bit and encoded in 3000digits, it's arguably already using such formula
ledookyn has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
anholt has quit [Ping timeout: 480 seconds]
guludo has quit [Ping timeout: 480 seconds]
anholt has joined #dri-devel
mvlad has quit [Remote host closed the connection]
Calandracas has quit [Remote host closed the connection]