ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #zink
<zmike> ajax: any luck with buffer age?
<anholt> well, perhaps zink exploding this nice shader out to being 64k instructions is part of zink perf issues /o\
<anholt> pretty sure
<zmike> ah :/
<anholt> for temps
<anholt> don't care about i/o
<zmike> yeah it's kinda all the same in terms of fixing iirc
<zmike> it's paged pretty far out atm though
LexSfX has quit [Read error: Connection reset by peer]
LexSfX has joined #zink
<zmike> ooooooo
<anholt> hoping you've got something laying around for samplemask. I tried hacking various things in to make samplemask make more sense to me, with no luck.
<zmike> uhh
<zmike> I can take a look, not entirely sure what the issue is
<zmike> do you have an example test case?
<anholt> KHR-GLES31.core.sample_variables.mask.rgba8ui.samples_0.mask_5
<zmike> k, lemme build and see what I can see
<anholt> messing around with fixing this cs is not really where I should be focusing. it's just that when I dumped shaders it made it hard to find any other shader's content :)
<zmike> yeah I always groan when I see the results of this in something I need to debug
<anholt> oh, and this MR had some store type mismatches once !18259 lands
<anholt> (16 vs 32)
<zmike> grimace
<anholt> possibly store_shared and friends need uint_type to use the instr's bit_size?
<zmike> uhhh
<zmike> hm
<anholt> oh, but in that theory this MR shouldn't be implicated, then.
<zmike> tentative yes in that I think I might have handled the zink_compiler part for that correctly?
<anholt> and, yeah. looks like that MR does break zink+turnip. will sort that out.
<zmike> almost figured out the samplemask thing...
<zmike> what the
<zmike> ohhhhhh
<zmike> hahaha
<zmike> this is from before erik saved us all with type caching
<kusma> ??? :)
<kusma> some manual caching left over somewhere? :)
<zmike> ugh this is really stupid...
<zmike> anholt: how do builtin function temps work with variable locations?
<anholt> not sure what you mean?
<zmike> like in this test there's a function temp samplemask variable
<zmike> it has location=FRAG_RESULT_SAMPLE_MASK
<zmike> is that reliable for temp vars in fragment stage?
<zmike> or coincidence
<anholt> coincidence, you shouldn't be looking at the location for a function temp
<zmike> didn't think so
<zmike> hmmmm
<zmike> ah
<zmike> I was looking too deep
<anholt> "Type mismatch for SPIR-V SSA value 369636 bytes into the SPIR-V binary" what if I don't want to look 370kb into a spirv binary, huh? have you considered that?
<zmike> I doubt it considered that at all
<zmike> k, got it
<anholt> is there a way for me to cast the type of my shared mem's pointer?
<anholt> (the var is array of u32, I need to be able to do a 16 bit store)
<zmike> you mean ctx->shared_block_var ?
<anholt> yeaaaaaah
<anholt> sorry, gnome-shell's key repeat is busted right now
<zmike> no, it'll need the same treatment as ctx->ubos and ctx->ssbos
<zmike> a familiar scenario
<zmike> I can hack something out for you to test if that's easier
<zmike> lmk, I'm over here trying to see how many errors I can get gcc to throw on one file
<anholt> I'm seriously confused by ctx->ssbo_vars -- it seems to be a single nir_variable, regardless of how many ssbos are used?
<zmike> correct
<zmike> all the ssbos are rewritten as an array
<zmike> oh ho ho now I've found a big pocket of cpu overhead
<zmike> up by almost 50% over radeonsi in drawoverhead
<ajax> zmike: not yet but also been afk for non-work reasons. !18214 had some pokes in the area but didn't fix any tests or anything
<zmike> ajax: np, just checking
<zmike> I saw !18214 and was hoping someone more expert would review it
<ajax> imma just land it at this point, it's not like i'm going to find another person willing to claim to know x11
<ajax> which is the only unreviewed bit iirc
<zmike> lemme get in there with an ack real quick
<zmike> so there's someone to blame later
<ajax> ta
<daniels> sometimes I do
omegatron has quit [Quit: What happened? You quit!]