03:43DemiMarie: I’ve been convinced that userspace command submission is a good thing, if it does not expose new attack surface in the kernel and/or firmware by allowing userspace to do things it otherwise could not, and if the kernel is still in control of which rings are runnable at any given time. It seems that both of those hold on all recent hardware.
13:37karolherbst: is there a way to set cmake_module_path via a native/cross file in meson?
13:37karolherbst: ohh.. `-Dcmake_module_path` apparently works..
13:38karolherbst: well.. maybe it doesn't
13:41karolherbst: I'm git bisecting and cmake picks the wrong llvm 🙃
14:37dcbaker: karolherbst: you can set it on the command line or in the [built-in options] section. I think it’s module prefix though and has different semantics than pkg_config_path, namely that it points at a prefix like ~/install rather than pkg configs ~/install/lib/pkg-config
15:46Company: dzn doesn't like GTK's shaders
15:46Company: or rather: DXIL doesn't
15:47Company: considering the whole code says "this is massively experimental, don't use for anything serious" I decided that's expected, but wanted to mention that I tried playing with it
16:01MrCooper: Company: jenatali might have pointers for Windows software rendering in GTK's CI
16:04Company: I think I asked him before but there was no clear conclusion
16:04Company: other than native D3D12 being best of course
16:07Company: there was also the issue about how to get it installed in the CI runners - ie there's official packages for GLon12 but not for llvmpipe
16:07Company: though at least for Vulkan, you can just set an env var, so lavapipe in CI would work if you had a DLL
16:10Company: there's also the benefit that when using llvmpipe/lavapipe in CI, I get mostly the same behaviour as on Linux
16:10Company: which makes tests less likely to fail
16:11Company: stuff like rounding behavior when writing0.5 into a UNORM texture
16:12MrCooper: AFAICT the Mesa CI windows-msvc job builds lavapipe, not sure if that produces anything usable by GTK CI though
16:13Company: got a link to a DLL?
16:14Company: Vulkan is just VK_DRIVER_FILES=some_icd.json that has a path to a DLL, so things are easy to test
16:15Company: assuming that DLL doesn't depend on 15 other DLLs of course
16:16Company: I didn't try building llvmpipe yet because of the llvm dependency
16:19MrCooper: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/66270534/artifacts/browse/_install/ looks like everything's there
16:20MrCooper: not sure if there's an official / stable way to get Mesa CI job artifacts though
16:23DemiMarie: Company: dzn is Vulkan 1.0, do you need more than that?
16:27Company: DemiMarie: shouldn't need more, no
16:29DemiMarie: Company: have you reported a Mesa bug?
16:29Company: no
16:30DemiMarie: might be an option
16:31Company: yeah, but I didn't want to spend lots of time on it unless there's interest in me doing it
16:31Company: from my side it was just an experiment to see what would happen
16:38Company: MrCooper: is that lavapipe DLL just build or also tested?
16:38Company: because I get https://i.imgur.com/uJ35rJr.png
16:38MrCooper: not tested AFAICT
16:38Company: which looks like a mismatch with the Windows ABI somewhere
16:39Company: happens deep down in some llvmpipe thread during startup
16:40MrCooper: fun
17:05alyssa: Company: aren't all the windows vendors shipping native vulkan these days?
17:06alyssa: iirc qualcomm wasn't but I thought that changed?
17:06alyssa: or maybe i dreamed that
17:06alyssa: ..or is this for WSL i guess?
17:06DemiMarie: alyssa: Vulkan on Windows doesn’t let you provide buffers that the Desktop Window Manager can use, so transparency does not work well.
17:08jenatali: Company: Can you elaborate on "doesn't like"?
17:09jenatali: Demi: dzn is Vk1.2
17:09DemiMarie: jenatali: https://mesamatrix.net only lists it as 1.0
17:10Company: alyssa: this is (1) I want to be able to debug what I'm doign wrong and I'm used to read source code - which is why I wanted dzn over "error in amdvlk.dll"
17:10alyssa: ahhh
17:11alyssa: yeah, fair
17:11Company: alyssa: and (2) I'm looking for a way to make our CI run the Vulkan tests on Windows
17:11Company: so that I can check that vkImportMemoryWin32HandleKHR() and VK_KHR_surface_win32 usage and whatnot is correct
17:12Company: jenatali: I only tried to run it and it returned OUT_OF_MEMORY errors because DXIL.dll didn't convert things right
17:13jenatali: Company: Got something for me to debug?
17:17DemiMarie: jenatali: is MesaMatrix mistaken there?
17:18jenatali: Demi: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/features.txt?ref_type=heads#L426 is wrong
17:19DemiMarie: jenatali: do you mean lines 428 (Vulkan 1.1) and 454 (Vulkan 1.2)?
17:20jenatali: I just mean that overall section of the file is stale
17:20DemiMarie: jenatali: also, that reminds me: does any part of Windows call the WDDM KMD interface _other_ than via the UMD?
17:20DemiMarie: Ah
17:21DemiMarie: The reason I ask is because the most obvious way to support virtio-GPU native contexts on Windows is DXVK + Mesa in userspace talking to a Windows virtio-GPU KMD, but I am not sure how hard it would be to expose the WDDM interfaces, some of which (such as modesetting) do not even make sense.
17:25jenatali: Windows has a paravirtualization infrastructure with a publicly documented protocol
17:26jenatali: Company: Just to be clear, dzn converts SPIR-V to DXIL internally, but then D3D expects the resulting DXIL to be validated and "signed." DXIL.dll is the validator. It was closed-source but that recently changed: https://devblogs.microsoft.com/directx/open-sourcing-dxil-validator-hash/
17:27jenatali: But yeah lavapipe should also work just fine
17:35Company: jenatali: I end up in https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/microsoft/vulkan/dzn_pipeline.c#L475
17:35Company: during one of the shader compiles
17:35jenatali: Company: Can you pastebin the log output?
17:35Company: and err is NULL
17:36jenatali: Oh, that just means that you don't have dxil.dll present
17:36Company: maybe I'm using the wrong dxil.dll or so
17:36DemiMarie: jenatali: Are there any open-source host-side implementations of that interface?
17:36Company: which one do I want?
17:37jenatali: Company: It comes from https://github.com/microsoft/DirectXShaderCompiler/releases/
17:37jenatali: Demi: Not that I know of
17:37Company: where do I put those files?
17:38jenatali: Just dxil.dll, next to vulkan_dzn.dll
17:38DemiMarie: jenatali: That would be a problem then, especially because Qubes OS generally puts complexity on the guest side to reduce attack surface. Where is the protocol documented?
17:40jenatali: Demi: Here's the Linux guest implementation: https://github.com/microsoft/WSL2-Linux-Kernel/blob/linux-msft-wsl-6.6.y/drivers/hv/dxgkrnl/dxgvmbus.c
17:40jenatali: I thought there were docs for it besides just code but I don't remember where off the top of my head
17:41Company: jenatali: same result
17:43jenatali: Company: Ah apparently dxcompiler.dll is needed to get the message: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/microsoft/compiler/dxil_validator.cpp#L321
17:44DemiMarie: jenatali: Ah, so that would require something to emulate Hyper-V’s VMBus. QEMU might be able to do that.
17:44Company: jenatali: I put that right next to it
17:45Company: maybe I need some debug flags?
17:47Company: how do I get the debug_printf()'s?
17:48jenatali: Company: Oh, apparently we don't do the same search shenanigans for dxcompiler.dll. Windows DLL search paths are next to the exe, in PATH, and in System32. For dxil.dll which is needed at retail, we explicitly also search next to vulkan_dzn.dll but for dxcompiler.dll which is only needed for debugging we don't
17:49jenatali: I thought debug_printfs go to stderr, maybe only in debug builds though
17:50Company: yeah, apparently needs EMSA_DEBUG which needs -Dbuildtype=debug
17:50Company: which is now rebuilding
18:06Company: VSCode cross-project debugging is not the greatest thing
18:10jenatali: Company: If you can extract the SPIR-V that's failing (text or binary) and file an issue I can take a look
18:12Company: first I get this working
19:00Company: I hve no idea why Windows claims it loads DLLs in PATH and then it doesn't - I bet there's some weird security flag somewhere that nobody talks about that disallows this somehow
19:02Company: error: Semantic 'TEXCOORD' overlap at 3. Validation failed.
19:06jenatali: Ah I/O var issues, fun...
19:09Company: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gsk/gpu/shaders/gskgpuborder.glsl if you want to look
19:10Company: (I'm not too proud of the madness that is our shaders though)
19:13jenatali: Company: how do I get that to SPIR-V?
19:14Company: it uses glslc to build it
19:14Company: see meson.build for the cmdline
19:15Company: or I can paste you the generated spirv
19:16jenatali: That'd be great :)
19:17Company:abuses gitlab:
19:18Company: jenatali: should be https://gitlab.gnome.org/-/snippets/6640
19:24jenatali: Company: 404
19:25Company: oh, because you don't have a gitlab account?
19:25jenatali: I had to create one before I got to the 404
19:26Company: I don't know a place where to upload binaries :o
19:26jenatali: spirv-dis and upload text?
19:27jenatali: Mesa gitlab issues allow attachments which can be binaries
19:27Company: yeah, good idea
19:27Company: lemme file an issue
19:33Company: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12128
19:34jenatali: Cool, thanks
19:56jenatali: The problem is the structs in the I/O FYI, I think this should be straightforward-ish
19:58Company: the push constants?
19:58jenatali: No, PASS_FLAT(2) RoundedRect _outside;
19:58Company: oh, because those are structs, right
19:58jenatali: There's disagreements between whether that gets one index or three
19:59Company: oh, because it can be a could be a mat3x4 or 3 vec4s
19:59jenatali: Yep
21:39jenatali: Company: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32047 compiles that single shader for me, let's see if CI blows up
21:39jenatali: I expect this is going to actually fix a bunch of GL tests
21:42Company: let's see what happens when I build it
21:44Company: how does spirv_to_dxil compare with spirv cross btw?
21:44Company: if I ever attempt a D3D12 backend for GTK
21:46jenatali: spirv-cross goes to HLSL. spirv_to_dxil does not
21:47jenatali: From a performance standpoint it should be faster
21:47jenatali: Not that I've personally measured it though
21:47alyssa: they also.. solve different problems, I think?
21:48Company: I just need dxil I guess
21:48alyssa: also i assume in the near future, you can just throw glslang spirv at d3d12 maybe..?
21:48Company: in the end I just have some fairly simple code that needs to create glsl, spirv and dxil
21:49jenatali: Maybe. TBD what D3D's SPIR-V environment will look like relative to GL/VK and whether glslang will be updated to produce it
21:50jenatali: Clearly the solution is to also upstream GLSL into Clang :P
21:51Company: at least that would produce better error messages
21:53Company: success
21:54Company: well, it compiles all the shaders, then displays half a second of stuff, then it gets a VK_ERROR_OUT_OF_POOL_MEMORY - but I'll blame GTK for that for now
21:56Company: yup, it's GTK's fault
21:56Company: we're waiting for OUT_OF_POOL_MEMORY, then reallocating the pool - but we also get a debug report about the error and we report on errors
21:56Company: whoops
21:57jenatali: :)
22:37Company: booo!
22:37Company: dzn claims it does VK_COMPOSITE_ALPHA_PRE_MULTIPLIED_BIT_KHR but I get black borders
22:40jenatali: Company: Try modifying wsi_win32_surface_create_swapchain_dxgi ?
22:40jenatali: DXGI_ALPHA_MODE_PREMULTIPLIED
22:42Company: oh
22:42Company: that looks like an easy patch
22:42jenatali: Yeah probably just an oversight
22:42jenatali: WSI stuff is hard to test
22:44Company: it can even do unpremultiplied alpha
22:57Company: jenatali: looking at this, here's another fun question: On VkSwapchainCreateInfoKHR.clipped == TRUE, is setting DXGI_SWAP_EFFECT_FLIP_DISCARD valid or not?
22:57jenatali: What's clipped supposed to do?
22:57Company: I know I've had this discussion before
22:57Company: that's for the old X11 model
22:58Company: when the buffer is shared between multiple swapchains and it's using clipping to restrict which images get drawn
22:58Company: *which pixels of the image
22:58Company: but various developers have interpreted that as "may discard buffer contents"
22:59jenatali: Ah ok. D3D11 had a "guard rect" feature that did this but 12 doesn't
23:00jenatali: If you're interpreting it as "may discard buffer contents" then sure, flip-discard would be valid. In practice there's not much difference these days
23:01jenatali: Originally it was to allow an optimization where the compositor would "reverse compose" overlay content into an app's swapchain and then send it out to display, to optimize for fill rate. Nowadays everything just uses multiplane overlay hardware to do that, so that path is dead AFAIK. It was always buggy anyway
23:03Company: yeah, it feels like it can go wrong
23:04Company: so I'll just not touch it if it's not worth it
23:04jenatali: Yeah it's not worth it
23:24Company: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32048