<kusma>
airlied: lp_build_insert_soa_chan doesn't seem to handle the cases where chan_desc.type == UTIL_FORMAT_TYPE_UNSIGNED / UTIL_FORMAT_TYPE_SIGNED and *both* chan_desc.pure_integer and type.floating is true...
<kusma>
That is, writing float-values into formats like r8i / r16i etc...
<kusma>
In that case, we only consider pure_integer, and bitcast the float to int, it seems.
<kusma>
I'm a bit confused, because I don't see failures on LLVMpipe for this... but I do see it fail with Zink + Lavapipe...
<kusma>
I'm a bit confused why there's an incoming float here rather than an int...
<kusma>
OK, that seems like it might be because st_pbo copies through a float... which seems like a bad idea to me.
<kusma>
(nan-flushing, anyone?)
<zmike>
llvmpipe wouldn't take that codepath because it does cpu texture population
<zmike>
using the cpu map codepath
<kusma>
zmike: Yeah, true.
<kusma>
But I also don't see any other failures for r8i images etc
<zmike>
in llvmpipe?
<kusma>
Yeah
<zmike>
probably just not hitting the exact case in any test that doesn't use the alternate pbo path
<kusma>
Yeah, could be that the PBO-case does something that isn't really legal in GL or something
<zmike>
mesa-internals aren't restricted to doing what GL can do, only what drivers can do
<kusma>
exactly
<kusma>
zmike: Yeah, you're right. This is not legal in GLSL, so I guess that's why it's not causing any issues there.
<kusma>
imageStore() requires that the image type and value have the same type.
<kusma>
But SPIR-V also have the same limitation, so I guess we have the same problem on the Zink-end...
<kusma>
(only legal in SPIR-V for CL, not Vulkan)
<kusma>
Or maybe I'm confusing things a bit now...
<kusma>
Yeah, we're just doing a bitcast here. Which isn't going to do the right thing :/
<kusma>
Hmpf, but we're doing the same on ANV, where things work...
hch12907_ has joined #zink
hch12907 is now known as Guest729
hch12907_ is now known as hch12907
Guest729 has quit [Ping timeout: 480 seconds]
hch12907 has quit [Remote host closed the connection]
hch12907 has joined #zink
hch12907_ has joined #zink
hch12907 is now known as Guest731
hch12907_ is now known as hch12907
Guest731 has quit []
<kusma>
zmike: Hmmpf, seems there's a *lot* of completely valid validator errors in this test (KHR-GL32.packed_pixels.pbo_rectangle.r16i on ANV)... I've disabled EXT_extended_dynamic_state to avoid the obvious validator-derp stuff...
<kusma>
Lots of these things "VkDescriptorSet 0x4c400000004c4[] encountered the following validation error at vkCmdDraw() time: Descriptor in binding #544 index 0 requires FLOAT component type, but bound descriptor format is VK_FORMAT_R16_SINT."
<zmike>
that's the same thing you just complained about with copying int formats using float
<zmike>
not my problem
<kusma>
Yeah, seems you're right. I think I have a fix for that.
<kusma>
And with that fixed... We also fail the test on ANV :P
<zmike>
"fixed"
<kusma>
What could possibly go wrong?!
<kusma>
Look, the validator tells me I'm doing everything correct. Apart from barriers, it doesn't like the access bits there.
<kusma>
Cool. Not trying to shovel things over on you here, just debugging out loud ;)
_whitelogger has joined #zink
<kusma>
Nevermind, the test passes. I was just being stupid.
<hch12907>
I noticed there's quite a lot of C99 VLA in nir_to_spirv... are there any particular reasons of using it? (e.g. avoiding heap allocation in hotpath)
<hch12907>
I was looking at issue #4854, for context
<zmike>
no particular reason that I'm aware of
jekstrand has joined #zink
<kusma>
That's probably laziness on my end. I'm all for fixing it!
<hch12907>
some of them are fairly trivial, I can simply replace num_components with NIR_MAX_VEC_COMPONENTS
<hch12907>
but others like `SpvId src[nir_op_infos[alu->op].num_inputs]`... not so much
<hch12907>
we don't have a NIR_ALU_MAX_INPUTS lying somewhere in the headers :P
<jekstrand>
It's the same as MAX_VEC_COMPONENTS
<jekstrand>
vecN is the biggest ALU op
<jekstrand>
We should really have a #define for that too. I'd not be opposed to someone adding one.
<jekstrand>
But MAX_VEC_COMPONENTS is sufficient, probably
<jekstrand>
There is a MAX_INPUTS thing for intrinsics, I think.
<jekstrand>
Maybe we should add one for ALU
<hch12907>
I saw there is a MAX_INPUTS for intrinsics, but nothing for other instructions
<jekstrand>
Only intrinsics and ALU really have a max and, for ALU, it's MAX_VEC_COMPONENTS
<jekstrand>
THough, like I said, I wouldn't be opposed to a `#define NIR_ALU_MAX_INPUTS NIR_MAX_VEC_COMPONENTS` with a comment saying that vecN is the widest ALU op.