07:27 hakzsam: Lynne: can you fill a radv ticket and way to reproduce it please?
07:34 Kayden: I feel like any time I touch any IO code at all I have to set no_validate now
07:34 Kayden: it's really annoying
07:35 Kayden: mostly during steps where I'm moving away from the info being validated toward offset based stuff
07:35 Kayden: like if I want to use nir_lower_wrmasks before lowering to driver intrinsics
07:36 Kayden: I wonder if this would have been better as a nir info flag for "we're past the phase of semantic IO, don't bother"
07:36 Kayden: instead of having to have every pass that might alter things tag every intrinsic
07:40 Kayden: don't know how other drivers aren't still broken honestly
12:44 Venemo: hey guys, here is a question for those who work on rust based drivers in the kernel. when can we expect rust support to "just work"? oftentimes I see some rust related build errors when I am trying to build the kernel, and the solution is to just disable rust, which is pretty disappointing
12:45 K900: Never had issues with that
12:45 Venemo: latest one is this error with rust/helpers/helpers.o: error: error loading target specification: target-pointer-width: invalid type: string "64", expected u16 at line 8 column 32
12:45 K900: And we're a distro shipping a Rust enabled kernel on multiple targets
12:45 Venemo: K900: that's nice to hear, can you help me figure out the solution?
12:46 K900: My money would be on too old Rust version
12:47 Venemo: rustc --version says: rustc 1.91.0 (f8297e351 2025-10-28) (Fedora 1.91.0-1.fc43)
12:47 Venemo: this is just 2 weeks old
12:48 Venemo: or is it? I don't know if that is the date of the Fedora build or the release of that rustc version
12:48 K900: Then possibly too new
12:48 karolherbst: Venemo: the kernel uses night/unstable features
12:48 karolherbst: so you really want to use the exact same version the kernel targets
12:48 Venemo: ok
12:48 karolherbst: *nightly
12:48 Venemo: so, when can we expect it to "just work"?
12:48 karolherbst: once all those features are stable
12:48 K900: As in "arbitrary stable compiler thrown at arbitrary kernel version"? Probably a year or so from now at the earliest
12:48 Venemo: I see
12:48 Venemo: thanks
12:49 karolherbst: yeah.. people are working on it, but the kernel has special needs, but it also needs to be used to figure those out and such.. well hopefully soonish it's all done
12:49 Venemo: which is the correct option to actually disable rust? looking at .config there are at least 3 different ones and it's unclear what the difference is between them
12:50 K900: CONFIG_RUST=n
12:50 Venemo: what is the difference between these 3? CONFIG_RUST_IS_AVAILABLE, CONFIG_RUST, CONFIG_HAVE_RUST
12:52 karolherbst: I think the first is after verifying the toolchain works and the last is architecture has support for rust?
12:52 karolherbst: I think
12:52 karolherbst: anyway, only have to care about CONFIG_RUST
12:52 Venemo: okay, thanks
12:53 Venemo: I really hope it stabilizes soon. I have high hopes for those rust based drivers
12:53 karolherbst: anyway, generally I advise devs to use rustup and just set a specific version so a distro update isn't breaking things randomly
12:54 karolherbst: most projects don't use unstable features, but the kernel does, so it causes those headaches
12:54 Venemo: it's easier for me to just disable it as I am personally not relying on any of those drivers at the moment
12:54 karolherbst: fair
12:54 Venemo: just want to build amd-staging-drm-next without trouble, is all
12:57 jannau: in principle every rustc version from 1.78 should be supported. I expect older ones get less and less testing as the rust code grows. rustc builds the kernel rust code in its CI but tests doesn't have good covered over all kernel config option
12:58 jannau: 1.91 hit this in multiple places, sanitizers and debug symbols for certain objects
12:58 karolherbst: ohh looks like there is a fix for your issue in git
12:59 karolherbst: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/scripts/generate_rust_target.rs?h=v6.18-rc5&id=8851e27d2cb947ea8bbbe8e812068f7bf5cbd00b
13:06 Venemo: I guess I'll get that if/when amd-staging-drm-next is rebased
13:07 jannau: that commit is in v6.17
13:07 Venemo: amd-staging-drm-next is based on 6.16
13:09 anonymix007[m]: Is there a simple test suite for checking Vulkan conformance for features that zink may use? I've tried VK-GL-CTS, but it just refuses to compile with mingw which is basically my experience with all of the Khronos tools.
13:16 Venemo: anonymix007[m]: which driver are you looking at, specifically? in order for a driver to be called conformant, it needs to have passed the CTS and be accepted by Khronos
13:23 anonymix007[m]: Venemo: venus. It being called conformant on the platform I'm porting it to is currently the least of my concerns, the primary thing I need right now is having zink working. It's a bit hard to debug, so I want to start with something much simpler. Basic things like cube already work though
13:24 Venemo: well, if the driver is non-conformant then the best way to find out if it supports a specific feature is to either test it, or look at the Mesa matrix and the CI files for the driver to see if the feature is being advertised and tested
13:25 Venemo: looks like venus is entirely missing from the matrix: https://mesamatrix.net/
13:26 Venemo: or wait, maybe it's "vn"
14:25 anonymix007[m]: Okay, so there are 7 piglit vulkan tests (not much, but better than nothing. At least piglit compiles). And all of them fail because vkCreateInstance failed. Which is weird since vulkaninfo and vkcube work, so something fishy is going on. Running vkrunner manually with `vkrunner ./tests/vulkan/fs-large-local-array-vec2.vk_shader_test` doesn't work either, it prints "program not found" and that's it.
15:22 tzimmermann: jfalempe, thanks for merging the ast dma-buf fix. out of curiosity: did you find the issue on i915's side. IIRC fixing ast was only half of the issue
15:25 silurian_invader: how should mutually-exclusive properties behave? e.g. say I have two planes and either one can have alpha enabled but not both at once
15:26 silurian_invader: should the driver error if userspace tries to set alpha at the same time?
15:26 silurian_invader: or should it "correct" the configuration by disabling alpha on the other plane if it is enabled on the first one?
15:27 silurian_invader: if the former, how should userspace find out it has to disable alpha one one plane when it enables it on the other?
15:28 daniels: silurian_invader: yeah, you need to refuse the configuration; never attempt to 'correct' it to something userspace didn't ask you for
15:29 daniels: there is currently no mechanism for KMS drivers to inform userspace why a configuration couldn't be set, or what it could do to get an acceptable configuration, though it's being discussed upstream
15:29 silurian_invader: fun
15:29 silurian_invader: and what about e.g. zpos
15:30 silurian_invader: whichever plane has alpha enabled should be on top, so does userspace also need to set zpos?
15:30 silurian_invader: or should that be done by the driver?
15:30 daniels: userspace needs to set zpos
15:31 daniels: if you 'correct' it by moving the alpha plane to the top, you end up displaying something completely different to what userspace intended to present, with no way for userspace to know that you've decided to just do something else
15:32 daniels: the same applies to everything: don't move planes, don't restack planes, don't change blending configuration, don't resize stuff, don't make everything be all magenta
15:32 silurian_invader: I mean that zpos is completely determined by the planes' blend modes
15:33 daniels: I'd imagine the way you'd account for that is marking the zpos property as immutable on your planes, with the topmost one exposing an alpha property/format and the others not
15:34 silurian_invader: right, but you can enable alpha on another plane too
15:34 silurian_invader: so there can't just be a single alpha property
15:47 daniels: but you can only enable alpha on one plane at a time, right? or do the planes have other properties, e.g. disjoint formats?
15:49 dschuermann: does someone know if nir_opt_algebraic is idempotent, now with the constant folding in place?
15:55 silurian_invader: daniels: yes, only one plane at a time
15:56 silurian_invader: but userspace should ne able to configure the plane with alpha
15:57 silurian_invader: an unambiguous way to do this could be to have an "plane with alpha enabled" property on the crtc
15:57 silurian_invader: but the standard properties put alpha properties on each plane (which assumes alpha can be enabled/disabled orthogonally)
16:02 pq: silurian_invader, why would userspace care which plane is the plane with alpha, if userspace can zpos-reorder the planes as it sees fit?
16:03 pq: Are the planes not equals?
16:03 silurian_invader: the planes are not equal
16:04 silurian_invader: they support different color modes, have different options for input
16:04 silurian_invader: and on a crtc that supported alpha on all planes at once, the "bottom" plane would be mixed with the background color, but on this crtc the bottom plane will always be opaque
16:15 daniels: I think then your only option is to expose alpha/zpos on both planes, and require that userspace set (only_one_alpha && plane->alpha_en == plane->zpos_is_top) for the proposed configuration to succeed. if it doesn't succeed, userspace will have to fall back
16:23 silurian_invader: that's rather disappointing, since it means userspace will effectively need custom code just for this crtc
16:24 daniels: well, there is no generic way to express restrictions such as this, so userspace already needs a bunch of trial & error, as well as various fallbacks. having a 'only the top plane can do alpha' check is equivalent to having a check for your exact hardware, so that isn't a solution either ...
16:28 glehmann: someone up for reviewing a nir_opt_algebraic pattern? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37937
18:43 alyssa: done
18:44 glehmann: thanks!
18:49 alyssa: meanwhil,
18:49 alyssa: - assert(intr->src[0].ssa->parent_instr->type != nir_instr_type_undef);
18:50 alyssa: + assert(!nir_src_is_undef(intr->src[0]));
18:50 alyssa: (& many others like it)
19:14 Company: Vulkan question: When I pass a wait semaphore to vkQueuePresentKHR(), when can I destroy/reuse that semaphore?
19:40 karolherbst: alyssa: do we have a simple way to add printf statements through nir_builder or is there something I'm missing?
19:47 alyssa: karolherbst: nir_printf_fmt
19:48 karolherbst: ... ohh
20:00 karolherbst: thanks! still doesn't work, but it's on the driver side now
20:00 alyssa: sure
20:39 dj-death: Company: I think it's only defined when using maintenance1 : https://github.com/KhronosGroup/Vulkan-Docs/issues/152
20:53 Company: dj-death: thx, it seems https://www.khronos.org/blog/resolving-longstanding-issues-with-wsi is what I want
22:52 sghuge: quick question, if there is a semaphore wait missing in the App (between render and compute, if they are depdendent), does vkd3d complains about missing potential synchronization point if we enable VKD3D_DEBUG=err logs?