04:08 DemiMarie: Is the overhead of robust access likely to be significant for a compositor?
05:22 emersion: DemiMarie: robust access is unlikely to be enough, hw is not allowed to crash but is allowed to return arbitrary contents
11:33 bg6vml: hi there. I'm cross-compiling the mesa 24.2 onto aarch64 platform. I created the cross file for meson tools and configured the compilers such as cc, rustc and so on. But when I build the project, I'm confronted with the error 'attempt to compute `4_usize - 8_usize`, which would overflow' in file src/gallium/frontends/rusticl/rusticl_opencl_bindings.rs. Could anyone help with it?
15:21 DemiMarie: emersion: Yikes. I thought the Vulkan spec limited the values that could be returned.
15:21 DemiMarie: Does this mean that every compositor with dmabuf support has a security vulnerability?
15:23 DemiMarie: Where should a validation library be?
15:29 emersion: I'd say just audit and fix the drivers
15:30 emersion: there are many things a driver can get wrong, it's just one more thing
15:43 dj-death: the various robustness extensions feature specify the returned values in case of OOB accesses
15:43 dj-death: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_EXT_robustness2.html
16:12 DemiMarie: emersion: does that mean that validating buffer sizes is not feasible?
16:13 DemiMarie: Is there a Vulkan API for checking if a buffer is large enough?
16:21 DemiMarie: emersion: What needs to be fixed?
16:21 emersion: I don't know, maybe all drivers check the sizes correctly
16:22 DemiMarie: Which API calls are you referring to?
16:23 DemiMarie: Is there a specific API call where the sizes get checked?
16:41 emersion: DMA-BUF import IOCTL, and the driver-specific APIs to create BOs maybe
16:42 emersion: maybe FB create as well? don't remember if the size is passed there
16:42 emersion: hm actually maybe DMA-BUF import has no size and FB create has one, don't remember
16:45 dj-death: anv lseek in the buffer to figure out the size
16:45 dj-death: and bails if it is too short
16:45 DemiMarie: How does it figure out the required size?
16:47 DemiMarie: The hard part is turning a (width, height, stride) tuple into a size.
16:54 bl4ckb0ne: height * stride?
17:11 dj-death: DemiMarie: any VkBuffer/VkImage created has a size associated to it
17:11 dj-death: DemiMarie: that's why you can call vkGet(Buffer|Image)MemoryRequirements()
17:16 DemiMarie: dj-death: How do I know what to pass for the many seemingly-irrelevant parameters, such as concurrent access mode?
17:16 DemiMarie: dj-death: I don't think any of the current compositors do this.
17:17 DemiMarie: I'm not writing a compositor, but rather a proxy that sits in front of it.
17:47 dj-death: DemiMarie: you mean this https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkSharingMode.html ?
17:48 dj-death: DemiMarie: if you don't know what the compositor will do, then you can't know I guess
17:49 DemiMarie: dj-death: will it ever matter on Linux?
17:49 DemiMarie: I thought the required buffer size was entirely determined by width, height, stride, offset, format, and modifiers.
17:51 DemiMarie: The client certainly doesn't know that information when it allocates buffers.
17:53 Sachiel: the client asks the driver the requirements and passes that to the allocation function
17:54 Sachiel: anv will check the imported bo is at least as large as the image is supposed to be and if not, it fails the import
18:00 DemiMarie: This seems like a Vulkan spec bug to me: to properly allocate buffers, a Wayland client must know various implementation details of the server, but it does not (and should not) know those details.
18:07 Sachiel: the client asks the driver "to allocate memory for this buffer/image with this characteristics, what do I need?", the driver gives back the details, client calls the vkAllocateMemory() with those details
18:08 Sachiel: I don't see the issue
18:11 Company: DemiMarie: the client and the server do not communicate Vulkan images
18:12 DemiMarie: Company: doesn't the client needs to be able to allocate a dmabuf that the server will be able to make a Vulkan image from?
18:12 Company: they communicate dmabufs and you must create a VulkanImage suited for export on the client (and then export it) and a VulkanImage suited for importing that dmabuf
18:12 Company: yes
18:12 Company: which can and does fail all the time even if both are cooperating...
18:13 DemiMarie: Does that mean that whether the creation succeeds must not depend on factors like VkSharingMode?
18:14 Company: it might eb that certain flags must be set to certain values or images cannot be exported
18:15 DemiMarie: My understanding was that Mesa uses create_immed because it can't handle an error. However, that means that if image creation fails the client gets disconnected. Changing VkSharingMode must not break a non-buggy client, so this means that the client must be able to pick a buffer size that works for any VkSharingMode.
18:15 Company: the buffers that Mesa shares with the compositor are created by Mesa
18:15 Company: not by the client
18:16 DemiMarie: Mesa still doesn't know what the compositor will pass for things like VkSharingMode
18:17 Company: no
18:17 Company: but VkSharingMode is about queues, not about inter-process sharing
18:18 Company: and even then, there's fun like and https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkPhysicalDeviceImageDrmFormatModifierInfoEXT.html where you get to query what values you're even allowed to use
18:18 DemiMarie: Does that mean that VkSharingMode (and all of the other parameters that the client does not know or provide) are not allowed to influence the minimum buffer size required?
18:18 DemiMarie: Assuming that they fall within valid usage.
18:19 Sachiel: pretty sure all of that is already specified in the spec, go read it
18:19 Sachiel: there's an entire section on resources that includes all about how memory allocation works
18:20 Company: Vulkan is just an API that sits on top of the basic buffer sharing API anyway
18:21 Company: and you can share buffers without using Vulkan or GL just fine
18:22 Company: the thing that Vulkan and GL do is various syscalls programming GPUs in fun ways
18:23 Company: which again can be done entirely without Vulkan or GL, they're just syscalls
18:23 DemiMarie: What I need to know is how big a buffer needs to be for a given width, height, and other parameters.
18:23 DemiMarie: I don't want to go through Vulkan or OpenGL for that if I can avoid it.
18:25 Company: I don't know if gbm has that info - usually this whole PI works by just allocating a buffer on the device you intend to use and then that buffer works on that device
18:25 Company: and if you get a buffer from a different device and try to use it, it may fail to import
18:26 Company: and if it does, developers from both sides will tell you you should have known in advance that this obviously wouldn't have worked
18:28 Company: but as long as you run the compositor on GPU 1 and the client allocated buffers on GPU 1, everything is fine
18:29 Company: you tell the GPU you want a buffer for WIDTH x HEIGHT in FORMAT and it tells you to use SIZE for it
18:29 Company: or does it?
18:29 DemiMarie: How do you tell the GPU that?
18:29 Company: it might just allocate the buffer for you
18:30 Sachiel: DemiMarie: the client will use what the spec says to use. You as a consumer don't allocate memory for the client to use, it's the other way around
18:30 Company: gbm_bo_create_*() I thin
18:30 Sachiel: if you don't want to use vulkan or gl, go read on gbm I guess
18:31 DemiMarie: I'll see about getting GBM to provide the needed size without allocating.
18:32 Company: I don't even know if "size" is an existing concept for such buffers, because memory management can be way fancier
18:33 DemiMarie: “size” as in “the value passed to Wayland”
18:35 Company: theres a size passed to Wayland?
18:36 Company: https://wayland.app/protocols/linux-dmabuf-v1 doesn't have a size
19:38 mlankhorst: There's a size you can get from fseek on the dma-buf. :)
19:46 Company: mlankhorst: that only works for linear ones, or?
19:50 dj-death: xantoz: all
19:50 dj-death: Company: all
19:50 dj-death: Company: kernel doesn't always knows what's in the buffer
19:52 Company: is that number useful for anything?
19:52 Company: on non-linear buffers I mean
19:55 pinchartl: does the buffer size depend on tiling ?
19:55 pinchartl: (probably a newbie question)
19:56 emersion: it does
19:56 pinchartl: for compressed formats I understand that the compressed and uncompressed sizes differ
19:56 pinchartl: but how does tiling affect the size in bytes ?
19:57 Company: I think Intel has different stride requirements for tiled vs untiled buffers
19:58 pinchartl: sure, but the size of the buffer in memory is still the same whether you look at it after or before tiling
19:58 pinchartl: if you have different formats (tiled vs. untiled) you may have different sizes for a given resolution
19:59 emersion: the size includes any paddinbg
19:59 dj-death: Company: just for mapping virtual memory
19:59 emersion: i don't know if there are uncompressed formats with a different effective memory usage
19:59 dj-death: Company: too small, no good
20:00 pinchartl: this reminds me I need to submit a talk proposal for XDC about buffer allocation
20:03 Company: I just know I VkMapMemory()ed image memory on intel a few times that I wasn't suppsoed to map and then was entirely confused about the bytes inside it
20:04 Company: but I didn't check the size of what I mapped, I was only interested in the bytes
20:07 HdkR: Get those talks submitted people, only two days left even with the week delay on the deadline!
20:08 pinchartl:clicks "Submit new abstract"
20:08 pinchartl: I hope there will be people interested in buffer allocation
20:08 emersion: there always are
20:09 emersion: (i am but will not attend)
20:09 pinchartl: there are three steps, in order of increasing difficulty
20:09 pinchartl: 1. agree that we need something better than what we have
20:09 pinchartl: 2. design the outline of the solution we want
20:10 pinchartl: 3. find someone to work on it
20:12 Company: 4. make the whole ecosystem actually use it
20:12 emersion: maybe a workshop would be better suited?
20:13 pinchartl: I've briefly discussed this with sima, she recommended submitting a talk proposal that can then be extended with a workshop
20:13 pinchartl: I'll pick a half-slot format, that will be enough to explain the problem and see if people are interested in continuing in a workshop
20:14 emersion: cool
20:15 emersion: i've discussed with sima last XDC and we had a start of an incremental plan with DMA-heaps
20:17 pinchartl: it would be nice to get James Jones to join too
20:17 pinchartl: perhaps remotely, I don't know if he plans to attend XDC
20:40 pinchartl: talk proposal submitted
20:49 pinchartl: (https://paste.debian.net/hidden/19096943/ if anyone wants a preview)
21:06 DemiMarie: Yes