01:27 <cphealy> I see with Mesa git trunk that GL_EXT_geometry_shader is not available with Panfrost for G52 while it is supported by Mali DDK. Is this expected? If so, what is preventing GL_EXT_geometry_shader from being supported with Panfrost on G52?

01:35 <alyssa> No.

01:48 <cphealy> Is it not supported as it's just not a feature that has been gotten to or is there some technical impediment?

01:50 <alyssa> No hw support.

01:52 <cphealy> Hmm, is it possible the G52 DDK is faking support for geometry shaders? It does advertise support for GL_EXT_geometry_shader.

06:30 <tomeu> cphealy: guess they are implemented on top of compute shaders or so?

12:48 <daniels> yeah, geom + tess

14:58 <jekstrand> yeah,

14:59 <jekstrand> geom/tess are all "emulated" with compute shaders on most mobile hardware

15:00 <macc24> are they even used anywhere?

15:00 <jekstrand> I'm not sure I actually believe them when they say there's something inherent with mobile/tilers that makes it that much harder than on desktop. But they've been able to hold back most of the apps so they can continue to ignore it for now.

15:00 <jekstrand> idk

15:00 <jekstrand> gles 3.2 supports both

15:01 <HdkR> I doubt any mobile games use them :P

15:02 <alyssa> jekstrand: At least with Mali's architecture, any vertex pipeline (VS/GS/TS/mesh) will require roundtripping transformed gl_Position to main memory

15:02 <HdkR> dolphin-emu uses geometry shaders. Obviously it's a required feature

15:02 <alyssa> which negates any benefit of using VS/GS/TS/mesh shaders (as opposed to running in software)

15:03 <alyssa> The inherent slowness dwarfs the overhead from lack of hardware support, so Arm has repeatedly made the call not to waste die space on the hardware when it won't move the fps needle.

15:41 <robmur01> is software emulation something that Mesa could do generically?

15:43 <alyssa> robmur01: Depends what you mean by software emulation, I think

15:44 <alyssa> running the entire vertex (VS+GS+TS) pipeline on the CPU with llvmpipe and then feeding the results into the GPU for fragment processing?

15:44 <alyssa> Yes, it could.

15:44 <alyssa> running the entire pipeline on the GPU with compute shaders?

15:44 <alyssa> I don't think so, there's enough hardware-specific magic needed to make that work well

15:50 <macc24> i just have the DUMBEST idea ever

15:50 <robmur01> yeah, I guess either approach would count - even to my lack of knowledge, lowering an entire shader program into other shader programs does sound a little far-fetched :)

15:50 <macc24> what if a gpu could be run in software on compute shader on gpu

15:50 <macc24> like hardware accelerated llvmpipe

15:57 <daniels> ‘accelerated’ …

15:59 <macc24> daniels: yea so like fragment and vertex shaders get compiled to compute shaders and the compute shader is compiled into binary code that runs on gpu

16:01 <HdkR> You don't want that

16:02 <HdkR> Some console emulators already do it. It's a bad idea.

16:02 <macc24> uh ok

16:04 <HdkR> The fixed hardware units are crucial for extracting a bunch of the perf you want

16:58 <anholt> jekstrand: qcom and bcm aren't compute shaders for geom/tess.

17:00 <jekstrand> anholt: Interesting

17:01 <jekstrand> anholt: So has ARM just not figured out how to make them not suck or does the HW only make it suck a little bit less?

17:01 <jekstrand> XFB with geom/tess really wants HW

17:01 <anholt> at a guess, they're screwed by patents.

17:02 <jekstrand> That's entirely possible

17:04 <anholt> though, qc doesn't do binning for gs/tess currently, so even though I think their method could easily do binned rendering for gs/tess, we don't.

17:04 <jekstrand> :-/

17:05 <jekstrand> They like they're "we're both a tiler and immediate" stuff

17:05 <jekstrand> *their

17:05 <anholt> yeah, having magic tuning knobs critical for performance that your apps don't know the rules for is SO GREAT.

17:06 <jekstrand> hehe

17:06 <anholt> bcm is strictly tiler, though, and does the gs/tess as full stages.

17:06 <jekstrand> Also, why would you ever want to not bin unless you're a blit shader.

17:08 <anholt> all those fullscreen blit-ish shaders. apparently not writing to gmem then copying gmem to real mem actually matters.

17:09 <alyssa> mali has a trick for blitting without binning, sort og

17:09 <alyssa> *of

17:09 <jekstrand> Yeah, extra memory traffic does matter at least some. I guess some of it depends on your dispatch pattern.

17:09 <alyssa> anholt: maybe you'd know -- is there any way to do XFB with binning?

17:09 <jekstrand> If it's reasonably cache-friendly, running without the binning is probably fine.

17:10 <alyssa> I assume no because of interactions with culling

17:10 <anholt> alyssa: bcm and qc write out the XFB outputs during the binning shader, since that happens once on all the draws in order.

17:10 <alyssa> oh, I see.

17:11 <jekstrand> Yeah, that's probably the sensible thing to do

17:11 <anholt> qc additionally has a mode that is tiled but not binned (because you ran out of memory for your compressed binning visibility stream, whoops, better go reallocate that), and in that case we should be turning on xfb during the first tile but not the following tiles (since all draws are in order per tile in that case). we don't do that, whoops.

17:11 <alyssa> then the binning shader needs to do arbitrary varying outputs (potentially) (to feed back to the frag shader)

17:11 <alyssa> or the XFB writes need to be duplicated between the binning shader and the varying shader

17:11 <alyssa> (which might not be the end of the world.. but means higher memory traffic)

17:12 <anholt> alyssa: or just ignore what xfb computed and recompute during the rendering phase. that's what we do.

17:12 <alyssa> right.. I guess mareko's new store_output makes that feasible to lower entirely in NIR, too.

17:13 <alyssa> atm I just disable binning shaders if xfb is used

17:13 <alyssa> no idea how the hit from disabling binning shaders (IDVS) compares to the hit from duplicating XFB stores

17:14 <alyssa> I suspect it's content dependent

17:14 <alyssa> never got around to checking what Arm's driver does

17:15 <anholt> I would say that "I suspect nobody's running xfb on our hardware anyway", except that nowadays everyone's running wine under emulators on us.

17:15 <alyssa> Alas

17:15 <alyssa> Valhall actually has 3 modes for vertex shaders

17:15 <alyssa> "compute shaders, write varyings to memory you allocate"

17:16 <alyssa> "binning shaders and varying shaders separately, write varyings to memory you allocate"

17:16 <alyssa> "binning shaders and varying shaders separately, memory for varyings is dynamically allocated by the hardware"

17:16 <alyssa> (modes introduced with Utgard/Midgard, Bifrost, and Valhall respectively.)

17:17 <anholt> oh? i thought dynamically allocating memory for binning output was older than that.

17:17 <alyssa> I am not convinced there is any situation where you'd want to use the second mode (bifrost-style), other than for b/w compat when bringing up the DDK on Valhall

17:17 <alyssa> Nope :(

17:18 <alyssa> Arm has a delicate series of hacks to allocate said memory in kernel space, but yeah..

17:20 <alyssa> anyway, given the breadth of hardware supported in panfrost, support for all three modes is maintained

17:20 <alyssa> so the path of least resistance for XFB is to reuse the implementation from midgard and support the few extra instructions / data structures used for that legacy mode

17:22 <anholt> ah, the kernel hacks are what I was thinking of

17:22 <daniels> anholt: grow-on-GPU-pagefault BO flag

17:23 <alyssa> + JIT alloc, i think