00:06 alyssa: anholt_: I admit I'm rusty on how this is supposed to work, but the original source code has something like
00:06 alyssa: "if (..) { fragColor = constant }"
00:06 anholt_: what's the precision on fragColor?
00:06 alyssa: which becomes GLSL "(if ... (assign (f162f constant)))"
00:07 alyssa: fragColor in the post-precision lowering GLSL still appears to be 32b if I'm not mistaken
00:07 alyssa: fragColor should be mediump in the original code tho
00:07 alyssa: yes, fragColor is mediump
00:08 anholt_: in the source, I meantif the shader is precision mediump float, and vec4 fragcolor doesn't have a modifier on it, then the bug is it being stored as 32 bit.
00:08 alyssa: shader is definitely mediump, but fragColor in NIR is also mediump
00:09 alyssa: so the bug is being stored in 32-bit (in GLSL first) despite being mediump, I think?
00:09 alyssa: Not sure why this only comes into play with conditionals, maybe the converts otherwise would get cleaned up in NIR so the bug is masked
00:10 anholt_: if the variable is being recorded as mediump, then whatever glsl is turning it into 32bit instead of mediump needs to be tracked down
00:10 alyssa: Hm, right
00:11 alyssa: (assign (x) (var_ref compiler_temp@58) (expression float f162f (expression float16_t dot (expression f16vec3 f2fmp (var_ref x@59) ) (expression f16vec3 f2fmp (var_ref y) ) ) ) )
00:11 alyssa: ^ is that sort of GLSL (with f162f wrapping it) normal for mediump/16-bit?
00:11 alyssa: (that's legitimately just f162f, not f162f32?)
00:13 alyssa: tempted to blame glsl_to_nir
00:13 anholt_: ok, so ast_to_hir is making an ir_var_temporary, which is where your 32b storage is coming from
00:16 anholt_: setting ir_variable::temporaries_allocate_names might help you track down what the temp is from
00:16 alyssa: ack
00:22 alyssa: I'm not sure how this is supposed to work.
05:03 dinosomething: any idea what the difference is between a "Screen" section's "Device" and "GpuDevice"?
06:20 HdkR: robclark: Does Freedreno not support an on-disk shader cache btw?
07:33 mareko: bnieuwenhuizen: the drm fd doesn't matter; if it's the same queue, the kernel doesn't wait, it only ensures correct IB order
09:57 MrCooper: bnieuwenhuizen mareko: I do wonder if the kernel couldn't do the wait for idle based on same/different DRM file description and/or whether there's a direct dependency between the jobs (i.e. later job has the fence of the earlier one as a dependency)
09:57 MrCooper: mareko: would be good to have the discussion with Christian on the amdgpu-gfx or dri-devel list
12:20 pmoreau: EdB: Are you thinking of adding image1d_t, image1d_array_t, image2d_array_t to llvm/codegen/common.cpp and core/kernel.cpp? Since you added those to core/format.cpp but you do not handle them as kernel arguments otherwise.
12:23 EdB: pmoreau: not or the moment since I have no device that support image
12:23 EdB: the latest addition was to make CTS appy
12:23 EdB: *happy
12:23 pmoreau: :-D I see; well, I don’t think I have one that does either.
12:24 pmoreau: Yeah; I’m not really comfortable advertising those formats if we do not support them.
12:25 EdB: maybe after clover goes 1.2 and if a workflow needed it one of them, I may have a look, but it's a big may be
12:26 pmoreau: No worries
12:27 EdB: I don't know if Blender use image for its CL
12:29 pmoreau: They might
12:37 EdB: pmoreau: If I get it correctly, you are working for clover on nouveau. Is it for a specif purpose or just for the chalange ?
12:39 pmoreau: Correct. More for the challenge, and getting some OpenCL support for Nouveau.
12:43 wm4: is there any video mixing API yet that gives access to low level optimized implementations or even fixed function stuff?
12:44 wm4: vdpau would be one, but that is severely limited, and probably emulated by shaders everywhere
12:53 ccr: wm4, hi. assuming you are the mpv developer, thank you for your work - and some very entertaining commit messages in the mpv repo :P
12:54 wm4: yes... and I'm asking as application developer, if that is not offtopic
13:46 robclark: HdkR: we haven't wired up any driver specific shader cache stuff..
13:51 himanshujha19964: The MIPI DSI driver `drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c` mentions "dual-dsi" master and slave interface. Is it that there are two instances of MIPI controller ?
14:03 EdB: pmoreau: is your review done ?
14:04 pmoreau: Not yet, missing the first 3 patches. But I’m taking a break from reviewing for now.
14:09 EdB: ok :)
15:07 EdB: pmoreau: If you're ok with that, I can push change according your current remarks
15:13 pmoreau: EdB: Sure, you can push an updated version in the mean time; I don’t really have further comments on the patches I already looked at.
16:14 EdB: pmoreau: done
16:15 EdB: sorry if I miss a message but my loptop screen is no longuer displaying anythings
16:16 EdB: so I add to find a way to plus a second screen a get my open widows to be dislayed on te new one
16:16 EdB: This could be a bug after the screen went on power save mode
16:36 Lightsword: did I send https://patchwork.kernel.org/patch/11483961/ to the right place? I haven't received any response in over a month
18:40 kisak: eric_engestrom: what's up with the stack of regression labels (and is it functionally better than using one "mesa 20.X regression tracker" milestone?
18:41 kisak: ^ or label
19:33 jekstrand: kisak, eric_engestrom: Yeah, I'd tend to agree. A regression label per minor version seems like an abuse of lables.
19:33 jekstrand: That's what milestones are for
19:34 jekstrand: For that matter, I don't know that having a milestone per minor release is useful either.
19:34 jekstrand: We have the Fixes: tag which deals with basically everything useful that the lable does IMO
20:01 eric_engestrom: milestones are unusable because you can only at most one, and we always have an overlap between the old stable branch and the new one
20:02 eric_engestrom: so we've been thinking about options to track issues and to which release they apply
20:03 eric_engestrom: this might not be the optimal solution, but it's the best I got for now
20:03 eric_engestrom: I'm writing tools and docs that I'll MR btw
20:03 kisak: right, but why is marking every patch version better than just marking the release branch?
20:04 eric_engestrom: because hopefully the issue will be fixed eventually
20:04 eric_engestrom: and we need to track that
20:05 kisak: you don't need seven labels say there is a regression in 20.0 like https://gitlab.freedesktop.org/mesa/mesa/-/issues/2626
20:05 eric_engestrom: my goal is to have the release script be able to look at gitlab and tell the maintainer "this issue hasn't been fixed on the release you're making" or "this MR needs to be backported to fix that issue"
20:06 eric_engestrom: kisak: yeah I wasn't really sure whether to track just the latest release or all of them
20:06 kisak: if open && label:"regression 20.0" isn't clear enough for a script?
20:06 eric_engestrom: it would be enough to just say "this issue is still present in 20.0.7" but we need to start being consistent first
20:08 eric_engestrom: kisak: I can't think right now (tired) but I though there was an issue with that solution
20:08 eric_engestrom: yes, I remember: the MRs
20:09 eric_engestrom: when an issue is closed we need to know if the latest release still had that issue to know whether to backport the MR fixing that issue
20:09 eric_engestrom: or if it's been fixed already
20:09 kisak: which should be completely covered by CC: <mesa-stable> and fixes:, if it's not, that's a documentation bug and the contributor should be encouraged to make it clearer
20:10 eric_engestrom: as for label spam, the idea is to delete all the label for a stable branch once that branch is closed and no new release will be made
20:10 eric_engestrom: labels can be added afterwards
20:10 eric_engestrom: the issue with commit tags is that everyone always forgets to add Fixes:
20:11 eric_engestrom: it's very possible that I'm over-engineering this and that we shouldn't have such a complex solution
21:18 eric_engestrom: kisak: I don't know who you are; what's your gitlab username?
21:18 eric_engestrom: I'm creating an issue to discuss this and I wanted to tag you :)
22:32 dinosomething: am i wrong in this train of thought?: since gpus can be hot pluggable or moved around on the pci bus, that a /dev/dri/by-id might be useful?
22:32 dinosomething: some sort of unique identifier that matches a gpu?
22:33 dinosomething: or, i guess one would write a custom udev rule of some sort for that?
22:34 HdkR: What about Thunderbolt hotplug?
22:34 HdkR: and PCIe hotplug?