<enunes>
rellla: I've seen those, my vectorize patchset also indirectly fixed at least one of them
<enunes>
but that pass seems like a good thing to have
<rellla>
enunes: i'm not sure, if it's entirely right to make a zero const out of the undef ssa, but all other driver seem to do the same...
<enunes>
yeah it would be nice to just not do anything rather than probably creating a mov to a field that is probably useless
<enunes>
but it's not even that common and not sure how to solve it otherwise, so I am ok with assigning zero
<rellla>
ok.
jrmuizel has joined #lima
<rellla>
enunes: should i look into the write_mask/swizzle issue in lower_select (and probably others) ot is this expected to be moved out out ppir lowering?
<enunes>
rellla: one thing I'm about to do in the same vectorize patchset is turn selects into scalars because apparently lima can't support the vec4 selects the way nir intends
<enunes>
are there write_mask/swizzle issues in other op lowerings?
<enunes>
or... potential issues
<rellla>
sin/cos is eliminated with the nir MR
jrmuizel has quit [Remote host closed the connection]
jrmuizel has joined #lima
<rellla>
and for the other potential candidates ... i haven't had a look :)
<rellla>
"alu->dest.write_mask = u_bit_consecutive(0, num_components);" or "alu->dest.write_mask = 1;" always is suspicious :p
<enunes>
always confuses me as wel
<rellla>
i just stumbled across it in lower_sin and lower_select. the write_mask was effectively hardcoded to 0001, even if it should write to .y
jrmuizel has quit [Remote host closed the connection]
<rellla>
this is a problem in piglit, where one of two consts (1.0, 0.0, 0.0, 1.0) and (0.0, 1.0, 0.0, 1.0) is probed.
yuq825 has joined #lima
<rellla>
when sth is wacky with .xyzw we get wrong results. especially when we deal with a select...
Unit193 has quit [Read error: Connection reset by peer]
Unit193 has joined #lima
<enunes>
rellla: this is what I'm currently testing before sending the MR for, it creates many more assignments to .y and .z but those still seem to work
<rellla>
enunes: for the lazy rellla... what does BITSET_SET macro do?
<enunes>
we have a bitset called alu_lower which lists the ops that nir_lower_alu_to_scalar will convert to scalar, I'm telling it to also do that for select ops
<rellla>
ah ok
<rellla>
as it probably fixes some dmesg errors according to your comment, i should give it a quick piglit run :)
<rellla>
is there anywhere some doc how to create this shaderdb reports?
<enunes>
this one with the test names is a bit of a hack, but if you run piglit one time with MESA_SHADER_CAPTURE_PATH to collect all shaders, you can just use them later with shaderdb itself
<enunes>
after my MR on it gets merged
<enunes>
just the shader names will be like 3-1212.shader_test 3-2203.shader_test etc
monstr has quit [Remote host closed the connection]
yuq825 has quit [Remote host closed the connection]
<anarsoul>
enunes: I profiled mpv and looks like it spends 10% of time in _mesa_format_convert
<anarsoul>
I think we need to add support for single-component textures
<enunes>
anarsoul: how much work is that?
<enunes>
anarsoul: I tried perf top on my pinebook with Fedora as well and I got nothing, but my perf version doesn't match my kernel so I wonder if that's a problem
<anarsoul>
enunes: not a lot, I believe it's just a matter of adding corresponding enums
<rellla>
fixes/regressions do still look weird within the last ppir instructions ...
<rellla>
lower_select still is untouched
<enunes>
rellla: I figured that when tests result in 0, 0, 0, 0 and that's an impossible result, it's just some random instability that happens for some reason
<enunes>
manually running the test again passes
<anarsoul>
rellla: you probably have to get used with select weirdness in assembler :)
<enunes>
anarsoul: can we use that and turn it into an assert or something so we can fix the unitialized reg to see if that resolves the random failures?
<enunes>
or just print some greppable debug
<anarsoul>
enunes: it's hard
<anarsoul>
and I'm not sure if it's worth the efforts
<MoeIcenowy>
strange...
<anarsoul>
basically it happens when dest doesn't match src
<anarsoul>
in ppir
<MoeIcenowy>
EGL_ANDROID_native_fence_sync doesn't work
<MoeIcenowy>
even EGL_KHR_fence_sync doesn't work
<enunes>
anarsoul: yeah and then, it might also be something in gpir... gpir tests fail at random as well with trivial fragment shader
<anarsoul>
:(
<MoeIcenowy>
does anyone know how the out_sync of submit work?
<anarsoul>
yes, it uses fences
<anarsoul>
enunes: you should probably ask Connor to look into it
<anarsoul>
I can read GP disassembly, but I barely understand the compiler
<enunes>
anarsoul: well since examples with trivial vertex programs also fail, I fear it might be something different like kernel or command stream related
<enunes>
I tried valgrind some time ago, enabled it for all shader_runner examples and run many times, some tests still randomly failed, but no valgrind diffs between the randomly failed and passed runs
<MoeIcenowy>
anarsoul: how does fences work on Lima?
<MoeIcenowy>
I think I got a total mess on fence on Lima when trying on Android
<anarsoul>
MoeIcenowy: see kernel driver, it's not really lima-specific
<anarsoul>
enunes: I'd check shader first though
<anarsoul>
MoeIcenowy: btw, looks like I got rid of RCU stalls
<enunes>
maybe disabling no-concurrency and running tests in parallel can reproduce it more easily
<enunes>
I should try that
<enunes>
with a limited set, and then hopefully be able to bisect it
<anarsoul>
enunes: so maybe uninitialized reg read in GP?
<enunes>
anarsoul: maybe, but I think it will also happen with the trivial passthrough vertex shader
jrmuizel has quit [Remote host closed the connection]