@benny @linuzifer
dann sollte er vielleicht ne therapie machen statt seine anhänger sich gegenseitig bekriegen lassen

@lritter @steve
salty? sounds weird

I'll have to try it anyway =)

@lritter @steve
Störtebeker Frei-Bier is also good.
Schneider Weisse Alkoholfrei is ok for alcohol-free wheat beer, but has that sweetness that alcohol-free beer often has (but to a tolerable degree IMO, and it seems that especially alc-free wheat beer always has that)

@raven667 @anniethebruce @foosel
Flatpak adds another layer of volunteers you rely on for applying security fixes

@dotstdy @floooh @pythno @sol_hsa
Depends on what you want to do - for modern graphics it sure is, but for that you most likely wouldn't use SDLs abstraction anyway.
For a bit of 3D rendering (ports of old games, model viewers, data visualization, ...) it would've been enough, probably.

I mean, SDL2 had that 2D rendering API that did HW accelerated 2D rendering, and was very limited (no shaders, for starters), but still was used by some projects

@dotstdy @floooh @pythno @sol_hsa
yeah, maybe it was a bit optimistic - though I think the plan was not to expose all modern features, maybe even only vertex- and pixelshaders at least as a start, so maybe it wasn't completely ridiculous? IDK, not familiar enough with the low-level details

@floooh @dotstdy @pythno @sol_hsa
The glslang README says (under dependencies):
> Python 3.x: for executing SPIRV-Tools scripts. (Optional if not using SPIRV-Tools and the 'External' subdirectory does not exist.)

sounds like it's optional? but unclear what features are disabled then

@floooh @dotstdy @pythno @sol_hsa
oh, nice -_-

Initially the plan for SDL3's 3D API included a custom bytecode that abstracts spir-v and whatever metal and D3D use, and a compiler from a custom shading language to that bytecode, so SDL3 would include everything needed for runtime shader editing - I was looking forward to that.

But then somehow they were in a hurry to release SDL3 and integrated a different existing solution for API abstraction that uses backend-specific bytecode, IIRC :-/

@floooh @dotstdy @pythno @sol_hsa
Do you need SPIRVTools to compile GLSL to SPIR-V, or are they only used for tests or other optional things?

@raven667 @anniethebruce @foosel
yes, you shouldn't try to roll your own crypto ;)

I just dislike that trend of depending on (literally) thousands of micro-libs (many of them as indirect dependency), would be nicer to have a handful of bigger more generic ones so it's feasible to keep informed regarding security fixes and if updates break things etc.

@pythno so OpenGL through zink + moltenvk works ok?

@pythno BTW: If care about macOS, their OpenGL implementation doesn't support spir-v.
Though zink + moltenvk probably does

@dotstdy @pythno @sol_hsa
ok, then I misremember, sorry :)
*Maybe* that was in a context of a GPU API abstraction (like SDLs 3D API or bgfx) that might also use d3d or even metal, not sure anymore.

I don't care much what my opengl driver links, I don't have to ship that with applications

@dotstdy @pythno @sol_hsa
or are there glsl or hlsl to spirv compilers that don't use llvm or are otherwise massively bloated? when I looked this up a while ago it seemed like there was always llvm or (even worse) standalone tools involved

@dotstdy @pythno @sol_hsa
*text* shaders

@dotstdy @pythno @sol_hsa
I find it very useful that OpenGL lets me compile text shaders at runtime without me having to link at least one copy of LLVM ;)

@dotstdy @pythno @sol_hsa
ha, just stumbled upon the same thing and was gonna post it =)
It's not even using callbacks with a filename but lets you upload strings with names that are then used for the includes - meaning you need to load all the shader source files first? Indeed not very compelling

@epiceneVivant @sidereal @Tattie
yeah, though I agree that just making faces is probably usually accepted

@pythno @sol_hsa
What should it be a feature of anyway? OpenGL? Vulkan?
That Google extension isn't even a real extension that's documented in the official places, but a hack supported by the shaderc tool. And of course for a tool that operates on files anyway it makes sense.

But as part of standard OpenGL/GLSL?
It *could* be made to work, but would at least require you to set a callback (that takes the filename as argument and returns a string) which might be a bit awkward for a std feature?

@dramypsyd @hyperreal
by that logic your husbands role is not the victim 😬