00:21 mareko: tarceri: yes texcoord packing is disabled with sprite_tex_disallowed=false
00:24 tarceri: yeah looke like that param should just be removed
00:25 mareko: a shader variant could optimize it, but yeah it's currently dead code
00:28 tarceri: optimise outputs is currently not optimal as it only works if the entire slot can fit in backing, and earlier user packing passes can make the user vars to big to fit
00:28 tarceri: *in packing
00:28 mareko: it's only good for SSO
00:28 mareko: nir_opt_varyings is for linked shaders
00:29 mareko: it only combines color outputs for linked shaders
00:31 mareko: we could lower colors before nir_opt_varyings using front_face, but the problem is that front_face reduces our pixel throughput by 50% in some cases, which is why we have overly complex optimizations for color inputs
00:33 tarceri: with the current var loactions its not possible to trigger the theoretical bug with clamping on back color
00:33 mareko: indeed
00:37 tarceri: I tried with gl_FogFragCoord but it just gets lowered to a user var
00:38 mareko: nir_opt_varyings moves it to VARn, but it stays FOG with SSO
00:38 tarceri: hmm ok I'll play around with SSO
00:42 mareko: glehmann: 1) a varying for 2 views needs to be exported twice, and PS could offset LDS for view 1 input loads, or 2) if the computation of 1 output for 2 views has very few differences, the SSA dominating both results in the def-use graph can be exported instead and the computation can be moved to PS, or 3) the pre-rast shader can export vertices and primitives for each view separately, which should be
00:42 mareko: faster because NUM_INTERP reduces PS wave launch rate and thus pixel throughput
00:45 mareko: an instanced draw would be close (3) and could beat everything else
00:46 mareko: *close to
01:38 karolherbst: *sigh* it looks like I need to add another pipe_cap for clear_buffer. I kinda want to know when drivers are hardware accelerating it. And then there is zink where it's hardware accelerated with a pattern size of 4 or lower... and then only if the size is a multiple of 4...
01:39 karolherbst: asahi is falling back to u_default_clear_buffer for a size >= 16
01:42 karolherbst: mhhh.. maybe I should change the interface of clear_buffer to return a bool and take a bool "force_accelerated" param and then drivers return true/false depending on stuff
01:42 karolherbst: zmike: any particular reason why zink doesn't call u_default_clear_buffer inside zink_clear_buffer?
06:10 MoeIcenowy: alyssa: I wonder how HK finally handle the quirk mentioned in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21978
06:10 MoeIcenowy: it seems that it's another thing common between AGX and PVR
06:11 MoeIcenowy: (found this when running ES2 CTS before Mesa PVR exposing non-seamless cube
09:39 tomba: We have mode and adjusted_mode in the crtc state, and that defines sync polarities. And we have bridge state's input and output bus cfg, for e.g. DE polarity. The problem is, for sync polarities we only have the adjusted_mode, which has the syncs the crtc will send, and mode, which is the supposed end result at the connector. But there's no way to define required sync polarities inside the bridge chain. Is that right?
10:33 zmike: karolherbst: probably zink's implementation existed before the util ?
12:13 alyssa: MoeIcenowy: hk doesn't handle it because there was never CTS added for it