09:04 jani: airlied: linus seems fine with https://lore.kernel.org/r/d69501d53c233386d70ed10290af24aafebf434f@intel.com, will you pick that up as well?
10:09 airlied: jani: yup I've put it on my todo list, hopefully remember to read that tomorrow :-)
10:51 jani: airlied: thanks :)
12:53 melissawen: MrCooper, nice! thanks! A very subtle improvement... I'd say: more laborious than impactful hehehe
12:54 MrCooper: eliminating banding would be a pretty big deal for me
13:01 alyssa: jnoorman: can we revert https://gitlab.freedesktop.org/mesa/mesa/-/commit/a72704d0fbd0dc594570ae2c97b7a8015a944b8e ?
13:02 alyssa: linking interp qualifiers depends on it
13:02 alyssa: or well
13:02 jnoorman: alyssa: hmm, probably not without breaking ir3.
13:02 alyssa: maybe reset to 0 for FRAGMENT only
13:02 alyssa: would that work?
13:06 jnoorman: yeah, looking at `nir_shader_gather_info`, I think that would work. but it feels like the proper solution would be to make sure it actually recalculates those things correctly on asahi as well?
13:10 lucaceresoli: lumag, lumag_, all: as I understand, calling drm_connector_attach_encoder() just after drm_bridge_connector_init() seems to be a mandatory step
13:10 alyssa: jnoorman: you can't recalculate
13:10 alyssa: for VERTEX
13:10 alyssa: since the shader_info field there is used as a sideband to stash the results of linking
13:10 lucaceresoli: and in fact each and every caller or drm_bridge_connector_init() calls drm_connector_attach_encoder() right after
13:11 alyssa: the way this works in opengl, the glsl compiler calls opt_varying_bulk which links stuff but then just passes individual nir_shader's to the driver
13:11 alyssa: so any info about linked shaders needs to be encoded in the nir_shader somehow
13:11 jnoorman: alyssa: ok I see. then I guess only resetting for FS is a good fix.
13:11 alyssa: so either abuse shader info or abuse new intrinsics or somethhing
13:11 lucaceresoli: lumag, lumag_, all: any good reason drm_bridge_connector_init() cannot call drm_connector_attach_encoder() and avoid all callers this step?
13:12 alyssa: jnoorman: it's not asahi specific either, panfrost probably could/should be using this mechanism too
13:12 alyssa: and img
13:14 zmike: seems to me like there shouldn't be multiple users of the same shader info fields
13:15 alyssa: zmike: it's a single mechanism meant to work together
13:15 zmike: but I guess nobody is moving stuff out of the VS so maybe it's fine
13:15 alyssa: gather_info sets for FS, linking copies from FS->VS
13:15 alyssa: propagating backwards
13:15 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/nir/nir_opt_varyings.c?ref_type=heads#L5598
13:17 jannau: I'm testing initialize for FRAGMENT only on asahi
13:22 jannau: that's not enough, looks like the same tests are still failing with https://paste.debian.net/hidden/33df905b
13:54 pq: How does one support KMS hardware that cannot support the plane "pixel blend mode" value "Pre-multiplied", but does support "coverage"?
13:56 pq: How does the driver communicate this to userspace?
14:02 vsyrjala: the property should only expose the supported enum values
14:02 pq: but it is illegal to not advertise "Pre-multiplied"
14:03 pq: says the code
14:04 vsyrjala: which code?
14:04 pq: the kernel common code
14:04 pq: drm_plane_create_blend_mode_property()
14:05 pq: https://docs.kernel.org/gpu/drm-kms.html#c.drm_plane_create_blend_mode_property
14:05 vsyrjala: hmm. looks like nonsense to me
14:05 pq: I agree, this hardware would never have worked with userspace assuming pre-mult anyway.
14:07 vsyrjala: yeah, any argument about requiring if for backwards compatibility with pre-pixel_blend_mode driver doesn't make sense to me
14:08 vsyrjala: such a driver should simply never have exposed alpha formats because they would not have worked correctly
14:09 pq: Yes. But can it expose alpha formats with a "pixel blend mode" list that excludes pre-mult?
14:10 pq: I would hope this does not need a client cap for "I understand and shall check pixel blend mode property".
14:10 vsyrjala: i suppose that could indeed break some ancient userspace. but does anyone actually care?
14:10 pq: *shrug*
14:10 pq: I hope not.
15:58 alyssa: glehmann: i'm wondering if we can memoize the is_only_used_as_float type calculations
15:59 alyssa: to lift the depth restriction on it
15:59 alyssa: on the bcsel propagation thing I mean
15:59 alyssa: & also have it see thru phi's
15:59 alyssa: pinging you because this seems eerily similar to range analysis
16:01 alyssa: For jay, I want to decide between sel.s32/sel.f32, where the latter is allowed to flush denorms
16:02 alyssa: feels probably easier to do at isel time with the NIR than the backend
16:02 zmike: glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15289
16:02 alyssa: & feels like exactly what algebraic already does and any instr count regressions I hit are symptoms of places algebraic itself could be doing better
16:28 glehmann: alyssa: are there many regressions? I always thought it's kind of an edge case
16:29 glehmann: zmike: there are more tgsi backends than virgl (softpipe, i915g, ancient nv), and I doubt anyone wants to spend time rewriting those.
16:30 zmike: 2030 item
16:31 glehmann: but imo it's silly that gallium helpers still emit shaders as tgsi strings
16:32 glehmann: there's also the weird d3d10 frontend that emits tgsi
16:32 zmike: ...maybe we can just delete that like we did to nine
16:36 karolherbst: we should obviously rewrite those helpers to use CLC :P
16:38 glehmann: they are short enough that nir_builder isn't too ugly
16:41 alyssa: glehmann: i'm just down a rabbit hole dont mind me
16:44 MrCooper: Alyssa in Wonderland
19:35 alyssa: anholt: 6 years later are we ready to talk about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5448 again :p
19:36 anholt: oh hey looks like my opinions haven't changed in 5 years.
19:58 mareko: alyssa: yes