15:05 cheako: I don't know if this has been done b4, but while testing AMD drivers logging how long each vulkan call took ended up being important. So I'm writing a vulkan timing tool, is that just a profiler. It'll help inform the design of my next project.
17:34 DemiMarie: iive: the architecture supports unaligned access for normal memory but not device memory. Due to various bugs on lots of hardware, it is impossible to expose PCI memory windows as normal memory. They must be exposed as device memory, and that means that unaligned access faults. The one and only workaround that doesn't break existing userspace is to emulate the operations in software.
17:46 iive: DemiMarie, so the kernel driver exposes device memory to userland applications (like mesa and nvidia drivers) and nvidia uses it as system ram.
17:51 iive: is it possible to give system ram buffers to the apps, when it's not mmap-ed hardware registers.
17:51 iive: i do assume the registers have fixed aligned addresses.
18:19 DemiMarie: The problem is not registers but memory. Accessing PCIe BARs with memory semantics is generally broken on Arm and should be considered unsupported. This means that unaligned access is also unsupported. Instead, userspace should be designed to never make unaligned accesses to VRAM.
18:34 soreau: emersion: so your test program https://paste.sr.ht/~emersion/08ed9c28dca9b1c22b48e1943fda5b7995a52e9b segfaults with radeonsi but works with zink (the output is "modifier: 0x0" from zink) should I mention this in the MR? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725
18:35 soreau: I'm trying to find a simple test application such as this that drives the point home instead of 'this fixes hwcursor for wlroots'
18:36 emersion: ah
18:36 emersion: i need to look at it again
18:37 llyyr: if an application picks a swapchain format with 16 bits per channel on vulkan, what is responsible for making sure the contents are dithered before being presented on the display? if it's the application itself, how can it know whether it should dither to 8bit/10bit etc.
18:37 emersion: i'll just marge it if it has a good commit message
18:37 soreau: emersion: ok
18:42 zamundaaa[m]: <llyyr> "if an application picks a..." <- That's handled by the compositor or kms driver
18:42 zamundaaa[m]: The application doesn't have to care about the scanout format, beyond what information it gets from the compositor through dmabuf feedback
18:43 llyyr: could it be then that amdgpu isn't doing any dithering (on both windows and linux) or it's too low quality
18:56 zamundaaa[m]: llyyr: it definitely does scanout dithering
18:57 zamundaaa[m]: If the compositor outputs 10bpc. If you're on Xorg, you only get 8bpc without dithering afaik
19:05 llyyr: zamundaaa[m]: context: https://github.com/mpv-player/mpv/issues/11862#issuecomment-1621699347
19:06 llyyr: currently mpv just tells users to set dither-depth to whatever their compositor is outputting, because driver dithering is not reliable or is too low quality to the point where you can tell the difference with bare eyes
20:19 Company: llyyr: after dealing with the AMD Vulkan driver and its (lack of) features on Windows, I wouldn't be too surprised
20:20 Company: at this point I have the suspicion that AMD has different developer teams for their GL and Vulkan drivers instead of sharing at least wsi parts like Mesa does