02:18 Lynne: does enabling an extension at device creation time, but not giving e.g. VkPhysicalDeviceShaderObjectFeaturesEXT in the pNext chain enable all supported features?
02:22 bnieuwenhuizen: No
02:22 Lynne: I know what happened, this was definitely the work of a d3d12 spy
02:24 Lynne: the meeting this was decided on must have gone on for at least 16 hours straight, because otherwise no one rational would have said "yeah, that's a pretty good idea"
02:29 JoshuaAshton: Well, some features are anti-features such as buffer device address' replay features. Some features come at a cost.
02:36 Lynne: you can still disable them if you need to
02:37 Lynne: needing to opt-in to extensions just means a lot more ifdeffery if you want to keep compatibility with old headers, which sadly, is required unless you want your users to send you poison pen letters
02:38 JoshuaAshton: I just add Vulkan-Headers as a submodule
02:41 Lynne: we don't do submodules in ffmpeg, we're stuck in 2001 and that's just the way we like it
02:41 JoshuaAshton: Then just ship the headers? :p
02:41 HdkR: ooo, package maintainers love that one. It's great
02:41 Sachiel: package maintainers wouldn't notice
02:42 Lynne: yeah, we don't ship headers either, particularly because we need to expose certain vulkan structures as public API, and good luck synchronizing with API users
02:42 HdkR: Maybe I need to stop putting things in to an explicit Externals/ directory. Might be easier to skirt around :D
02:43 JoshuaAshton: They have in the past, and have made issues against several of my repos, but typically it just involves explaining that Vulkan is ABI stable and there is nothing to worry about.
02:43 Lynne: also there are no good options to merge vulkan-headers
02:44 JoshuaAshton: wdym by merge?
02:44 Lynne: a gigacommit "update vulkan headers" like they do at Vulkan-Headers upon every release is just awful to git log -p
02:44 Lynne: a merge-commit is awful because merge commits are awful
02:45 Lynne: and an individual rebase can't be done because khronos does gigacommits to update headers
02:45 Lynne: clearly git submodules are the better option, but git submodules are awful too
02:46 Sachiel: we do the "update vulkan headers" in mesa and I'm not aware of any issues with it
02:46 Lynne: following the UNIX way is the better option, have good packaging for each distribution and regularly update it
02:48 JoshuaAshton: In an ideal world, you would be right, but unfortunately the packaging philosophies of many distributions make that an impossibility.
02:48 Lynne: but khronos, google, et al. don't know what pkg-config is and its evident they don't understand what dynamic linking means either, otherwise the queue API wouldn't be designed the way it is designed today, with users requiring mechanisms to trade global per-queue locks
02:48 Lynne: actually they do know what dynamic linking is, since statically linking libvulkan on windows is officially unsupported
02:49 airlied: just copying the files in like mesa does is probably the best actual answer, for the headers
02:49 JoshuaAshton: I could not imagine a world where mesa would ever use the system Vulkan headers, it would be the worlds worst spam of useless ifdefs to compensate for people who want to build on Vulkan 1.0.0 known to mankind
02:49 Lynne: (so on the most popular platform, they expect you to ship your own headers, but not expect you to statically link?)
02:50 JoshuaAshton: Because libvulkan is just the loader
02:50 Lynne: I'm not saying vulkan 1.0.0, we target 1 year old headers, which isn't that horrible
02:51 JoshuaAshton: The typical usage for end users, is you use something like volk or call vkGetInstanceProcAddr, etc yourself and just build against the latest headers
02:51 Lynne: we do all that, we just don't ship our own headers
02:52 Lynne: volk's total running code is literally less than 20 lines, lol
02:53 airlied: I think for ffmpeg just shipping the headers is easiest option
02:54 Lynne: and then we'd have #include <libavutil/hwcontext_vulkan.h>; #include <vulkan.h> issues, since we need definitions for our external API
02:54 airlied: why?
02:54 airlied: just include vulkan.h from the headers you bring in
02:55 JoshuaAshton: Then the include guard can deal with the rest
02:55 Lynne: include guards will prioritize the first included vulkan headers copy
02:55 Lynne: which can be ours
02:55 JoshuaAshton: That's what I mean, that's what I would do
02:55 Lynne: telling users "oh, you need to include your own vulkan header first" is just bad design
02:56 Lynne: plus, packagers will dislike it, and all developers will dislike it
02:56 airlied: do you expose that level of internals in the external API
02:56 airlied: ?
02:56 Lynne: we expose vkqueues, vkimages, vksemaphores, vkdevices, vkphysicaldevice, and I think that's all
02:56 JoshuaAshton: why not just forward declare then?
02:57 airlied: so you could have your installed headers just pick up from the system
02:57 Lynne: its still means shipping hundreds of thousands of lines of autogenerated headers
02:58 Lynne: or at least carrying them in our repo
02:58 Lynne: and like I mentioned earlier, updating them is not a great solution
02:58 Lynne: we still use mailing lists, you know?
02:58 airlied: you could just make the bump to new headers an exception :-)
02:59 airlied: like in theory you should be able to bump at any time with no problems
03:07 DemiMarie: JoshuaAshton: which distributions are the problematic ones?
03:11 JoshuaAshton: DemiMarie: Many distributions have policies, such as Debian, in which they freeze package versions for stable. For example their vulkan headers are of 1.3.239 on bookworm right now, which is pretty old, coming up on 2 years now in a few months...
03:12 DemiMarie: JoshuaAshton: is this why desktop app developers decided to bundle everything in a Flatpak/Snap/Appimage/etc?
03:14 JoshuaAshton: I don't think that is the sole reason, but I think it's pretty high up there in terms of why I would consider targeting Flatpak, etc as a desktop app developer.
03:14 JoshuaAshton: but for Vulkan headers alone, that probably isn't the reason -- especially as you can just ship your own.
03:16 JoshuaAshton: but to use those Vulkan headers................... you'd need a newer driver and probably want other newer dependencies too and etc etc
03:21 Company: Vulkan headers do remove stuff
03:22 airlied: true there have been times with beta stuff and with maybe some vendor exts?
03:22 Company: yeah
03:23 Company: we copy the VkResult error message strings into GTK proper
03:23 Company: and once or twice there have been deletions of VkResult values
03:24 Company: I think it's usually very experimental extensions, but it'sa bit weird that they get deleted in some point release
03:26 Company: I think there's a requirement even in Vulkan to do some #ifdef check for those extensions, so it's technically GTK's fault, but it is unexpected with how Linux stuff typically works
03:27 Company: but it's understandable that Debian stable wants to freeze the version
03:37 Lynne: yeah, when unstable extensions go EXT->KHR they do remove the old defines
03:39 Lynne: when an extension is promoted to Vulkan 1.N, all of its features are added to VkPhysicalDeviceVulkan1NFeatures, right?
03:39 Lynne: what happens if you put both the extension's struct and the 1N struct in the pnext chain, and the values differ?
03:40 Lynne: I guess the last struct's values are used
03:40 Lynne: but is it guaranteed that all of the extension's values will be added to the Vulkan1N features struct?
03:41 Company: I would expect the spec to say something about it - maybe the validation layer even knows
03:41 Company: but I can see a large project adding a Vulkan1.1 features thing for one extension while still having an extr struct for another feature in the pnext chain
03:43 Company: like adding multiview but having YCbCrFeatures in the pnext
03:45 misyl: Lynne: The only time that ever happens is for the beta extensions, which are the only things that have an unstable abi like that
03:46 misyl: When regular extensions are promoted EXT -> KHR or to core, the old defines are just aliased
03:47 Company: Lynne: another fun interaction that I remember GTK and hk having is that alyssa had fogotten to advertise an extension promoted to Vulkan 1.1 and I had just enabled the extension if version >= 1.1 without checking it
03:48 Company: was a fun question about whose fault that was
06:42 airlied: fyi marge seems dead
06:44 soreau: she must have been assigned a fatal MR
06:49 airlied: :-P
07:48 MrCooper: HdkR: Xwayland also uses DRM_IOCTL_SYNCOBJ_EVENTFD
08:00 fulldenial8: And by the way you thought you had an upper hand in my abuse case despite your bully trash all kicked out from freenode, but this was never so, and so thought the orphanage house magpie gloria terreur, that we simply abuse you and talk about our mob gangsters and take your assets , in reality the magpie was given shots several times and her half brother was handled same way, i did not
08:00 fulldenial8: want to become their retardeds mob tank driver, even though the upper hand surely belongs to me, though i am affiliated with science breakthroughs and in general in the era of many science subfields. But my associates say which i agree with, i should not do lessons of technology anymore, we know i am chipped and i fuzz everything i do, cause i do not want retarded people into my life. And
08:00 fulldenial8: i do not suffer, cause i am no longer active on things that cause terror at me, suffering is an envious people retaliating for what you are in the world of sports and cinematography, media and such, which i have all already banned out in reality, so as long as i do not achieve nor perform publicly i do not suffer, cause abortion leftovers do not envy me enough to retaliate.
08:01 fulldenial8: simple and easy.
08:07 austriancoder:is looking for someone to review a src/mesa/main/formats.csv related change: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3418/diffs?commit_id=1d194e9316989cae8a00ab4062de84c332b7dc01
13:08 alyssa: Company: (it was mine)
13:09 Company: the question we didn't agree on I think was if my code was technically correct
13:12 alyssa: the user's always right?
13:12 alyssa: :P
13:14 bl4ckb0ne: does it makes sense to use a timeline semaphore for acquire/submit/present ?
13:16 dj-death: bl4ckb0ne: I don't think vulkan timeline semaphores are allowed for this
13:16 emersion: sadly not yet
13:16 dj-death: VUID-vkAcquireNextImageKHR-semaphore-03265
13:16 dj-death: semaphore must have a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY
13:16 bl4ckb0ne: for acquireimage ?
13:17 dj-death: same deal
13:17 bl4ckb0ne: ah yeah its in the validation id
13:17 bl4ckb0ne: well, that answers my issue then, thanks
15:24 austriancoder: daniels: you have been reviewing changes in that file .. soo .. what do you think about this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3418/diffs?commit_id=1d194e9316989cae8a00ab4062de84c332b7dc01
16:19 DavidHeidelberg: On a phone befoe immigration check, but can someone verify that "X11: fix crash of gnome-shell if mesa is compiled with legacy-x11=dri2" is ok? It got into 24.2.4 and by commit name I have feeling it's not intended to :(
16:19 DavidHeidelberg: I saw the commit somewhere when reviewing i915 stuff, but what I recall it wasn't commit to merge as-is, but maybe I'm mistaken
16:20 DavidHeidelberg: eric_engestrom: daniels: ^
16:22 daniels: eric_engestrom: what about it seems wrong?
16:23 daniels: DavidHeidelberg: ^
16:24 DavidHeidelberg: No idea, I just recall it from aome MR and it felt like hack, but maybe it's ok now, or if it look solid, then fine.
16:24 DavidHeidelberg: I was afraid I accidentally merged some commit in MR which shouldn't got in
16:25 daniels: I didn't see it go by, but it does lgtm
16:25 DavidHeidelberg: Good :) (relieved_smile)
16:59 eric_engestrom: DavidHeidelberg: I chose to include it even though its author (who's not a regular contributor) didn't include a backport tag, because it looks entirely correct to me, and it looks like it had been "working" by accident until then by the fact that apparently on some/most systems, `*NULL == 0`
17:00 eric_engestrom: I felt confident enough to do that without asking; maybe I should have asked anyway :)
22:52 Mis012[m]: does https://github.com/jhuber6/doomgeneric/tree/amdgpu only need the CPU for input? is there any reason one couldn't use an i2c gpio expander (with polling bbiously, there's no way you can route any interrupts to the GPU cores)
22:52 Mis012[m]: *obviously
22:53 Mis012[m]: I'd put that as a feature request but it seems issues are disabled :P
22:54 Ermine: seems like DRM_IOCTL_GEM_OBJECT_CREATE from that keithp's letter on GEM doesn't exist anymore?