01:02 Ryback_: folks, anybody knows whether F43 will update to Mesa 25.2.8?
01:19 airlied: last week someone said in a week or two they might have time
07:37 linkmauve: Hi, with the new (?) IN_FORMATS_ASYNC property, is the compositor meant to put the supported formats/modifiers in a higher priority tranche for clients?
07:38 linkmauve: I understand it as a way for compositors to not bother doing an async page flip if the client didn’t use a compatible format/modifier pair.
07:49 jannau: Ryback_: based on https://src.fedoraproject.org/rpms/mesa/pull-request/100 it might be skipped and f43 will get mesa 25.3.4 though
10:04 linkmauve: > 19:04:17 alyssa> cwabbott: https://docs.mesa3d.org/drivers/panfrost/drm-shim.html
10:04 linkmauve: > Additional GPU IDs are enumerated in the panfrost_model_list list in src/panfrost/lib/pan_props.c.
10:04 linkmauve: This list doesn’t exist any longer, in that file or anywhere else in Mesa.
12:03 lucaceresoli: Hello, I'm in trouble trying to apply this fix to a bridge driver:
12:03 lucaceresoli: https://lore.kernel.org/all/20260123-imx8qxp-drm-bridge-fixes-v1-3-8bb85ada5866@nxp.com/
12:03 lucaceresoli: The fix should go to drm-misc-next-fixes according to https://drm.pages.freedesktop.org/maintainer-tools/committer/committer-drm-misc.html but it does not apply there due to a conflict with an unrelated change.
12:04 lucaceresoli: I think the best I can do is:
12:04 lucaceresoli: 1. apply the fix on drm-misc-next, where it applies cleanly
12:04 lucaceresoli: 2. send a modified patch for drm-misc-fixes, to fix ASAP the master branch
12:04 lucaceresoli: However I'm not sure this is the best strategy, it might create conflicts when later drm-misc-next goes into master, so I'll wait a while for any better suggestions.
13:04 MoeIcenowy: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38810#note_3303344 raises a question about usage of os_dupfd_cloexec() on GPU fd for renderonly drivers
13:04 MoeIcenowy: who can answer this?
14:33 mripard: lucaceresoli: if it applies on drm-misc-fixes, why do you want to apply it to drm-misc-next-fixes?
14:34 lucaceresoli: mripard: it's the other way around, it does not apply to drm-misc-fixes
14:34 alyssa: linkmauve: guess someone refactored it
14:35 alyssa: it's src/panfrost/model/pan_model.c now
14:35 alyssa: feel free to update the docs
14:36 lucaceresoli: mripard: but the bug is in v6.17, so it should go in drm-misc-fixes accprding to the documented process
14:36 mripard: lucaceresoli: yes
14:36 mripard: drm-misc-next-fixes is for bugs that are in drm-misc-next but not in master
14:38 lucaceresoli: mripard: aaah, sorry, my mistake, in the 13:03:53 message I wrote drm-misc-next-fixes, I meant drm-misc-fixes
14:39 alyssa: anholt: as with riscv, the s390x is qemu and hitting the nir algebraic timeout occassionally https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39250#note_3303469
14:40 glehmann: alyssa: if you have time, can you look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39460 please?
14:40 alyssa: glehmann: sure yeah
14:40 glehmann: thanks
14:40 alyssa: I usually stalk MRs by Updated date which means stuff not touched since a weekend tends to miss my context window :p
14:41 alyssa: I have normal execution function dont worry
14:41 lucaceresoli: mripard: so the problem is: the fix should go in drm-misc-fixes but does not apply there; it only applies to drm-misc-next
14:41 mlankhorst: Just put a fix ready for drm-misc-fixes and fix up the drm-tip rebuild
14:42 alyssa: glehmann: should stuff be nir_fp_exact or nir_fp_no_fast_math?
14:43 alyssa: like the opencl thing doesn't really make sense to me
14:44 glehmann: well it depends on whether you want well defined NaN/Infs
14:44 alyssa: which I guess is by execution mode here..
14:44 alyssa: OK
14:44 alyssa: have you ran OpenCL CTS btw?
14:45 glehmann: only the few CL jobs in CI
14:46 alyssa: karolherbst: ^
14:46 zmike: jenatali: maybe you want to comment here https://gitlab.khronos.org/opengl/API/-/issues/284
14:48 karolherbst: CL doesn't really have exact anyway and the SPIR-V we get should have the proper floating point decorations/execution mode set
14:49 jenatali: zmike: thanks for the ping, will look closer in a bit
14:49 karolherbst: though it is picky about NaN/inf and precision in some cases
14:50 alyssa: karolherbst: Mm.
14:51 alyssa: The ContractionOff stuff seems to be CL-specific so there's value CTS'ing that MR beyond what's in CI
14:51 alyssa: or I can I guess
14:52 karolherbst: CL has a couple of compiler flags: -cl-mad-enable (allows a * b + c to be fused or unfused), -cl-no-signed-zeros, -cl-finite-math-only (ignore Nan/Inf exists) and -cl-unsafe-math-optimizations (enables a bunch of others, but basically yolos optimizations)
14:53 karolherbst: ohh yeah, but ContractionOff is deprecated in CLC
14:53 karolherbst: or maybe not?..
14:53 karolherbst: there is the FP_CONTRACT macro thing which is cursed
14:53 glehmann: the question is what does map to in the SPIR-V that we see
14:54 karolherbst: anyway, FP_CONTRACT allows per instruction settings
14:54 karolherbst: the translator uses SPV_KHR_float_controls
14:56 karolherbst: and SPV_INTEL_float_controls, SPV_INTEL_float_controls2 as well
14:56 karolherbst: ehh.. SPV_INTEL_float_controls2
14:57 karolherbst: anyway, I'd just assume the SPIR-V we get has proper annotations for everything and if not, I can dig into the issues and figure out what's broken
14:59 glehmann: I guess SPV_INTEL_float_controls2 is basically float controls2
14:59 glehmann: so that should be fine
15:05 karolherbst: yeah.. but I don't enable the translator to use it yet... but I kinda should if we support it in mesa
15:06 karolherbst: only use SPV_KHR_float_controls for now
15:09 karolherbst: anyway.. I don't see it using SPV_INTEL_float_controls2 for anything we'd run into
15:10 karolherbst: I can maybe do proper testing tomorrow, want to finish cleaning up an MR today (and will be stuck in meetings)
15:49 Ryback_: jannau: if f43 skip to 25.3.4 would be good too. thanks.
16:41 alyssa: glehmann: thinking about the pack half stuff and extracts and such
16:41 alyssa: I wonder if the first step is to designate certain opcodes as non-canonical, and banish them to late NIR only
16:42 alyssa: Potentially we could even have an algebraic_property NONCANONICAL and then validate that no such opcodes exist during the main nir_opt_algebraic loops
16:42 alyssa: so if backends really want to fuse stuff like extract_u8 in NIR they still can - but we ignore that in common code
16:42 alyssa: which would solve your ACO problem without causing a new Intel/Arm/etc problem
16:43 alyssa: and I think that could be applied more generally too, every case where we have multiple copies of an opcode because some backend wants things fused a certain way
16:43 alyssa: without opt_algebraic rule combinatorics
16:43 alyssa: bfe vs bitfield_extract is another potential case
16:45 alyssa: In general I'd like NIR to be more opinionated
16:45 alyssa: I don't care whose opinions it has.
16:48 glehmann: I mean, if it's nessecary
16:48 glehmann: I was kind of hoping that everyone's codegen is decent
16:49 glehmann: especially arm is surprising given their focus on fp16
16:50 alyssa: that's a... bold assumption
16:50 alyssa: look if you want to just delete extract_u8/u16/i8/i16 too I'd ack :p
16:53 glehmann: we actually use those
16:56 jenatali: alyssa: That sounds like a good design to me
16:56 alyssa: glehmann: /o\
16:56 alyssa: jenatali: what I actually want is a single, human-documented, machine-validated, canonical NIR
16:57 alyssa: and have frontends produce it as quickly as possible, and backends maintain it as late as possible
16:57 alyssa: and common code that only has to worry about that
16:57 jenatali: Sounds very LLVM-like (I think)
16:57 jenatali: Makes sense to me
16:57 alyssa: instead of today's circus of "every ISA has its own unique NIR dialect during common opt loops which means we need to duplicate patterns and still miss stuff"
16:58 alyssa: Unfortunately we do get real benefit from the circus today.
16:58 alyssa: because any time ISAs need special lowering, there's room to optimize the code that gets lowered out.
16:58 glehmann: the recent trend seems to go in the opposite direction, with everyone adding their own zoo of alu instructions
16:58 alyssa: yeah.
16:58 glehmann: because people don't want to write a backend optimizer
16:59 alyssa: I don't care about people adding opcodes that are only produced by backend_nir_algebraic_late
16:59 glehmann: maybe we should have infra that does late algebraic opts and backend instruction selection in one
16:59 alyssa: the problem is when that infects the main opt loop.
16:59 jenatali: Right. You can write arbitrary backend-specific algebraic optimizations
17:00 alyssa: unfortunately having the real optimizer run over the lowered code can be legitimately useful.
17:00 alyssa: as an example, a bunch of backends lower sin(x) to sin_backend(x * #k) for different #k's (usually some fraction of pi)
17:00 alyssa: and having the real optimizer see that fmul is useful :|
17:01 alyssa: in cases like sin(3 * x) turning into sin_backend((3 * x) * #k) and then nir opt algebraic - the main loop - reassociates the multiply to fold the constant.
17:01 alyssa: So there's no winning /o\
17:03 alyssa: [ or sin((x * #y) + #z) becoming sin_backend(((x * #y) + #z) * #k) which opt algebraic turns into sin_backend((x * (#y*k)) + (#z*k))
17:03 alyssa: ]
17:04 glehmann: I don't think we have to take either approach to its extreme, it's not like there are many opts with sin/cos
17:04 alyssa: That's fair.
17:05 alyssa: It's just an easy counterexample to the lie that simply keeping everything canonical is the winning strategy.
17:06 daniels: also Mir
17:07 glehmann: alyssa: I mean, there are bigger counter examples
17:07 glehmann: like alu vectorization
17:07 alyssa: glehmann: sure. this was just the literal first that popped to mind :p
17:10 alyssa: glehmann: also I checked the backends -- for the unpack half MR, arm should be fine because of the f16vec2 shenanigans we do
17:11 alyssa: and Intel should be fine because it all turns into MOVs and I think backend copyprop can chew thru it.
17:11 alyssa: so that's an ack.
17:12 glehmann: so the only backends in question are broadcom, and the nvidia ones
17:13 glehmann: and d3d12, but code quality isn't really a concern there, it just has to work
17:14 alyssa: & an r-b.
17:14 glehmann: I really hope gerddie actually thought my r600 changes through, because I was guess-coding them
17:16 glehmann: jenatali: did you already write something to keep d3d12 working?
17:16 jenatali: Not yet
17:19 jenatali: glehmann: I should be able to do that today
17:37 daniels: dj-death: do you have any way to test if removing the anv formats would be fine in !39552?
17:37 daniels: or doing what radv does, which is to allow it for buffer storage but not images
18:22 Company: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/blob/8c5db11ebe339de0ccf507ef92207a7ac7480e40/src/vulkan/wsi/wsi_common_wayland.c#L603-611
18:23 Company: isn't that wrong?
18:23 Company: I'm unsure because I don't know all the flags, but isn't that mapping a 3byte to a 4byte format?
18:24 anholt: Company: that's definitely incorrectly mapping to a 3-byte format.
18:26 Company: the one thing where 3byte formats are interesting in GTK is when people open gigapixel image files
18:26 Company: because Loupe can save 25% of memory which is > 1GB for gigapixel images
18:28 daniels: Company: yes - that VK format is specified to be 24bpp, which is getting mapped to a 32bpp DRM format
18:29 daniels: radv supports that format, but not for images so it's not relevant. anv 'supports that format', in the sense that it's actually the 4bpp format, like if you specify VK_FORMAT_B8G8R8A8 + componentAlpha==OPAQUE. panvk does literally support that format, which is why I've tripped over the broken mapping.
18:30 Company: daniels: that link is from your branch in case that wasn't clear
18:32 daniels: Company: touché.
18:32 Company: I blame gitlab for butchering the link
18:32 daniels: thanks :) looks like I fixed DRM_FORMAT_BGR properly, but mangled DRM_FORMAT_RGB
18:36 alyssa: Company: why do gigapixel image files exist
18:37 Company: alyssa: I blame Hubble Deep Field mostly
18:37 alyssa: ah
18:37 HdkR: It's a sacrifice we must be willing to make so we can look outwards to the pretty space.
18:40 Company: I had to write code to split images because they exceeded texture size limits
18:40 Company: and pretty much every gpu does 16384 pixels these days
18:40 HdkR: Some even do 32k! :D
18:42 Company: I know, my testcase stopped working
18:43 HdkR: We're going to need some larger pictures and a quad 8k panel arrangement.
18:44 Company: libpng has a limit, too
18:47 Company: https://github.com/pnggroup/libpng/blob/0f07f70aa55e4771d00b0f8a238dca992fbb60e4/pnglibconf.h.prebuilt#L215 - okay, it's still some orders of magnitude off