01:34bl4ckb0ne: does panfrost have valhall support?
01:36HdkR: THere are zero Valhall Linux SBCs on the market
04:51jekstrand: Venemo: I'm inclined to say use nir_shader_instructions_pass because it'll inline
05:26jekstrand: Woohoo! Common Vulkan dispatch code at last!
07:14DrNick: it sure would've been nice if somebody had looked at COM in between the creation of OpenGL and the creation of Vulkan
08:28Venemo: jekstrand: I can use that one, but would prefer if there was a single way to do both.
08:33Venemo: jekstrand: what annoys me a little is that the filtering works a little differently between the two
09:55neobrain[m]: is gitlab having loading problems for anyone else currently?
09:56neobrain[m]: huh, works now. weird
09:57emersion: there's an upgrade going on
15:45jenatali: DrNick: Are you suggesting maybe Vulkan should've been a COM API?
17:01DrNick: learned from it, anyway
17:02DrNick: D3D11/DXGI proper have like 10 global functions, none of them device-specific
17:20bnieuwenhuizen: DrNick: if you look at the core of Vulkan that is very similar no?
17:21bnieuwenhuizen: most of the vulkan functions are just utility wrappers around the dispatch
17:22DrNick: but the utility wrappers have to be instance independent hence the code generation in that patch series
17:24bnieuwenhuizen: you mean https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8676 ?
17:25bnieuwenhuizen: I guess the instance wrappers for device functions are a thing but otherwise it is all in the loader
17:26bnieuwenhuizen: main thing the driver dispatch code does is vtable population
17:26bnieuwenhuizen: (wrt that series)
17:31DrNick: yeah, I guess I am complaining about the gross stuff the loader has to do instead of that patch series in particular
17:46ichernev: hello, I submitted a simple panel ~ month ago, https://lore.kernel.org/patchwork/project/lkml/list/?series=478425 the binding were approved, but there is no word on the actual panel spec
18:11airlied: jekstrand: nice!
19:21jekstrand: airlied: Rebasing and reworking things a bit right now.
19:21jekstrand: Trying to make common code even easier
19:21jekstrand: I'm hoping to get to the point where 90% of the time that we have a vkFoo2 in the API, drivers will only have to implement the 2 version.
19:26jekstrand: I'm also hoping that most drivers can delete almost all of their python.
19:29airlied: jekstrand: no driver python would be nice, or at least very minimal driver glue, but I do like the wrapping foo2, have you considered the 1.1 and 1.2 features/properties as well?
19:30airlied: for lvp it took me a while to work out what anv/radv were wrapping in the CORE_FEEATURE macro
20:01jekstrand: airlied: Yeah, I've thought about those.
20:01jekstrand: airlied: Those are a bit trickier because they would involve common handling some structs and the driver handling others. :-/
20:01jekstrand: But I think it could be done.
20:08jekstrand: It would also mean some sort of trampoline where common code runs and then calls driver code.
20:08jekstrand: Not sure I want to embed that much layering but we'll see.
20:12zmike: would certainly be nice for those of us who frequently debug multiple vk drivers on a daily basis :)
20:51jekstrand: Oh, man... This is shaping up so nicely....
20:51jekstrand: I've been wanting to do this for years. So glad I finally found a mechanism I don't hate.
20:53jekstrand: Just re-pushed the MR. Even better now!
20:53jekstrand: ANV now only has one bit of python codegen and it can now be easily replaced with C
20:53jekstrand: I should probably check driver size before/after the MR to be sure it didn't totally explode
20:54jekstrand: Even if it blew up a bit, getting rid of 5 no-two-are-the-same copies of ANV's code-gen is worth it.
21:06airlied: jekstrand: should I look at porting lavapipe to it?
21:06jekstrand: airlied: Yes, you should
21:06jekstrand: airlied: Everyone should port their drivers.
21:07jekstrand: airlied: I could probably do it to but uh... I'll happiliy spread the build system pain around. :)
21:08jekstrand: airlied: It shouldn't be a lot of work. Just inherit from vk_instance and vk_physical_device, delete your code-gen, and tweak a few things.
21:10airlied: jekstrand: I'll take a look today
23:09Plagman: jekstrand: this is cool
23:10Plagman: there won't be an extra stack frame in the way for api calls with common dispatch right? or any extra instructions needed?
23:14jekstrand: Plagman: Nope.
23:15jekstrand: Plagman: Maybe for the ones that hit the trampoline but that only happens for instance and physical device entrypoings and those are never on the hot-path.
23:15jekstrand: Also, if you hit a common wrapper like the one I added which implements vkBindBufferMemory in terms of vkBindBufferMemory2, those will have an extra stack frame and a function pointer call but, again, that's not a hot-path function.
23:27jekstrand: Hopefully, the #1 effect will be simplifying drivers and easing development over-all.
23:28jekstrand: And common code can be truly common instead of just providing helpers that we all have to wrap in dumb one-line entrypoints.
23:47airlied: jekstrand: okay have lavapipe working with it now (at least vulkaninfo :-)
23:54jekstrand: airlied: Cool. I've not touched my MR for an hour or so so feel free to push the lavapipe changes on top of it if you want.
23:54jekstrand: Or you can make a separate MR. I don't care.
23:56airlied: jekstrand: just pushed it on top then
23:56jekstrand: airlied: Your lavapipe patch has enough - lines to make up for all the code I added to make things common. \o/
23:57airlied: tempted to port radv now as well
23:57jekstrand: airlied: Go for it.
23:57jekstrand: airlied: I thought about porting things but I have no way to test other than CI
23:57jekstrand: I guess I could have ported lavapipe
23:57jekstrand: But ELAZZY
23:59airlied: oops forgot a git add, repushed