ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
phire_ has joined #dri-devel
phire is now known as Guest16878
phire_ is now known as phire
Guest16878 has quit [Ping timeout: 480 seconds]
davispuh has quit [Ping timeout: 480 seconds]
alanc-away has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc-away has quit []
alanc has joined #dri-devel
Calandracas has quit [Ping timeout: 480 seconds]
Calandracas has joined #dri-devel
kasper93 has quit [Remote host closed the connection]
alanc-away has joined #dri-devel
alanc has quit [Remote host closed the connection]
npmania has quit [Read error: Connection reset by peer]
npmania has joined #dri-devel
nerdopolis has joined #dri-devel
parthiban has quit [Remote host closed the connection]
parthiban has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
<Lynne>
AndrewR: version 4 is *experimental*
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
epoch101 has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
Nasina has quit [Read error: Connection reset by peer]
sarnex has quit [Read error: No route to host]
sarnex has joined #dri-devel
glennk has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
kts has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
kts has joined #dri-devel
Duke`` has joined #dri-devel
tlwoerner_ has quit []
tlwoerner has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
slattann has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
Duke`` has quit []
Duke`` has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
sima has joined #dri-devel
itoral has joined #dri-devel
dviola has left #dri-devel [WeeChat 4.6.2]
dviola has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Nasina has joined #dri-devel
Nasina has quit [Read error: Connection reset by peer]
dolphin has joined #dri-devel
Nasina has joined #dri-devel
alarumbe has quit []
fab has quit [Quit: fab]
valentine has joined #dri-devel
<valentine>
looking into those CI issues, I think I see what's going on
fab has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
pixelcluster_ has joined #dri-devel
fantom has quit [Ping timeout: 480 seconds]
pixelcluster has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
tzimmermann has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<dolphin>
airlied, sima: could we get 6.15 backmerge to drm-next? I'd then gladly backmerge that to drm-intel-gt-next where build is breaking without on old GCC at the moment
<sima>
dolphin, you mean the gcc15 fixes from linus or something else?
Nasina has quit [Read error: Connection reset by peer]
coldfeet has quit [Quit: Lost terminal]
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]
Nasina has joined #dri-devel
nerdopolis has joined #dri-devel
Nasina has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
DodoGTA has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
frieder has joined #dri-devel
woskova has quit []
woskova has joined #dri-devel
DodoGTA has joined #dri-devel
itoral has quit [Remote host closed the connection]
alarumbe has joined #dri-devel
jsa2 has joined #dri-devel
kasper93 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
<gio>
Hi, while trying to run vkd3d tests on v3dv (using a Raspberry Pi 4B) I noticed that VK_KHR_shader_draw_parameters isn't available (and is required for vkd3d). Being quite clueless about that GPU (or, for that matter, any GPU) works, I was wondering: is there a fundamental reason why VK_KHR_shader_draw_parameters isn't offered? Or is it just a matter of nobody ever having cared
<gio>
enough about it?
<gio>
In other words, is that something somebody who doesn't know a lot about Mesa might figure out in their spare time, or is there some substantial work to be done?
hansg has joined #dri-devel
JLP has joined #dri-devel
jsa2 has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
jsa1 has joined #dri-devel
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
<alyssa>
mareko: I'm looking at enabling the 16-bit caps for asahi (mostly out of curiousity), noticed something really problematic in shaderdb
<alyssa>
for reasons I don't fully understand, a bunch of shaders get store_output(undef) to non-existant render targets. ok, that all gets optimized out by nir_opt_undef, that's fine
<alyssa>
with the 16-bit i/o lowering, we first get instead store_output(f2f32(undef))
<alyssa>
nir_opt_undef turns that into store_output(nan) and suddenly a bunch of frag shaders go from 1 instruction to 20 because of a pile of NaN moves
<alyssa>
if I disable undef->nan optimization, later i/o lowering turns to store_output(f2fmp(f2f32(undef)) which folds to store_output(undef) and then gets deleted as it should be.
<alyssa>
Not really sure how to solve this properly though, there seems to be a bunch of layers of "sketchy" interacting
warpme has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
fab has quit [Quit: fab]
<lumag>
Current drm-tip fails to merge drm-xe-next, but I don't feel brave enough to handle that merge conflict.
<lumag>
jani: ^^
cyrinux94907 has quit []
lsntvt_ has quit [Ping timeout: 480 seconds]
cyrinux94907 has joined #dri-devel
Nasina has joined #dri-devel
Caterpillar has quit [Ping timeout: 480 seconds]
mareko_ has joined #dri-devel
dri-logg1r has joined #dri-devel
kzd has joined #dri-devel
mareko has quit [Ping timeout: 480 seconds]
dri-logger has quit [Ping timeout: 480 seconds]
dri-logger has joined #dri-devel
mareko has joined #dri-devel
mareko_ has quit [Ping timeout: 480 seconds]
dri-logg1r has quit [Ping timeout: 480 seconds]
Nasina has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
warpme has quit []
jsa1 has quit [Remote host closed the connection]
davispuh has joined #dri-devel
dri-logg1r has joined #dri-devel
mareko_ has joined #dri-devel
dri-logger has quit [Read error: Connection reset by peer]
mareko has quit [Read error: Connection reset by peer]
<alyssa>
nir_lower_pack needs to die ;;
mareko_ has quit [Ping timeout: 480 seconds]
dri-logg1r has quit [Ping timeout: 480 seconds]
mareko_ has joined #dri-devel
mareko_ is now known as mareko
Duke`` has joined #dri-devel
<mareko>
alyssa: we could look deeper into uses of undef (such as f2fN) and if they only lead to stores, we could remove that store instead of replacing undef
<alyssa>
mareko: Is that... correct?
<alyssa>
I genuinely don't know
<alyssa>
what if you loaded the output value after doing store_output(f2f32(undef)) - shouldn't that load an indeterminate value that is rounded to 16-bit quantizing?
<alyssa>
(nir's undefs are such a disaster.)
<mareko>
alyssa: we could say that removing stores with undef isn't correct because something else could expect a load to return an undefined but fixed value
<mareko>
alyssa: the only "disaster" is the removal of store(undef)
dri-logger has joined #dri-devel
<alyssa>
no I mean fundamentally the way we have undef specced in NIR is a mess
<mareko>
and also branches with if (undef)
<alyssa>
(this is not new and it's not your fault)
<alyssa>
(and we all know this but also lol what do we do about it now)
<mareko>
I guess it's undefined whether undef means "undefined fixed value" or "anything goes"
<alyssa>
it's deeper than that
<alyssa>
but I don't really want to rehash that rn
<glehmann>
spir-v's undef definition isn't more relaxed than NIR either
<alyssa>
(that papers about llvm but mesa likely has the same bugs)
<demarchi>
lumag: fixed
<mareko>
LLVM used to be far more broken than Mesa, basically any use of undef would result in the removal of most instructions using it, not replacing with a fixed value
<alyssa>
that I believe yea
<alyssa>
llvm's definitely more aggressive than we are
Caterpillar has joined #dri-devel
dsimic is now known as Guest16926
dsimic has joined #dri-devel
<mareko>
alyssa: I have no suggestion other than removing store([fui]2[fui]N(undef))
<alyssa>
wheee
<alyssa>
no worries
<alyssa>
i'm currently being grumpy about nir_lower_packing
Guest16926 has quit [Ping timeout: 480 seconds]
lsntvt has joined #dri-devel
kts has joined #dri-devel
<alyssa>
..yeah this mess is too deep for me to think about anymore today, nvm
<mareko>
alyssa: is removing store(f2fN(undef)) not viable?
<alyssa>
mareko: it's not sound
<alyssa>
although my last comment was referencing nir_lower_pack
<alyssa>
i think that's my cue to crawl back into my cave for the morning
slattann has quit [Ping timeout: 480 seconds]
<mareko>
alyssa: what's the concern with the removal? we already remove store(undef), which is not less incorrect in theory
<alyssa>
mareko: if you load after a store(undef), it could be anything which matches what you'll load (which could also be anything)
<alyssa>
if you load after store(f2f32(undef)), it could only be a value that you could get out of f2f32, which is only about 0.0015% possible values
<alyssa>
statistically whatever garbage you load if you don't do the store is not in that <0.01% of possibilities
<alyssa>
so removing the store isn't sound
<alyssa>
(but replacing it with store nan as we do now is fine.)
phasta has quit [Quit: WeeChat 4.6.2]
<mareko>
removing store(undef) is also incorrect because the next load doesn't get the stored value
<alyssa>
..so it is.
<alyssa>
wait, no that's fine
<alyssa>
store(undef) can be removed because whatever is currently in memory is perfectly good value of undef
<mareko>
x = undef; store(addr, x); .. then load(addr) == x must be true, no?
<alyssa>
only if undef is frozen, not Undef
<alyssa>
like i said. this is going in circles.
<alyssa>
i'm going to log off now.
<mareko>
ok
tzimmermann has quit [Quit: Leaving]
<karolherbst>
I think this entire undef business is something that the spirv WG has to decide or explicitly state, but I've heard they also don't know how to define undef, so... I think the only way to fix is, to make spir-v undef to be truly undef, add poison/freeze semantics to spirv, do the same for nir and then it's all explicit, but.. that's a bunch of work
<karolherbst>
:)
<karolherbst>
but yeah.. a true undef value doesn't compare to itself as equal, an undef out of a (undef % 1) can be any value, it doesn't have to adhere to the inherent characteristics of the operation. Like (undef * 2) & 1 doesn't have to be 0, it can be 1
<karolherbst>
but that all depends on how you define undef. If it's frozen by default, then the semantics are more strict
<glehmann>
the current spir-v spec reads to me like OpUndef can have different values per use, but something like undef & 0 is 0, not undef
<pendingchaos>
isn't the "(undef * 2) & 1" only for poison? I'm not sure if undef propagates like that
<pendingchaos>
though NIR also optimizes phi(undef)/mov(undef) to undef
<karolherbst>
my point was it depends on how you define it
<karolherbst>
which atm isn't defined at all
<karolherbst>
but I do think that spir-vs wording is close to "undef is frozen"
<karolherbst>
but not if you read the undef value a couple of times
<karolherbst>
it's not great
<karolherbst>
like yes you _could_ argue that "undef * 2" reads undef only once, but where is that written?
<karolherbst>
what if undef * 2 reads undef twice, and undef * 10 reads undef 10 times?
bolson has joined #dri-devel
<glehmann>
it's not frozen, otherwise the spec would talk about "Each consumption"
<karolherbst>
it doesn't say what a consumption is
<karolherbst>
for all I know, opimul can consume each value 100 times
<karolherbst>
where is it stated that opcodes only consume each input exactly once?
<glehmann>
nowhere I guess, but it's clearly not frozen
<cwabbott>
I argued about this millenia ago and can confirm the intent was to match llvm's semantics at the time (i.e. not frozen)
<karolherbst>
fair
<karolherbst>
things are easier to argue on for like opcodes, but what if you pass a value as a function parameter? What if you need to lower the opcode to 100 instructions?