14:41 <lsntvt> MoeIcenowy: what I don't understand is how / where the spec would support said assertion. The driver uses more memory and it is being transparent about it.

14:44 <MTCoster> The driver behaviour is spec compliant; it's allowed to require more backing memory for a buffer than just the buffer size. That's part of the reason vkGetBufferMemoryRequirements() exists in the first place, to separate the physical memory size from the "apparent" or "usable" buffer size. The more common use case here would be requiring all physical memory allocations to be rounded up to their alignment (which we do too)

14:45 <MTCoster> The check in the wsi_create_buffer_blit_context() is nonsensical as-is - why would you allow a physical memory allocation that's *smaller* than the buffer you want to store in it?

17:29 <enunes> gave a try today of the dev/bxs on TI AM69 (BXS-4-64). was able to build everything, run the triangle VK_KHR_display demo, with base Fedora 42 and upstream kernel 6.16-rc6

17:29 <enunes> in the kernel, the device tree node for this soc appears to be missing upstream, I put one together looking at the existing ones and TI SDK. I guess I could post a patch adding that node, nobody seems to have posted it yet?

17:29 <enunes> building the dev/bxs branch seems to have some race condition to generate some headers like csbgen/rogue_cdm.h , don't know if anyone else hit it? I had to generate it explicitly with the ninja target to continue..

17:29 <enunes> on the WSI part, I was able to run the new Weston vulkan renderer with it, one cool thing is to run it with the vnc backend, to skip drm integration. so it is able to run with the vulkan driver, no zink required, and get the output over vnc, though Wayland surface support still missing for Vulkan apps.

17:30 <enunes> but the interesting part is that allows to work on that Wayland integration part without having to resolve drm integration for now.

17:37 <MoeIcenowy> enunes: I hit the race cond

17:38 <MoeIcenowy> I think specific window system support is free if the WSI assert problem is resolved

17:39 <MoeIcenowy> See the commits in https://gitlab.freedesktop.org/icenowy/mesa/-/commits/pvr-os-hack

17:40 <MoeIcenowy> I enabled X11 support because I have some platform with DDX that can implement DRI3 with a 2D only GPU

17:42 <MoeIcenowy> BTW I am trying to move on KHR_dynamic_rendering for regaining Zink support, but looks like I need to satisfy a number of dependencies first

17:43 <MoeIcenowy> KHR_multiview -> KHR_create_renderpasses2 -> KHR_depth_stencil_resolve -> KHR_dynamic_rendering

17:55 <enunes> I remember solving an issue in v3dv which was going through this blit path instead of going through the native one, perhaps it should not be going through this wsi_blit path at all?

17:55 <enunes> anyway I'm refraining to do any sort of feature work like this until the downstream branch gets merged to mesa upstream, still really hoping for that to happen asap

20:05 <simon-perretta-img> MoeIcenowy: We have those three dependent extensions downstream, but need to get through the current upstreaming backlog before those can then go out

20:07 <simon-perretta-img> enunes: Probably going to try and do one big MR this week bringing upstream up to date (minus those extensions), and excluding hardcoded shaders (that are in dev/bxs); there'll be later MRs for those as they get implemented in nir/clc