<eric_engestrom>
zzyiwei: yeah, I have some medical stuff planned and I haven't figured out when I'll be able to make releases, that's why it's not in the calendar yet
<eric_engestrom>
I'll be out starting on oct 22 (maybe 21), and I'm not sure how long until I'm able to do things; medical leave is 6 weeks, but given that release work is not a full day of work and I do it from home (and if it's too painful to sit I can just stop and resume another day), I think I'll try to do it after 2 weeks and see how it goes
<eric_engestrom>
the branchpoint would normally be on the week before that, but I think there's no point branching and then just leaving it sitting for weeks, diverging for no reason, so I think I'll put the branchpoint 2 weeks after my surgery, ie. on Nov 5
<eric_engestrom>
thanks for prompting me to actually think it through 😊
<eric_engestrom>
I'll update the calendera with that
hansg has joined #dri-devel
jsa2 has joined #dri-devel
The_Company has joined #dri-devel
danylo has quit [Read error: Connection reset by peer]
jsa1 has quit [Ping timeout: 480 seconds]
kasper93 has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
olivial has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
olivial has joined #dri-devel
jsa2 has quit [Remote host closed the connection]
danylo has joined #dri-devel
dsimic is now known as Guest26760
dsimic has joined #dri-devel
Guest26760 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
YuGiOhJCJ has quit []
<eric_engestrom>
(changed my mind, I'll try to do it after one week, meaning 25.3 is pushed back by only 2 weeks)
vliaskovitis has quit [Remote host closed the connection]
opotin has quit []
frankbinns has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
epoch101 has joined #dri-devel
davispuh has joined #dri-devel
clamor has quit [Read error: Connection reset by peer]
frankbinns has quit [Remote host closed the connection]
lsntvt has quit [Remote host closed the connection]
lsntvt has joined #dri-devel
davispuh has quit []
davispuh has joined #dri-devel
frankbinns has joined #dri-devel
frankbinns has quit [Remote host closed the connection]
dsimic has quit [Quit: Going offline for now]
dsimic has joined #dri-devel
pixelcluster has quit []
pixelcluster has joined #dri-devel
alyssa has joined #dri-devel
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
dolphin has quit [Quit: Leaving]
kzd has joined #dri-devel
haaninjo has joined #dri-devel
<dcbaker>
eric_engestrom: Would you like help with the next release?
<eric_engestrom>
talked in private, dcbaker will take the 25.3 release cycle, and it will happen at the normal schedule (branchpoint on oct 15) :)
phasta has quit [Quit: WeeChat 4.6.2]
Duke`` has joined #dri-devel
Peuc has quit [Quit: Peuc]
Peuc has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
ahadi has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
idr has joined #dri-devel
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #dri-devel
epoch101 has joined #dri-devel
<zzyiwei>
eric_engestrom: Oh my...no worries about the next release. At least there's no urgency from our end. Please take good care of yourself and I hope you have a good recovery from your surgery!
<eric_engestrom>
zzyiwei: thank you ❤️ fyi the 25.3 release cycle will be managed by dcbaker so it will not be delayed and not require anything from me :)
epoch101 has quit [Ping timeout: 480 seconds]
anholt has joined #dri-devel
pzanoni has joined #dri-devel
bolson has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
jsa2 has joined #dri-devel
kts has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
epoch101 has joined #dri-devel
chewitt has quit [Quit: Zzz..]
frankbinns has joined #dri-devel
clamor has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
jsa2 has quit [Ping timeout: 480 seconds]
blaztinn has quit [Remote host closed the connection]
blaztinn has joined #dri-devel
bonzini has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
<simon-perretta-img>
Aside from the opcode count increasing and the fact that most drivers don't seem to need/use vec widths other than 2..5/8/16 in NIR, are there any other obvious reasons I might be overlooking for not having more?
agd5f_ has quit [Read error: Connection reset by peer]
ahadi has joined #dri-devel
agd5f_ has joined #dri-devel
<dj-death>
simon-perretta-img: I think ALU instruction side
<dj-death>
simon-perretta-img: I tried to propose vec32 at some point
<dj-death>
alyssa: you might remember why
<simon-perretta-img>
Ah... yeah that makes sense for upping the limit
<alyssa>
swizzle[]
Gatherer has joined #dri-devel
<alyssa>
swizzle[] is on every nir_alu_src and sized to maximum vec length
<alyssa>
if you double the vec length every ALU instruction bloats accordingly
<alyssa>
going 16->32 makes every ffma grow by 48 bytes
<alyssa>
if someone could make swizzle[] not worst-case allocated I wouldn't care
<alyssa>
but so far no takers on that
<alyssa>
(Part of me would like to just remove swizzles from NIR but unfortunately that's a nonstarter.)
<simon-perretta-img>
Fair
<simon-perretta-img>
Although in which case, I guess defining some of the ops between 5,8,16 without upping the limit probably wouldn't be too controversial?
<alyssa>
That'd probably be fine yeah
<simon-perretta-img>
There are some pco-specific reasons for wanting to, but also I imagine nir_opt_load_store_vectorize would benefit from it
<alyssa>
If you need vec7 or something, go for it
<alyssa>
but no vec32 unless it comes with a patch to shrink nir_alu_src
<simon-perretta-img>
Haha noted
* simon-perretta-img
sweeps Rogue DMA ops that can output vec1024 under the rug
<alyssa>
Yeah no
<alyssa>
Find another solution, vec1024 is not your solution.
<simon-perretta-img>
Dw I wasn't being serious lol, the most that would ever realistically be needed is a vec18 or something
<alyssa>
dj-death: If we still need vec32, lmk. now that I'm team bleu I might be more motivated to try to wrestle swizzle[]
<alyssa>
("Team Bleu? Is that French?" "Non it's just a cheesy joke")
<HdkR>
Variable length NIR instructions weeee
<alyssa>
HdkR: It's already var length
<HdkR>
Dang
<alyssa>
it's just an array-of-struct-of-arrays where the outer array is var and hence the inner cannot be
<HdkR>
ah
<jenatali>
Make swizzle into a pointer which can point after the sources to a second variable-length chunk of memory? Then null can be "no swizzle"
<jenatali>
Though that makes it hard to convert from no swizzle to have a swizzle
<jenatali>
Eh, can just reallocate the instruction with swizzles, not that bad probably
<alyssa>
That's going to slow down the common cases with e.g. simple non-identity swizzles
Gatherer has quit [Read error: Connection reset by peer]
<alyssa>
lots of pointer chasing
<alyssa>
so would need minimally like a tagged pointer thing
Gatherer has joined #dri-devel
<jenatali>
If it's to the same block of memory though it should be cache-friendly
<alyssa>
"inline small swizzle or pointer to large swizzle"
<jenatali>
Oh, for vec sizes < 8 yeah it could just be inline
<dj-death>
alyssa: it would help for load uniform blocks
<dj-death>
alyssa: right now we're limited at 16 * 4 = 64B
<alyssa>
dj-death: Is that enough of a reason to burn a month on this? :(
<dj-death>
alyssa: but we could load 128 with 32 items
<dj-death>
alyssa: really a month? :)
<dj-death>
alyssa: I thought that would be an afternoon for you
<alyssa>
Probably.
<alyssa>
No
<alyssa>
would need replumbing swizzles in 20 backends
<dj-death>
arg
<jenatali>
Does it really need to return an immediately ALU-able vec32 or could it return something else opaque that has smaller vectors extracted from it?
<dj-death>
well just do ours, throw it at perf CI and if the number look good...
<dj-death>
jenatali: could be opaque
<alyssa>
I like opaque tbh
<dj-death>
but then we don't get the vectorizer
<jenatali>
Hm, true
<alyssa>
We could standardize Big Vectors in nir, though
jkrzyszt has quit [Quit: Konversation terminated!]
<alyssa>
common intrinsics to swizzle/extract/build? them
<jenatali>
Seems reasonable to me
<alyssa>
makes vectorizer messier but then simplifies everything else
<alyssa>
and then ideally we would make spirv-to-nir handle vec16 as big vec
<jenatali>
At that point I wonder if you could drop ALU vec size back down? Probably not though
<alyssa>
so we can shrink swizzle[] back down to 8
kts has quit [Quit: Konversation terminated!]
<alyssa>
jenatali: Should be able to. No Mesa driver does vec16 ALU in hardware, it's just there because of OpenCL
<jenatali>
Oh cool, I'd assumed someone could do some 8x16 or something
<alyssa>
Midgard is capable of doing vec16 alu but it's not wired up and I'm nak'ing anyone who tries.
<simon-perretta-img>
I imagine that opaque approach could also be nice for being able to do things like indexable regs without having to use scratch mem
<jenatali>
:P
<alyssa>
as the original author of an unmainted compiler, I retain NAK rights
<alyssa>
:p
Gatherer has quit [Remote host closed the connection]
<alyssa>
simon-perretta-img: we already have that lol
<alyssa>
anholt: nir patch is a-b me, not sure you're going to get a good review on that
<jenatali>
alyssa: One random thought - DXIL is actually adding arbitrary length vectors, so if there were intrinsics to operate on NIR "big vec" to do basic things like add/sub/mul without swizzles, I could translate those and get more compact shaders
<alyssa>
but feel free to merge
<alyssa>
jenatali: Yeah there's really two ways we could do this
<anholt>
alyssa: I've been thinking about taking a stab at tuning someone else's driver about vars-to-scratch to increase interest. but, also, I need to sort out this copy prop vars masking because that's so much bigger of a deal and affects the same area.
clamor has quit [Ping timeout: 480 seconds]
<alyssa>
jenatali: One is "big vec" is an opaque handle in NIR (like how nir reg works) and you need to do an extract/swizzle intrinsic to pass it to ALU
<alyssa>
The other is having actual vec128 (or whatever) in NIR, and you can pass it into nir_alu_src[], but it's automatically an identity swizzle (and you need a special intrinsic to swizzle non-identity)
<alyssa>
Both of these are ugly but could be made to work
<jenatali>
Yeah I like that latter one, that seems useful
<alyssa>
Both seem like a /lot/ of work to fix up all the producers. Idk
<alyssa>
The latter has the benefit that it can at least be done incrementally with a nir_validate check
<alyssa>
(and gives a path to shrinking all the way down to vec4 swizzles if that ends up faster.)
<alyssa>
anholt: Yeah that's fair
<simon-perretta-img>
Is the reasoning behind swizzle being integrated into nir_alu_src rather than e.g. a separate swizzle op, to save a level of indirection?
<alyssa>
historical reasons basically
<simon-perretta-img>
Mm, fair
<alyssa>
but see also "we have 20 backends which means any nontrivial change to core NIR data structures costs 10s of 1000s of dollars of engineering time"
gatherer_ has joined #dri-devel
Gatherer has quit [Read error: No route to host]
<alyssa>
what I like about the latter approach is that only NIR producers really get changed
<alyssa>
and only producers that mess with swizzle[] manually, pure nir_builder stuff doesn't change
rasterman has quit [Quit: Gettin' stinky!]
gatherer_ has quit [Ping timeout: 480 seconds]
yogesh_m1 has joined #dri-devel
yogesh_mohan has quit [Ping timeout: 480 seconds]
testaccount has joined #dri-devel
<ukleinek>
is it better to report nouveau bugs on the ML or in the bug tracker?
<anholt>
tbh I wish we could convince meson to put deps on mesutil finishing before moving on to anything else. u_format generation dep correctness is just sisyphean.
<gfxstrand>
Yeah, generated headers are just cursed from a build system POV.
<gfxstrand>
We have some generated headers for Vulkan as well and eesh.
jsa1 has quit [Ping timeout: 480 seconds]
Gatherer has quit [Read error: Connection reset by peer]
gatherer_ has joined #dri-devel
Jeremy_Rand_Talos_ has joined #dri-devel
dsimic has quit [Quit: Going offline for now]
dsimic has joined #dri-devel
gatherer_ has quit [Read error: No route to host]
Gatherer has joined #dri-devel
Gatherer has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Ping timeout: 480 seconds]
epoch101 has quit []
glennk has quit [Ping timeout: 480 seconds]
Gatherer has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
Gatherer has quit [Read error: No route to host]
Gatherer has joined #dri-devel
<anholt>
ooh, https://reviews.llvm.org/D83032 looks like it could automated detect missing C/C++ header deps for the builds we do in CI.
<anholt>
someone should do something about that.
<anholt>
(gives me a distressing number of plausible-looking failures on my build)
<mattst88>
I haven't tested it myself, but another gentoo dev has a script that finds missing deps in build.ninja files