00:53 mareko: karolherbst: that's because rusticl uses compute queues and ac_prepare_compute_blit fails with that format because compute blits can't copy it without precision issues
00:57 mareko: this will allow it, but some pixels can be changed +-1 during the copy:
00:57 mareko: - max_dst_chan_size == 5 || /* PIPE_FORMAT_R5G5B5A1_UNORM has precision issues */
00:57 mareko: + (blit->is_gfx_queue && max_dst_chan_size == 5) || /* PIPE_FORMAT_R5G5B5A1_UNORM has precision issues */
01:01 mareko: actually the next line needs the change
08:45 karolherbst: mareko: interesting... I was seeing precision issues on iris as well with 565.. like returning 0.580392182 instead of 0.580645144 for red of 0x97c4. And I'm wondering if it's the same precision issues mentioning in the code?
08:46 mareko: karolherbst: it only happens on gfx6-8, I have a patch that enables the blit for gfx9+
08:46 karolherbst: I see
08:47 karolherbst: I am sometimes wondering if I need a more detailed check with is_format_supported so drivers can report a different set of formats for GL and CL to account for random precision issues like that
08:48 mareko: I think it can be mitigated in drivers by using format reinterpretation, e.g. copy as r32_uint
08:48 karolherbst: but for now I'll probably ignore 565 and only land 10102, because that seems to work already
08:48 karolherbst: (and 21010)
08:49 karolherbst: mareko: so the issue I'm seeing on iris comes directly from txl and images are formatless in CL, so not sure it can be solved in shaders without adding some runtime lowering code or something
08:49 mareko: resource_copy_region isn't formatless
08:49 mareko: in drivers
08:50 karolherbst: right, not saying that resource_copy_region can't be fixed, but running shaders could still cause problems
08:50 mareko: indeed
08:51 mareko: FS outputs round towards zero, while image stores probably round towards nearest, which could be the problem
08:51 karolherbst: intel doesn't seem to advertise "CL_UNORM_SHORT_565" in their CL stack either, but they don't advertise many formats to begin with
08:51 karolherbst: yeah... maybe
08:58 karolherbst: though the difference on iris was bigger than you'd see from rounding issues, unless there is some internal precision between what floats give you and 565/unorm
09:08 karolherbst: also...
09:08 karolherbst: clvk disabled UNORM_SHORT_565 support "because intel has issues" https://github.com/kpet/clvk/commit/3f52fd6be8532c7e7c5a0d69f0fd5eb524d0c90f
09:08 karolherbst: sooo.. not feeling particularly bad for doing the same :D
09:09 karolherbst: though they seem to do that per driver and maybe I should do that as well...
11:49 mripard: pinchartl: let's discuss it here maybe, it's going to be easier than by writing 1-line mails :)
11:54 pinchartl: mripard: indeed :-)
11:54 pinchartl: so what am I missing ?
11:55 mripard: idk, what are you missing / not understanding?
11:56 pinchartl: are KMS drivers required to support XRGB8888 ?
12:05 mripard: pinchartl: yeah, but looking into the mail archives it looks like we never merged the doc patch ...
12:05 mripard: https://lore.kernel.org/dri-devel/20230825140434.182664-1-jfalempe@redhat.com/
12:06 pinchartl: that may explain why I wasn't aware of the requirement :-)
12:06 mripard: there's a few hints in the code still
12:06 mripard: https://elixir.bootlin.com/linux/v6.15.4/source/drivers/gpu/drm/drm_fb_helper.c#L419
12:06 mripard: https://elixir.bootlin.com/linux/v6.15.4/source/drivers/gpu/drm/drm_fb_helper.c#L1532
12:06 pinchartl: + * All drivers should support XRGB8888, even if the hardware cannot support
12:06 pinchartl: + * it.
12:07 pinchartl: + * DRM drivers should not do software color conversion, and
12:07 pinchartl: + * only advertise the formats they support in hardware.
12:07 pinchartl: that sounds a bit... contradictory ?
12:08 mripard: the controversy about that code seems to come from the exceptions part, not the XRGB8888 requirement
12:08 mripard: yeah, I guess it could be rephrased
12:08 mripard: up for the job?
12:09 pinchartl: no, because I don't know what the requirement is :-)
12:10 mripard: you didn't accept it as an excuse in the past :)
12:10 pinchartl: :-D
12:11 pinchartl: I haven't followed the discussion at all, and I assume this ship has long sailed, but forcing XRGB8888 support for hardware that only supports ARGB8888 doesn't seem very nice. it should have been relatively easy for userspace that support XRGB8888 to also support ARGB8888
12:12 zamundaaa[m]: [@_oftc_pinchartl:matrix.org](https://matrix.to/#/@_oftc_pinchartl:matrix.org): the problem is that legacy doesn't really have supported formats
12:12 mripard: yeah, the issue isn't with having support in the future
12:12 mripard: it's about what we inherit from the past :)
12:13 pinchartl: legacy as in native KMS without format support ?
12:14 zamundaaa[m]: Legacy modesetting, yeah
12:16 vsyrjala: addfb2 was added in 2011
12:22 zamundaaa[m]: And yet, compositors assume XRGB8888 to be supported with legacy modesetting. I'm sure some assume it with atomic too
12:25 emersion: yeah, XRGB8888 is assumed to be always supported
12:25 emersion: some drivers not supporting it natively perform CPU conversion
12:26 pq: This may be complicated that userspace will probably favor XRGB over ARGB if both are supported. That's kind of horrible for hardware that only supports ARGB.
12:26 pq: pinchartl, what kind of hardware supports ARGB but not XRGB?
12:28 glehmann: Why do some NIR passes use nir_instr_free on removed instructions, but not all?
12:29 zamundaaa[m]: a driver only advertising ARGB8888 with the atomic API could potentially be fine, as it's expected for drm clients to check the list of supported formats
12:29 pq: pinchartl, does that hardware support not support "pixel blend mode" "none"?
12:29 zamundaaa[m]: But you still need to support it for legacy modesetting
12:40 zmike: glehmann: I think instrs are part of the ralloc ctx, so it isn't necessary
12:42 glehmann: but then why would you still want to call it manually?
12:47 zmike: people don't know?
12:51 pinchartl: pq: the Xilinx dpsub driver
12:52 pinchartl: drivers/gpu/drm/xlnx/zynqmp_*
12:52 pinchartl: in particular zynqmp_kms.c for the KMS API
12:53 pq: pinchartl, I mean, what's the hardware like? What does it use the alpha channel for?
12:53 pinchartl: it has two planes and a blender
12:53 pinchartl: the zpos is fixed
12:53 pq: and no blend-mode control?
12:53 pinchartl: the bottom plane is called the video layer and the top plane the graphics layer
12:54 pinchartl: the blender has a global alpha control
12:54 pinchartl: but as far as I can tell it doesn't offer a way to ignore the alpha channel of the graphics layer
12:54 pinchartl: the hardware doesn't support plane positioning, which makes things a bit simpler
12:55 pq: I mean blend mode: none, premult, coverage? It's hard-wired to one of them?
12:55 pinchartl: from a KMS point of view, if the graphics layer is enabled with XRGB *and* the global alpha is set to opaque, then the video layer should not be visible anywhere, so the hardware could be programmed to disable the video layer
12:55 pinchartl: let me check the modes
12:56 pq: hmm, I hope that offers a solution.
12:58 pq: Legacy KMS with multiple planes is dragons anyway, so maybe that trick help get legacy KMS to support XRGB, and then planes users are atomic which should be able to deal with the absence of XRGB.
13:05 pinchartl: pq: as far as I can tell the blending mode is not configurable
13:06 pinchartl: it's not even documented, the documentation doesn't indicate if it's premultiplied or not
13:06 pq: ok
13:06 pq: hah
13:06 pinchartl: I think it's not premultiplied
13:10 emersion: not premultiplied would be an issue, KMS is premult by default unless the compositor sets the optional prop explicitly
13:15 pinchartl: that's what the hardware does I'm afraid :-(
13:16 pq: whelp, it must be a new driver, so you cannot regress anything. :-)
13:16 pq: You could expose the "pixel blend mode" property with the only option that the hardware implements.
13:17 pq: That way userspace at least knows.
13:21 vsyrjala: someone could type up a patch to enforce that the driver expose that prop if it exposes any alpha formats. though that person would also have to fix up all the existing drivers
13:22 pinchartl: it's a good idea
15:01 MrCooper: zamundaaa[m]: do you already have some kind of prototype or something for getting timing feedback from the atomic commit ioctl?
15:12 edt_: in mesa MRs they often quote fossil stats. How are they generated (eg what do you run etc.) Are there docs anywhere?
16:13 MrCooper: tarceri_ robclark: FWIW, looks like mesa!35801 & mesa!35814 might conflict
16:15 robclark: yeah, probably
16:18 robclark: thx for the heads up
16:29 zamundaaa[m]: [@_oftc_MrCooper:matrix.org](https://matrix.to/#/@_oftc_MrCooper:matrix.org): I have an idea for the API I want, nothing more than that though
16:30 zamundaaa[m]: That API would really just be an additional timestamp in the pageflip callback
16:32 MrCooper: my thinking was similar, possibly multiple additional timestamps though
17:02 edt_: how does one generate the fossil reports seen in many MRs? Docs anywhere?
17:07 pendingchaos: edt_: https://gitlab.freedesktop.org/mesa/shader-db#vulkan-fossils
17:07 pendingchaos: some people use private fossils, because they are from proprietary applications
17:13 edt_: pendingchaos Thanks
17:19 edt_: now I just have to find the what supplies the commands/scripts on arch
17:22 zamundaaa[m]: [@_oftc_MrCooper:matrix.org](https://matrix.to/#/@_oftc_MrCooper:matrix.org): what additional timestamps are you thinking of?
20:07 dcbaker: eric_engestrom: BTW, I've looked into the opposite of a --force-fallback-for option, I have some ideas but none of them are straight forward unfortunately :/