10:59 linkmauve: Hi, it seems rusticl currently doesn’t build when using a nightly Rust version with bindgen:
10:59 linkmauve: error: invalid value '1.88.0-nightly' for '--rust-target <RUST_TARGET>': "1.88.0-nightly" is not a valid Rust target, the patch version number must be an unsigned 64-bit integer
10:59 linkmauve: With `rustup default stable` it does build.
11:34 tzimmermann: what is the expected UAPI behavior if the gamma_lut table is larger than the bits-per-component? for example, if the gamma_lut has 256 hardware entries, but the color format is rg565? will userspace load only enough entries for the rgb565 format? or will it load the full table and let the driver interpolate?
11:35 emersion: driver interpolates
11:39 pq: That's a good question, I suppose it hasn't been documented then?
11:41 pq: the framebuffer format is quite far removed from the CRTC after-blend format in the abstract color processing model.
11:42 pq: you could have one plane with argb888 and another plane with rgb565
12:19 tzimmermann: emersion, pq, i searched thorugh xorg and drivers, but i couldn't find a definite answer. xorg appears to load the full HW palette. but not all drm drivers appear to interpolate
12:20 pq: tzimmermann, are you talking about C8, the paletted format?
12:22 pq: There is much of ancient history, C8 was, AFAIU, supposed to work by loading the palette into... one of the CRTC LUTs. Obviously that's problematic with multiple planes on a CRTC, and there probably isn't a solution, because paletted formats feel out of use.
12:23 pq: *fell
12:23 tzimmermann: neither. each pixel component serves as index into the gamma lut. so if the plane format is rgb565, the gamma lut requires 32/64/32 entries. but the hardware table has usually 256 entries for each component. my question is bout the behavior in this case
12:24 pq: right, and I would assume the you would find all possible behaviors in different drivers/hw
12:24 tzimmermann: indeed. the semantics arent clear
12:24 pq: However, this LUT is attached to the CRTC so it acts after blending. What format does blending produce?
12:25 tzimmermann: pq, depends on the hardware
12:25 pq: Given one can compose a CRTC from planes with e.g. argb8888 and rgb565.
12:26 pq: right, except in modern KMS it cannot depend on the hardware
12:26 pq: the view of KMS to userspace must the common across all hw
12:26 tzimmermann: right. at least the HW-specific behavior has to be marked as such
12:27 pq: so there must be a common abstraction, assumption, of what that format is
12:27 tzimmermann: exactly
12:27 pq: *I* would assume that format is the normalized [0.0, 1.0] range.
12:28 tzimmermann: and that is the 'index' into the lut
12:28 tzimmermann: ?
12:28 pq: which means that no matter how many elements a LUT has, the first elements maps to 0.0 and last element maps to 1.0. Linearly in between.
12:28 pq: yes
12:28 tzimmermann: that makes sense
12:29 pq: yeah, it would make sense, but I cannot guarantee it works like that :-)
12:29 tzimmermann: i think that is the assumption build into the UAPI, although it's under-documented
12:31 tzimmermann: there is simple hardware that takes the pixel component as an index into the hardware lut. something like r' = hw_gamma_lut[r] ; same for g and b components. this is when the driver has to interpolate the gamma_lut property to get the corresponding hardware lut
12:32 tzimmermann: does that make sense?
12:32 pq: yes, I think so.
12:33 tzimmermann: thanks. that was very helpful
12:35 pq: there is also hardware with non-uniformly distributed LUT taps, and the driver converts the uAPI given table to that form.
14:26 MrCooper: hakzsam: FYI, I bisected some piglit cl regressions with rusticl on radeonsi to e433a57650c1 ("ac,radeonsi: rework computing scratch wavesize and tmpring register")
14:27 MrCooper: (isn't it time for some rusticl on radeonsi coverage in CI?)
14:27 hakzsam: MrCooper: sorry for the breakage, I will take alook
14:28 MrCooper: no worries, it happens if there's no CI coverage
14:29 MrCooper: hakzsam: fails with cl-program-tester: ../src/gallium/drivers/radeonsi/si_compute.c:303: si_setup_compute_scratch_buffer: Assertion `scratch_needed' failed.
16:22 hakzsam: MrCooper: I'm afraid I don't see the issue. How do I repro?
16:23 MrCooper: e.g. 'RUSTICL_ENABLE=radeonsi .../piglit/bin/cl-program-tester .../piglit/tests/cl/program/execute/amdgcn.sign_extend_inreg.cl'
16:25 hakzsam: ok
16:48 hakzsam: MrCooper: oh, I see the bug...
16:55 hakzsam: MrCooper: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34586
17:23 cmarcelo: do I need to do something special to enable margebot to act in a gitlab repo? (mesa/vkrunner)
17:59 eric_engestrom: cmarcelo: yes, we need to add that repo to ones of the marge instances
18:00 eric_engestrom: cmarcelo: please ask for it on #freedesktop, I don't have time right now and I'll forget by next week so it's better to ask there :P
18:02 cmarcelo: eric_engestrom: ok tks
20:05 yusisamerican: How does the compiler figure out the association between the nir_variable associated with the ubo and the source of the ubo load intrinsic?
21:27 zf: is there any feasible way to bisect llvm?
21:29 kisak: sure, on the odd occasion I've bisected llvm with mesa, I've always rebuilt mesa from the same day as the llvm commit and carefully took notes as I went.
21:31 kisak: that was with gentoo portage and SSH'ing into the test box to only use the system-wide installed versions of llvm and mesa so that I didn't contaminate the test with unexpected combinations
22:10 olivial: yuisamerican: is the nir_lower_io pass what you're looking for/asking about?
22:11 olivial: this is where ubo variable derefs are converted to load_ubo
22:21 yusisamerican: olivial: I think so
22:43 yusisamerican: thanks
22:47 olivial: np :)