On 3/24/26 20:20, Mario Kleiner wrote: > On Sun, Mar 22, 2026 at 7:11 PM Kovac, Krunoslav <[email protected] > <mailto:[email protected]>> wrote: > >> There is a reason for the change that is alluded in the commit, but >> perhaps I should've been clearer. >> If you have an ARGB2101010 surface and monitor is 10bpc, one of the HW >> design goals is that we can output this in a bit-perfect way, i.e., for >> every surface pixel value K=0..1023, monitor will receive K at its end. It's >> also one of the things some customers have checked for and complained about >> historically. This is very hard to see visually or even with a colorimeter >> but is readily apparent with a HW capture card. >> >> Our HW can accomplish this 10-bit perfect requirement if set up >> correctly, however, it can only do so if we use rounding, not dithering. >> For example, say you have a 10-bit code 200, our pipeline precision and >> error accumulation may result with 200.15, which in 12bpc before dithering >> would be 801 and the nature of the spatial dithering is that now and then >> RNG result will push that to 201 output, it's just the way it works. >> Rounding is several times less sensitive to this, and without this >> randomness component, we can verify we're always accurate enough at 10bpc >> level. > > Ok, that makes a lot more sense. I can understand that. My own software and > users have the same critical requirement for some use cases, of being able to > pass through ARGB8888 surfaces to 8 bpc video sinks. They connect special > neuroscience display equipment that parses special binary control information > out of false-color coded framebuffer images, or implements very high color > precision display up to 16 bpc per color channel on top of 8 bpc framebuffers > and some shader magic. Luckily, using a standard 8 bpc framebuffer under the > native X-Server, a 8 bpc DVI-D or DP video sink, and loading a specifically > crafted gamma table achieved this for our case, despite the spatial > dithering-down-to-8bpc being active. DC has some special detection function > (__is_lut_linear() in amdgpu_dm_color.c) that detects if a user provided > gamma lut is essentially meant to be a linear identity mapping lut, and if > so, enables lut bypass or identity mapping iirc, and that does the trick well > enough for us atm.
Sounds like passthrough of 10 bpc values should work fine with your patch thanks to this bypass / identity mapping, doesn't it? > I haven't tested this yet under Wayland, as the Wayland eco system is not > ready for the more demanding use cases, [...] Are there issues describing those use cases? >> I believe we don't have surface info in that code, but one way to work >> around it would be to use spatial dithering for FP16/ARGB16 and rounding for >> 10 bits. But if we just switch to spatial, some of the earlier complaints >> about 10-bit output having one-off bit errors will be coming back. > > Looking at all callers of resource_build_bit_depth_reduction_params(), they > all have access to the associated "struct pipe_ctx", which should give access > to pipe_ctx ->plane_state->format of an associated display plane. I could > prepare a patch that passes the pipe_ctx from each caller into > resource_build_bit_depth_reduction_params() and that function could check if > a 16 bpc framebuffer is in use and switch to spatial dithering down-to-10-bpc > in this case, and leave the rounding/truncation to 10 bpc otherwise. That doesn't really make sense, the output of the display HW colour pipeline has more than 10 bpc regardless of framebuffer format. > This workaround, that you also propose, would be the least bad of all bad > solutions. Seems pretty bad to me, mixing up things which aren't directly related. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
