07:45 Kayden: freedreno CI seems to be a bit pokey at the moment
08:10 sima: robclark, for the double import I guess a vgem+vkms igt would be nice
08:11 sima: I think if you abuse FLINK you can even test it from userspace alone, if both gem handles on the two separate drmfd where you imported the foreign dma-buf don't have matching flink names the kernel is bugged
08:11 sima: or something like that
08:11 sima: just woke up, this idea might be complete nonsense :-P
08:16 MoeIcenowy: question about mesa vk wsi code: the vk spec requires swapchain presentable images to behave like tiling = VK_IMAGE_TILING_OPTIMAL, but the Mesa WSI code tries to create them with tiling = VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT and assume LINEAR modifier is avilable, is this an issue?
08:17 MoeIcenowy: (there's usages that isn't valid for linear but for optimal in mesa powervr driver currently
08:17 MoeIcenowy: there're *
08:20 MoeIcenowy: (and mesa powervr driver currently don't expose GPU-internal formats as modifiers
08:20 MoeIcenowy: s/formats/layouts/
08:26 MoeIcenowy: BTW ping https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36266 , trying to MESA_VK_WSI_DEBUG=buffer to workaround the problem above and hit the old problem solved by this MR
08:27 valentine: Kayden: some of the boards were having network issues but they should to be doing better now, apologies
08:43 Kayden: valentine: awesome, thanks :)
14:21 robclark: sima: I guess double import could also be tested w/ dma-heap enabled? I haven't had a chance to check if dma-heap is already used by any other igt test
14:23 robclark: but yeah, flink name is a good idea
14:44 sima: yeah dma-heap for the exporter should work too
14:44 sima: was just thinking of something entirely virtual so we could run it for anyone's igt stack and all that
14:49 pinchartl: robclark: there's also udmabuf but that will possibly not give you suitable memory
14:55 robclark: I think dma-heap shouldn't have any particular hw req, so it should work w/ vkms as well?
14:55 robclark: although not sure how commonly it is enabled
14:57 Company: Gnome CI is using udmabuf for dmabuf stuff, and I think Weston, too - and I think GStreamer uses it in production when it needs CPU-accessible dmabufs, ie for software decoder but hw display
14:57 Company: do it'd be nice if that turned into what everyone uses
15:02 pinchartl: dma-heap may give you memory that will not be suitable for $USE_CASE with your $GPU. with vkms it should be all fine, for hardware testing it will work in some cases but likely not in all of them
15:02 pinchartl: Company: udmabuf wraps a memfd, that won't work for devices that require DMA contiguous memory
15:03 Company: pinchartl: I'm not an expert on memfds or DMA, but couldn't you add some way to make that happen?
15:07 Company: what I like about udmabufs is that they allow using the same codepaths as dmabufs but work everywhere
15:07 Company: and they've been catching on pretty well
15:08 Company: "everywhere" meaning without the need for special hardware
15:23 pinchartl: Company: not really, no. dma-heaps will already work better
15:23 pinchartl: and they give you dmabufs
15:24 Company: they just aren't enabled anywhere, or?
15:27 Company: I mean, ultimately my goal is that everyone supports the same methods, because if llvmpipe uses dma heaps and GStreamer uses udmabuf, then that makes things more complicated than necessary
15:30 pinchartl: they're not universally enabled by distros, or not accessible by non-root users
15:31 pinchartl: I think Maxime Ripard recently worked on adding memory accounting to dma-heaps, which should pave the way to enabling them in distros
15:31 pinchartl: but the best solution would be a universal allocator in userspace that would use the right backend based on the use cases
15:36 Company: I think if there's a well-documented way to allocate a dmabuf that has caught on in enough places, then people will just copy-paste the code around
15:36 Company: you just need to do the initial push to get it copy/pasted to a bunch of places
15:37 Company: I mean, for udmabufs, I think everyone just copied the code from llvmpipe
15:44 idr: glehmann: I'd prefer to not merge !399987 until we at least understand why that commit causes a unit test failure.
15:45 idr: Having a future bisect hit a commit that fails 'ninja test' will be annoying.
15:45 glehmann: it's not failing for me, but sure
15:45 idr: Ah... I see you just updated the MR. :)
15:45 idr: Really?
15:46 glehmann: I think the issue probably is that the pattern uses fp range analysis for an integer operand
15:47 glehmann: but then again, unsigned zero should be a subset of fp zero...
15:47 idr: https://people.freedesktop.org/~idr/nir_opt_algebraic_pattern_test.b2i16_vec2_uge_uge.txt
15:48 idr: I am now seeing the result is unsupported... which doesn't make sense.
15:50 glehmann: do you only see that on the one commit?
15:50 alyssa: idr: the fp range queries are pretty special in the algebraic unit tests, could be related
15:52 glehmann: ah now I see the fail too
15:53 idr: glehmann: I first hit it when my bisect landed at `nir: add fp class analysis for some intrinsics`.
15:53 idr: So it last for at least a couple commits.
15:58 glehmann: it goes away when I just add a proper uint search helper
15:59 glehmann: I think it probably regressed because all the constants it tried are zero or denormal floats
16:00 glehmann: so the condition was always false, and the test unsupported
16:01 glehmann: and maybe later changes caused a different random seed to be used for this pattern so it started working again?
16:03 idr: That's plausible.
16:03 idr: I have to take off, but I should be back around in 4 or 5 hours.
16:03 idr: I'll finish digging into the problem then.
16:03 idr: It looks like the potentially problematic Intel optimization is from 2013. ca675b73d3ac2e1b57ec385c2c80b05b6382f6b6
16:06 glehmann: yes that looks completely broken for NaN :D
16:06 alyssa:is trying to spot the bug
16:07 alyssa: sel.l.sat(NaN, 1.0) = sat(NaN < 1.0 ? NaN : 1.0) = sat(1.0) = 1.0
16:07 alyssa: ah. that'd do it. :p
16:23 glehmann: idr: alyssa: I pushed https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39987/diffs?commit_id=8ad775718e8b3adf0a42b5376153a76a505eb69a
16:26 alyssa: glehmann: rb
17:54 sima: robclark, oh yeah, was more thinking of the existing dma-buf import/export tests, which sadly is tied to i915 for historical reasons
17:55 sima: I think there's xe copies now of some of them, but would be nice to avoid tying to specific hw if we can
17:55 sima: no idea about dma-buf heaps tbh, but isn't really harder to enable for CI systems than vgem
18:48 karolherbst: mhh what's the difference between nir_address_format_64bit_bounded_global and nir_address_format_64bit_global + has_load_global_bounded?
18:52 karolherbst: oh nvm.. I got confused