09:10 valentine: pac85: `./piglit run gpu -t 'spec@arb_texture_rg@texwrap formats-float bordercolor.*' results`
09:11 valentine: and results.json will have the subtests: "gl_r16f, swizzled, border color only": "pass",
09:17 valentine: or actually "gl_r16f, border color only": "pass", from your example
13:29 karolherbst: rusticl gets hit my libstdc++ symbol conflicts :') https://gitlab.freedesktop.org/mesa/mesa/-/issues/14090#note_3182691
13:34 karolherbst: sooooo... what's the proper way to fix those kind of issues?
13:34 karolherbst: like how can I ensure that mesa will only ever call into c++ symbols from the system libstdc++ lib
13:46 karolherbst: seems like "-static-libstdc++" solves it mhh..
14:24 pac85: valentine: that worked, thanks!
16:29 alyssa: pendingchaos: looking at ballots / ballot_relaxed in aco .. Is there anything that optimizes out the &execution_mask for convergent control flow?
16:30 alyssa: does it make sense to lower ballot -> ballot_relaxed at the NIR level in nir_lower_subgroups?
16:46 pendingchaos: not exactly in convergent control flow, but it does optimize out the &exec if thinks it's already masked (can_eliminate_and_exec() in aco_optimizer.cpp)
16:46 pendingchaos: also optimizes s_cselect(-1, 0, a)&exec -> s_cselect(exec, 0, a)
16:46 pendingchaos: maybe there's room for improvement if we know exec=-1, since that s_cselect thing is limited
16:48 alyssa: Hmm, ok, so it's an aco backend thing
16:49 alyssa: I guess aco_optimizer is also CSE'ing ballot(true) and stuff like that?
16:49 alyssa: or well aco's value numbering rather
16:49 pendingchaos: it's in aco_opt_value_numbering.cpp, but should be yes
16:49 alyssa: right ok. because NIR definitely doesn't do that (:
16:50 alyssa: incidentally I still don't understand the difference between value numbering and CSE
16:50 alyssa: but have always been too afraid to ask ;)
16:53 alyssa: thanks
16:54 pendingchaos:doesn't either
18:53 pac85: I'm sure some player would be upset about that one pixel differing by a unit in the blue channel https://mesa.pages.freedesktop.org/-/mesa/-/jobs/87465111/artifacts/results/summary/results/trace@zink-radv-vangogh@supertuxkart@supertuxkart-ravenbridge-mansion.rdc.html
19:24 idr: pac85: Could be worse... we had a bug years ago where the light blue trails Tux left in the snow were bright red.
19:24 idr: It was quite a thing to see. And then never unsee.
19:59 pac85: idr: some bugs are art. Though those failures in traces in my branch might be more like precision issues stemming from rearranging ops
21:35 alyssa: that's pretty typical
22:01 mareko: Kayden: I don't think any hw can do writemasks for memory ops
22:10 mareko: AFAIK, the difference between CSE and GVN is that GVN sees a+b and b+a as equivalent, while CSE doesn't; also GVN considers %0 and %1 equivalent where %0 = a+b, %1 = %0, so it's like CSE combined with copy prop
22:16 mareko: GVN could do CSE with commutativity, copy prop, constant folding, and some DCE at once I think
22:21 mareko: our CSE (via instr_set) handles commutativity though
22:36 austriancoder: mareko: vivante isa uses writemask for memops, e.g. loading a 64bit value from memory : load.denorm.u32 t1.xy, t0.x, 0
22:37 mareko: I mean for stores
22:40 austriancoder: mareko: store r1.xx at address r0.x with offset of 8: store.denorm.u32.xz r0.x, 8, r1.xxz