16:20 <q4a> cphealy: as far as I know, it's supported. Looks like it autogenerate bi_builder.h with bi_fma* functions from https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/panfrost/compiler/bi_builder.h.py

16:20 <q4a> Also you can see tests that uses some bi_fma funct-s in tests: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/panfrost/compiler/valhall/test/test-validate-fau.cpp

16:36 <cphealy> q4a: The reason I'm asking about this is Panfrost currently advertises support for GLSL 3.10 and from what I'm reading FMA is only available starting with GLSL 3.20. https://registry.khronos.org/OpenGL-Refpages/es3/html/fma.xhtml

16:37 <cphealy> Maybe the next question then is is there anything preventing Panfrost from advertising GLSL 3.20 even though the GLES level is 3.1?

16:43 <q4a> I know that biggest problem is geometry shaders https://registry.khronos.org/OpenGL/extensions/ARB/ARB_geometry_shader4.txt

16:44 <q4a> mali gpus don't have hw support for it.

16:45 <HdkR> Nobody likes GS

16:48 <cphealy> Yea, geometry shader support is needed for GLES 3.2. I'm wondering though if GLSL can be bumped to 3.20 without GLES going to 3.2? The idea is I don't need geometry shader support, but I want to be able to have shader source that use FMA.

16:52 <q4a> I was wonder is it posibble to use/add software support for geometry shaders (like in llvmpipe/softpipe), but I still think, that much easier just add " MESA_GL_VERSION_OVERRIDE=4.1 MESA_GLSL_VERSION_OVERRIDE=410"

16:53 <alyssa> the problem is that there are real apps (e.g. blender) that use GS

16:55 <cphealy> Would the real apps have a problem though if GLSL version was 3.20 while GLES version is 3.1? This would indicate to the apps that geometry shaders are not supported, right?

16:56 <q4a> oh.. I don't know apps, that uses GS. Good to know about blender)

17:02 <HdkR> I'm surprised there's no pre-existing art in mesa for GS in compute-like environments still. RDNA2 mesh stage should be similar no? :P

17:02 <q4a> ok. I tried to run blrmder. Clean env: A graphics card and driver with support for OpenGL 3.3 or higher is required.

17:03 <q4a> MESA_GL_VERSION_OVERRIDE=3.3 MESA_GLSL_VERSION_OVERRIDE=330 blender: Error: maximum output vertices (2) exceeds GL_MAX_GEOMETRY_OUTPUT_VERTICES

17:03 <q4a> No big difference now)

17:10 <alyssa> HdkR: NGG is a lot more capable than bare compute

17:10 <alyssa> and tilers have extra snafu

17:12 <HdkR> alyssa: :<

17:12 <HdkR> Dang NGG being too good

17:15 <alyssa> bbrezillon: when you get bored with kernel space, please review !20837

17:15 <alyssa> thanks :-)

17:17 <HdkR> I'm still very sad that the ARM Mali GPU optimization manual stopped being so aggressive towards GS

17:17 <alyssa> oh, did they?

17:17 <HdkR> It still says "don't use this", but with less aggressive repeating

17:19 <alyssa> Awww

17:19 <alyssa> * Don't use geometry shaders with transform feedback

17:19 <alyssa> * Don't use geometry shaders with tessellation

17:19 <alyssa> * Don't use geometry shaders with geometry shader instancing

17:19 <alyssa> * Don't use geometry shaders

17:19 <alyssa> * Just, don't do it

17:20 <HdkR> :D

17:21 <HdkR> I'm surprised that more GPUs haven't taken the NGG path really. Just take all these terrible VS-style stages, merge them in to one or two compute-like stages and move on.

17:21 <alyssa> yeah...

17:22 <HdkR> I guess to be efficient you need a lot of on-die memory and that is expensive

17:22 <alyssa> in fairness if I were building a tiler I'm not sure I'd do things differently

17:22 <alyssa> you kinda have to roundtrip through memory anyway, so why not use compute for it? or something

17:22 <alyssa> the really nasty part is dynamic memory allocation

17:23 <alyssa> Mali and AGX both have solution sfor this and they both suck

17:25 <HdkR> Such a shame