01:30 jenatali: Sounds familiar as the only other producer of DXIL besides DXC
02:36 Company: Lynne: so, if you were to write a rendering library today that was meant to target as many backends as possible, what shader language would you go for?
02:37 Company: I'm wondering about the best approach for GTK, before we actually start using shaders for much more than gl_FragColor = texture(tex, uv);
02:38 Company: and that's gonna happen this year most likely, with the HDR stuff and path rendering
07:09 HdkR: Did 23.2 actually release? Wasn't paying attention and thought it was at the start of the month
07:09 psykose: nope
07:11 HdkR: I see
09:47 Lynne: Company: glsl is here to stay and be extended
09:48 Lynne: glslang may be horrible, but who knows, maybe in the future someone will write a simple compiler that doesn't depend on glslang
09:49 Lynne: it's simpler than C, and you can write a simple C compiler in a thousand (very long) lines
09:50 Lynne: it doesn't even need to do any simplifications, optimizations, or register management
09:53 Company: Lynne: but how do I get DirectX or Metal supported with it?
10:06 Lynne: ah, I didn't know that was a requirement
10:10 Lynne: if the shaders are comparitively simple, I think you can get away without any extra deps by templating the common parts
10:11 Lynne: a = b + c; is valid in all 3 languages after all
14:21 Company: Lynne: otoh HLSL is a nice language, too - and there are decent HLSL=>GLSL compilers, plus I can get SPIRV out of it
14:21 Company: which gives me Vulkan, GL and DirectX at least
14:22 Company: and then there's the gaming community which uses HLSL and has quite some open source tools available - though I didn't investigate them other than reading READMEs
14:51 alyssa:wonders why v3dv drm-shim isnt working
15:21 Lynne: Company: sure, and libdxcompiler is a nicer library than glslang, I'm just of the opinion that if something isn't optimal, you make it optimal
15:22 Lynne: you don't get certain features in hlsl that you get in vulkanese glsl, like addresses, coop matrices and such, but to a gui toolkit, those are probably not of any interest
15:24 Company: I don't know - we're getting very close to state of the art with GTK4's rendering pipeline, because lots of other toolkits I used to take inspiration from are still stuck on the CPU
15:26 Company: and if we can invent a way to do layout and or styling on the GPU (which we want to do because it's slow and at least in theory it's parallelizable) then we're suddenly writing pretty complex code
15:27 Company: but how much of that is overlapping with ML stuff or audio/video I have no idea
15:28 Company: the immediate concern is about the best way to do (reasonably old) GL, Vulkan, DX and Metal
15:30 Company: and neither GLSL nor HLSL nor SPIRV can do that and what people use is either a game engine's platform or some WebGL implementation like ANGLE
16:03 zmike: sounds like you want workgraphs
16:23 Company: "Announcing GPU Work Graphs in Vulkan®" - July 28, 2023
16:23 Company: that sounds very much like I can't look at many toolkits for inspiration
16:24 Company: but it's good to know that whatever DirectX comes up with has a Vulkan extension about a week later
18:15 Lynne: I wish instead of pipelines they could've gone with shader objects
18:16 Lynne: for shader_enqueue
18:31 airlied: yeah they dropped opencl because of so many low quality implmentations
18:31 airlied: maybe if i make some low quality cuda they might drop it
18:32 glehmann: Lynne: shader objects vs pipelines makes no difference for compute shaders
18:32 HdkR: airlied: Isn't that already HIP?
18:34 airlied: indeed
18:34 airlied: DavidHeidelberg[m]: did llama not work for you on tinygrad?
19:02 DavidHeidelberg[m]: airlied: haven't tried yet, so far just tested benchmark_train_efficientnet.py https://github.com/tinygrad/tinygrad/pull/1534
19:04 airlied: oh i just removed the array there i think
19:08 airlied: ah yes what the mr does
19:34 Lynne: glehmann: yup, my point, there's no need for an extra indirection
19:35 Lynne: requiring users to create individual pipelines
19:36 DavidHeidelberg[m]: airlied: feel free to drop `Tested-by` :D
19:40 airlied: DavidHeidelberg[m]: did you results from that benchmark?
19:42 DavidHeidelberg[m]: on my Intel XPS 9310: ;11.45 ms cpy, 6921.94 ms run, 94.26 ms build, 6827.63 ms realize, 0.04 ms CL, -0.00 loss, 421 tensors, 0.04 GB used, 0.00 GFLOPS;
19:42 DavidHeidelberg[m]: didn't ran on XT6800 yet
21:21 karolherbst: airlied: any prototype on that function calling stuff for llvmpipe? once I've done wiht global prog vars there isn't much needed for general HIP/SyCL besides SVM (pain) and subgroups (should probably merge it)
21:41 airlied: karolherbst: oh the branch I have it in is a bit of a hackfest branch, I might clean it up and pull just the fn work out
21:41 airlied: the hacky one is my llvmpipe-cl-funcs branch
22:24 JoshuaAshton: Lynne: Shader objects or pipelines there is no extra indirection here.
22:25 JoshuaAshton: Shader objects != shader modules
22:25 JoshuaAshton: You have to make a shader object or a pipeline
22:25 JoshuaAshton: eso is a meme anyway
23:20 Lynne: was it like that? been a while since I looked at it, I thought you needed to wrap shader objects in pipelines to use them
23:20 Lynne: anyway, the enqueue api is pipeline-based