12:37 <dliviu> bbrezillon: what's the best strategy for pushing my patch? wait until drm-misc catches up with v6.12-rc1 or push it into drm-misc-next-fixes?

13:41 <stepri01> dliviu: It should end up in drm-misc-fixes, but neither branch has the problematic commit yet and I believe it will be a compile error until that lands.

13:41 <stepri01> So either it needs to find a faster route to Linus or wait for -rc1 (and the back-merge to drm-misc-fixes).

13:42 <dliviu> yeah, I know, but apparently drm-misc-next-fixes can be used in such strange situations

13:43 <stepri01> it would still need a back-merge first. Ask the DRM maintainers I guess

13:46 <paperManu> hello! I'm doing some computer graphics development, maintaining a videomapping software in particular, and I wanted a confirmation that the Panfrost driver does not support geometry shaders? Is it meant to be added at some point?

14:00 <CounterPillow> It does not support GS because the hardware doesn't support it

14:00 <CounterPillow> It could be added by emulating it through compute shaders etc. eventually, but ideally you don't use geometry shaders even on hardware that supports it

14:01 <CounterPillow> GS are a bad idea for performance everywhere regardless of hardware support for them.

14:10 <CounterPillow> I don't know what your software does but chances are whatever you think of doing with GS is better solved with just better use of VBO+VAO+VS (e.g. instead of generating a bunch of geometry from a point primitive in a GS, have the geometry already generated and modify it in a vertex shader based on vertex attribs and such)

14:11 <paperManu> ah, I wondered whether it was supproted by the hardware. Thanks for the clarification.

14:12 <paperManu> and yes I know about the issues with geometry shaders. They are used to generate some geometry once, returned through transform feedback, and then used through another rendering pipeline during runtime

14:13 <paperManu> I know that at some point I should convert some of this to compute shaders

14:50 <bbrezillon> dliviu: check with the drm-misc maintainers

14:51 <bbrezillon> I tend to wait the -rc1 and ask for a backmerge in drm-misc-fixes

14:52 <bbrezillon> but if you want the fix in before -rc1 is released, you'll probably have to apply to drm-misc-next-fixes

15:51 <dliviu> I've been slapped over the wrist twice for committing to drm-misc-next-fixes, at least now I have a good reason</joking>

16:15 <alyssa> paperManu: yeah, compute shaders are the preferred approach for that

16:15 <alyssa> and a hypothetical driver impl would turn the GS+XFB into compute

16:15 <alyssa> (asahi does this)

16:16 <alyssa> and that compute shader would be surely slower than what you'd've written yourself

16:17 <paperManu> well, that would depend on how well I do it ;) Anyway, getting rid of geometry shaders has been on my todo list for some time, this might just be the good reason I needed to do it

16:18 <paperManu> thanks for your answers!