05:08 Danct12: is freedesktop.org down?
05:08 Danct12: the acutal site, not gitlab
05:22 jrayhawk: Yes
05:22 jrayhawk: something went wrong with the graceful reload for log cycling
05:23 jrayhawk: it is at least ostensibly fixed now
05:24 jrayhawk: Thank you for pointing it out.
15:48 zackr: dakr: do you happen to know how with drm_gpuvm are userspace bits handling vulkan aliasing requirements? drm_gpuvm doesn't support aliasing, so what should happen if a vulkan app creates two buffers and binds them to the same address? (two separate vkCreateBuffer bound to the same vkAllocateMemory)
16:04 zackr: i'm assuming that the userspace makes vkr resources (buffers, images, etc) objects that are backed by drm_gem_object's and drm_gem_object are simply VkDeviceMemory
16:23 dakr: zackr, it's a while ago that I bothered with the userspace side of things, i.e. Vk. But I remeber that I always got confused by how things are named, so I have to page it back in.
16:25 dakr: Just to confirm: VkDeviceMemory -> handle to actual physical memory (drm_gem_object on the kernel side), VkBuffer -> GPU virtual mapping of some VkDeviceMemory (drm_gpuva on the kernel side).
16:28 zackr: dakr: perfect, thank you! and currently drm_gpuvm doesn't have any utilities for "just map this thing into a first spot that's available" does it? i need a vm for kernel allocated buffers as well, so i just have a simple gen_pool to keep finding ranges for new buffers, but i wanted to make sure i didn't miss anything
16:28 dakr: zackr, oh, well, that was a question. :)
16:30 zackr: hah, well, it made it click in my head so it became an answer
16:30 dakr: great!
16:31 dakr: And I think what I wrote should be correct.
16:31 dakr: Regarding your follow-up question:
16:32 dakr: No, GPUVM is not meant to serve as an allocator for the GPU's virtual address space. It only keeps track of it, help with eviction, etc.
16:32 dakr: It's meant to be used for a uAPI where userspace manages the GPU's virtual address space by its own.
16:32 dakr: So, you need some kind of range allocator in userspace for VkBuffer objects.
16:34 dakr: Or did you mean the kernel's VA space carve out with "kernel allocated buffers"? I think the term "buffer" is a bit overloaded. In the kernel we mean actual physical memory by that, whereas userspace with VkBuffer, means space in the virtual address space, where we can bind physical memory to.
16:40 zackr: dakr: yea, the userspace bits make sense. but i also have a bunch of kernel side buffers for various things and i need them mapped in the gpu va space so i have a dedicated drm_gpuvm for kernel created objects. iirc pvr does something like that for their firmware ops but they don't need a range allocator because they use the physical addresses of buffers as va ranges. i can't do that because tt in ttm_resources' which are dma memory array's aren't
16:40 zackr: guaranteed to be contiguous so that's why i have a gen_pool to just allocate ranges for those kernel objects, but i wanted to make sure i wasn't missing something
16:41 dakr: zackr, ah, I see. That sounds fine then.
16:42 zackr: awesome, thank you. hugs and high fives
16:42 dakr: yw. :)
19:37 airlied: zackr: nouveau carves out a chunk at the top of the address space for kernel
23:49 mareko: alyssa: could you ack this? you don't need to review it, but note that nobody else will probably review it, and I'll merge it: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36100
23:51 alyssa: mareko: I enjoy that you know that I'm the one to ping for that :p
23:51 alyssa: sure, will look
23:59 alyssa: left a few comments but looks fine to me