07:51 bbhtt: Getting an error while trying to compile 24.2.0 "virtgpu_drm.h: No such file or directory"
07:51 bbhtt: Any idea ? https://dpaste.com/ETDRL68UF
07:52 bbhtt: the header exists in `/usr/include/drm/` I guess the include path is wrong?
08:06 bbhtt: i guess it should be `drm-uapi/virtgpu_drm.h`
13:07 dolphin: airlied, sima: Not sure of tursulin already pinged you, but no drm-intel-fixes picked up this week so no PR
13:34 sima: dolphin, ack
14:02 kisak: morning karolherbst, I'm thinking I should drop rusticl from the Jammy build to get rid of the bypass-to-build-with-llvm-15 shinanigans.
14:03 karolherbst: kisak: is that still such a mess?
14:05 kisak: I won't get a clear picture of how messy it is until I'm ready to try to move the Noble build to llvm 18
14:06 kisak: (instead of the nature of the universe 2 years ago)
14:07 karolherbst: what's the big blocker with any of this anyway? I thought it's mostly how it's nearly impossible to build the spirv binaries of libclc?
14:08 kisak: the big blocker is that bindgen is tangled into distro packaging all of rust or something. It's too much hassle to (significantly) version bump it on Jammy.
14:09 kisak: and that needed to also be rebuilt on llvm change.
14:11 kisak: There was some package restructuring between Jammy and Noble, so hopefully that's less ugly going forward, but I haven't looked into it in detail.
14:12 karolherbst: I see
14:12 karolherbst: yeah, and I guess that's fair enough
14:19 Lynne: are implementations free to support extensions but claim that no physical device features are supported when querying using vkGetPhysicalDeviceFeatures2?
14:22 pixelcluster: Lynne: usually not, this is defined in https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap46.html#features-requirements
14:23 pixelcluster: I can't 100% certify there aren't any cases where this was missed, but in general you should be able to rely on it :P
14:25 Lynne: oh, neat
15:27 tzimmermann: jfalempe, i had to send out another update to the ast bmc series. hope you can take another look
16:05 dviola: hi, can I close this: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9321 ? seems like the problem is gone (I can't reproduce it anymore)
16:06 kisak: if it's your issue report, you don't need permission from anybody to close your own issue report.
16:06 dviola: oh, okay
16:06 dviola: thanks
19:17 airlied: Lynne: though when things get rolled into core I think that changes
19:18 airlied: so yes you should always look at features
19:19 Lynne: yeah, I ended up keeping all the management code, its not too bad since there's no requirement that all the structs given to vkGetPhysicalDeviceFeatures2 need to be supported by extensions, unlike with device creation
20:50 glehmann: Lynne: wdym, you clearly aren't allowed to use vkGetPhysicalDeviceFeatures2 with structs from unsupported extensions
20:51 Lynne: well, there's another bug in the validation layer
20:52 Lynne: could you point to the part of the spec where it says that?
20:53 glehmann: https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#fundamentals-validusage-pNext
20:53 glehmann: Each structure included in the pNext chain must be defined at runtime by either:
20:53 glehmann: - a core version which is supported
20:53 glehmann: - an extension which is enabled
20:53 glehmann: - a supported device extension in the case of physical-device-level functionality added by the device extension <- this is the important part
20:54 glehmann: it's a bit weird because the spec mandates double safety, applications are not allowed to provide structs unknown to the driver, but drivers are also required to skip structs unknown to them
20:55 glehmann: many people are only aware of the second part, not the first
21:01 Company: I used to have code where I did if (extension_supported) { do_stuff_for_that_extension(); } during setup
21:01 Company: these days I first check all supported extension I care about, put them in some flags, and then do stuff with the ones I know exist
21:02 Company: makes stuff a lot easier when there's stuff I need to do for either ext1 or ext2
21:02 Company: (and I have an env var to manually disable flags for testing, so I can simulate less capable drivers easily)
21:28 piggz: hi ... im trying to package mesa 24.2 (upgrade from 24.1.4) ... but something is horribly wrong with the build, seems like no DRM/dri drivers are being build (lima/panfrost) even though ive asked for them to be built, and none of the kmsro drivers are built. Whats changed in the build system and any idea what im missing? so far nothing jumping out in the meson output
21:40 piggz: meson suggests it should be working?
21:40 piggz: Gallium
21:40 piggz: Enabled : YES
21:40 piggz: Drivers : softpipe llvmpipe virgl vc4 lima panfrost
21:40 piggz: Platforms : wayland surfaceless drm
21:48 zmike: sounds like it is
21:49 piggz: zmike: there is no lima_dri.so generated
21:51 zmike: what is the full summary of your meson configure step?
21:52 piggz: zmike: https://paste.mozilla.org/57twsgfW
21:54 zmike: looks fine to me
21:54 zmike: what is the issue you are having?
21:55 piggz: zmike: im expecting lima_dri.so and panfrost_dri.so drivers to be built
21:56 piggz: unless there is some architectural change?
21:56 zmike: you disabled all x11 support, so those files are not built
21:56 zmike: you only need them if you are running xorg, and based on your build it looks like you aren't
21:57 piggz: im not sure thats right .. ive always done it like that before, and this system runs wayland
21:57 zmike: the installed files have changed
21:57 piggz: what is used for wayland these days?
21:58 zmike: gallium
21:58 piggz: so, the lima support is built into libgallium_drv_video.so
21:58 piggz: ?
21:59 zmike: probably a different libgallium
21:59 zmike: but yes, that is the idea
21:59 piggz: ok, i was starting to wonder that...
22:00 piggz: ill alter the package, and see if sailfish on the pine phones still starts up!
22:28 piggz: zmike: thx, it appears to work, thanks for putting me on the right path!
22:28 zmike: glad to hear it
22:29 piggz: that gallium driver is quite the size, 28mb