06:59 Lynne: so... why are shader objects not cached, again?
06:59 Lynne: fyi this is for compute shaders, for which there is no performance difference
07:06 Lynne: I get that it allows users to perform their own caching, but still, many ephemereal users would like to rely on the driver to do it for them
07:06 Lynne: plus its useful to know the binary size of a shader
09:00 pq: mripard, I see Daniel reviewed the state reset flag. Would you still *need* my input?
09:30 emersion: same question here :P
11:11 daniels: so you trust me eh? :P
11:29 pq: enough ;-)
14:44 soreau: so I have a basic glsl vertex and fragment shader that worked with gles. In order to use it with vulkan, I put it through glslangValidator which required some changes, and after getting it working with vulkan, it no longer works with gles.
14:44 mareko: the sentiment around ESO is justified because it's rather hard to make fast, that is if you use rigorous testing to prove what the perf is instead of living in a la la land where no perf tests are run and everything is beautiful
14:45 soreau: my question: is it possible to use the same glsl shaders for gles and vulkan?
14:48 soreau: I asked ai, it says #ifdef stuff
14:49 mareko: yes, that's a good idea
14:50 soreau: so the answer is technically yes, but no if #ifdef's are off-limits
14:50 mareko: either use #ifdef's or use SPIR-V in both GL and VK
14:50 soreau: hm
14:51 soreau: I didn't know you could use spirv with gl.. but how would that work with push constants..
14:51 mareko: #ifdefs in GLSL, then convert to SPIR-V
14:51 soreau: :P
14:52 soreau: mareko: ok thanks
14:52 mareko: or HLSL with HLSL->SPIR-V
14:53 mareko: or LLVM IR -> SPIR-V ;)
14:54 soreau: heh
14:58 soreau: the #ifdef's are doable, I just don't really understand why it has to be different byte code
15:00 Company: GTK uses #ifdefs
15:01 Company: the problem with Vulkan vs GL is the different semantics, mostly about how to handle uniforms
15:01 karolherbst: read the GL and Vulkan SPIR-V env specs, they may contain contradicting requirements
15:02 Company: and of course they have different features, but if you can use a common subset it's pretty doable
15:03 Company: spirv with gl can be a bit of a driver problem, depending on what platforms you target
15:04 mareko: gpu-ratemeter uses GLSL, and uses libshaderc for GLSL->SPIR-V for VK
15:04 Company: libshaderc is just a wrapper around glslang
15:05 mareko: now I just need to target HLSL/DXIL
15:05 Company: but glslang does not have a stable library, you're meant to include it in your codebase
15:05 Company: mareko: if you figure out how, tell me
15:06 Company: I've not managed to find a satisfactory method for GTK - spirv-cross wasn't flexible enough when I tried
15:06 mareko: alternatively I've been thinking about using HLSL and doing HLSL->SPIR-V for GL & VK
15:07 Company: do HLSL compilers produce good enough spir-v for Vulkan?
15:07 mareko: I've heard there are bugs
15:08 mareko: there is also the option of fixing spirv-cross using LLM
15:08 Company: I don't really care about the shader language, because GTK's shaders are simple enough, in fact I'd prefer HLSL
15:09 mareko: HLSL->SPIR-V is in DXC
15:09 Company: I've also looked at the various webgpu implementations and slang
15:10 karolherbst: be a real coder and use spirv-as
15:10 Company: but they all don't exist in distros, so it's a rather massice dependency in an area I have zero clue about, which makes me rather reluctant to switch
15:11 Company: if i was a real code I'd tell claude to pull nir out of mesa and make me a GLSL compiler
15:11 mareko: spirv-cross + LLM may lead to usable SPIV-V->HLSL
15:12 Company: it feels too brittle to do that
15:12 karolherbst: but yeah.. doing it by hand can also be quite messy.. you could also use ifdefs and compile it twice and assert that the binaries are more or less equal...
15:12 karolherbst: but I suspect that's not really doable as the SPIR-V might also differ?
15:14 Company: it's a bit of a problem with versioning, too
15:14 Company: if you target very modern spirv, it's easier to convert that to dxil - if you want Vulkan 1.0 there's more conflicts
15:15 Company: I think the main problem I had with spirv-cross was that it randomly decided to generate a different root signature for the DXIL, so my C code broke
15:16 Company: and the YUV stuff needs multiple SRVs on Windows but only one descriptor on Vulkan
16:00 jenatali: mareko: Out of curiosity, given the comments about GPL and ESO and perf, have you looked at D3D's partial programs design at all? So far we don't really have perf numbers yet other than gut feelings about how it should be and I'd be curious your opinion on it
16:01 jenatali: Company: Have you looked at Mesa's spirv2dxil? It hasn't gotten much love recently but it doesn't use HLSL as an intermediate
16:02 Company: nope, I didn't
16:02 Company: does spirv-cross use an intermediate?
16:03 jenatali: Yes, spirv-cross produces a source language that needs to be fed to another compiler
16:04 mareko: jenatali: it depends on GPU vendors implementing it optimally, it may be more difficult to implement optimally on some GPU architectures than others but not impossible; I can't speak for AMD since I'm no longer there
16:05 jenatali: Yeah, we've talked to the vendors and folks think it's reasonable, was just curious for an outside opinion :)
16:07 glehmann: I think D3D's partial programs are basically GPL
16:07 soreau: Company: my plan is to declare variables and then assign the uniforms to them in both #ifdef paths so I can use the variables in the code..
16:09 glehmann: hopefully the state split will be a bit cleaner than in vk, because like connor said GPL has some rough edges
16:10 glehmann: but the basic principle of not splitting vs/tes/gs is good
16:11 mareko: also not splitting TS and MS
16:17 mareko: AMD HW has quite unusual dependencies between states and shaders, e.g. if the FS uses the face sysval and doesn't know the cull face state and the pre-raster primitive type at compile time, it must insert shader code into the FS to get optimal perf with the face sysval
17:14 Company: MrCooper: rereading the discussion above, have you ever thought about how you are gonna do shader compilation in gnome-shell with Vulkan?
17:15 Company: because I guess you need runtime compilation if you want to support the snippet API for extensions
17:16 Company: kwin also hasn't figured out how to do effects if I understood zamundaaa's academy talk right; but for now the Vulkan stuff is using one big shader so it can do compile-time spirv creation
17:19 Company: weston uses glslang at compile-time
18:51 soreau: Company: I used glslang's C API and it seems to work fine without a ton of extra code
18:51 soreau: and I already have a shader working with gles and vulkan renderers with a few #ifdefs
18:52 soreau: without changing the main() { <code> }
18:57 soreau: glslang apparently #defines VULKAN for spir-v wiith vulkan target already
18:57 Company: glslang takes ages at startup, and I think it alloates 60MB or so
18:58 Company: which is fine for a compositor ofc, but people get annoyed when their image viewer doesn't open instantly
18:59 soreau: I 'interrupt' the compositor with ipc, pass it the full path to a fragment shader, build it and discard the source, including glslang init/fini
18:59 soreau: and it doesn't even glitch the compositor
19:00 Company: maybe I copied the wrong compiler config when I tried that
19:00 soreau: or maybe your shader is lengthy?
19:01 zamundaaa[m]: Company: I'd like to require effects to ship SPIR-V in addition to GLSL, but nothing's certain yet
19:02 soreau: but yea, the uniforms were just layout(push_constant) uniform uniforms { type name; }; #else uniform type name; #endif
19:02 zamundaaa[m]: 60MiB just for compiling shaders would certainly be a lot for a compositor, too
19:02 soreau: then use name as normal
19:02 Company: that works as long as you keep those shaders separate enough or have a well-defined API
19:04 zamundaaa[m]: KWin on my system uses 170MiB atm, increasing that by 1/3 just for the shader compiler would be quite sad
19:07 Company: one thing I'd definitely need is a shader cache, so I don't need to recompile shaders that already exist
19:07 soreau: I just checked, after starting the compositor, it's 218.0MB and after compiling the vert/frag shader program, it's 226.0MB so about 8MB?
19:08 soreau: subsequently, disabling the shader and recompiling it doesn't increase usage
19:10 bjorn3_gh: when does DRM_EVENT_FLIP_COMPLETE get sent? at the start of the scanout that will show the new framebuffer, at the start of the vblank after showing the framebuffer, or at the start of the next scanout when a new framebuffer may be shown?
19:10 bjorn3_gh: the kernel docs only say that it is sent "when the page-flip is done" without defining what it means for a page-flip to be done.
19:11 bjorn3_gh: s/new framebuffer/framebuffer passed to the page flip ioctl/ once
19:20 soreau: it would seem that DRM_EVENT_FLIP_COMPLETE is sent after vblank and the hw swaps buffer registers
19:22 bjorn3_gh: thanks soreau
19:25 Company: soreau, zamundaaa[m]: dusted off the patch and ran it through valgrind --tool=massif: running gtk-demo and closing it right away allocates 22MB via glslang::TPoolAllocator::allocate()
19:26 Company: which is 1/3 of what gtk-demo allocates, and more than anv_device_map_bo()
19:26 Company: so not as bad as the number I remembered
19:26 soreau: Company: is that a call from within glslang?
19:27 Company: its their allocator that seems to allocate most/all of the memory
19:28 soreau: well I just looked via top and init/fini glslang right away, so maybe I'm not seeing the full picture and the usage I did see was the shader running overhead
19:28 soreau: but still doesn't take that long
19:29 Company: or maybe I'm doing something stupid
19:29 Company: ah, with widget-factory it comes out at 60MB allocations
19:30 soreau: hm
19:30 Company: it seems to copy around a 6MB symbol table