ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
rasterman has joined #panfrost
rasterman has quit [Quit: Gettin' stinky!]
vstehle has quit [Ping timeout: 480 seconds]
tjcorley has quit [Ping timeout: 480 seconds]
tjcorley has joined #panfrost
<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?
<alyssa> No.
JulianGro has quit [Remote host closed the connection]
<cphealy> Is it not supported as it's just not a feature that has been gotten to or is there some technical impediment?
<alyssa> No hw support.
<cphealy> Hmm, is it possible the G52 DDK is faking support for geometry shaders? It does advertise support for GL_EXT_geometry_shader.
atler is now known as Guest1094
atler has joined #panfrost
Guest1094 has quit [Ping timeout: 480 seconds]
evx256 has quit [Remote host closed the connection]
camus1 has joined #panfrost
camus has quit [Read error: Connection reset by peer]
indy has quit [Server closed connection]
indy has joined #panfrost
go4godvin has quit [Server closed connection]
go4godvin has joined #panfrost
jkl has quit [Quit: Gone.]
jkl has joined #panfrost
vstehle has joined #panfrost
jekstrand has quit [Ping timeout: 480 seconds]
jekstrand has joined #panfrost
danct12_ has joined #panfrost
danct12_ has quit []
Daanct12 has joined #panfrost
<tomeu> cphealy: guess they are implemented on top of compute shaders or so?
Daanct12 has quit [Quit: Leaving]
lympa has joined #panfrost
lympa has quit []
Daanct12 has joined #panfrost
Daanct12 has quit []
Daanct12 has joined #panfrost
Daanct12 has quit [Remote host closed the connection]
erlehmann has quit [Remote host closed the connection]
Daanct12 has joined #panfrost
MajorBiscuit has joined #panfrost
pendingchaos has quit [Ping timeout: 480 seconds]
jekstrand has quit [Read error: Connection reset by peer]
jekstrand has joined #panfrost
jambalaya has quit [Server closed connection]
jambalaya has joined #panfrost
rasterman has joined #panfrost
erlehmann has joined #panfrost
Major_Biscuit has joined #panfrost
MajorBiscuit has quit [Read error: No route to host]
Major_Biscuit has quit []
MajorBiscuit has joined #panfrost
f11f12 has joined #panfrost
pendingchaos has joined #panfrost
Daanct12 has quit [Remote host closed the connection]
<daniels> yeah, geom + tess
JulianGro has joined #panfrost
camus has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
JulianGro has quit [Remote host closed the connection]
tlwoerner has quit [Ping timeout: 480 seconds]
tlwoerner has joined #panfrost
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #panfrost
tlwoerner_ has joined #panfrost
tlwoerner has quit [Ping timeout: 480 seconds]
<jekstrand> yeah,
<jekstrand> geom/tess are all "emulated" with compute shaders on most mobile hardware
<macc24> are they even used anywhere?
<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.
<jekstrand> idk
<jekstrand> gles 3.2 supports both
<HdkR> I doubt any mobile games use them :P
<alyssa> jekstrand: At least with Mali's architecture, any vertex pipeline (VS/GS/TS/mesh) will require roundtripping transformed gl_Position to main memory
<HdkR> dolphin-emu uses geometry shaders. Obviously it's a required feature
<alyssa> which negates any benefit of using VS/GS/TS/mesh shaders (as opposed to running in software)
<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.
<robmur01> is software emulation something that Mesa could do generically?
* robmur01 also stubbornly runs desktop GL things on Midgard...
<alyssa> robmur01: Depends what you mean by software emulation, I think
<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?
<alyssa> Yes, it could.
<alyssa> running the entire pipeline on the GPU with compute shaders?
<alyssa> I don't think so, there's enough hardware-specific magic needed to make that work well
<macc24> i just have the DUMBEST idea ever
<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 :)
<macc24> what if a gpu could be run in software on compute shader on gpu
<macc24> like hardware accelerated llvmpipe
<daniels> ‘accelerated’ …
<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
<HdkR> You don't want that
<HdkR> Some console emulators already do it. It's a bad idea.
<macc24> uh ok
<HdkR> The fixed hardware units are crucial for extracting a bunch of the perf you want
erlehmann has quit [Ping timeout: 480 seconds]
f11f12 has quit [Quit: Leaving]
Major_Biscuit has joined #panfrost
MajorBiscuit has quit [Ping timeout: 480 seconds]
<anholt> jekstrand: qcom and bcm aren't compute shaders for geom/tess.
<jekstrand> anholt: Interesting
<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?
<jekstrand> XFB with geom/tess really wants HW
<anholt> at a guess, they're screwed by patents.
<jekstrand> That's entirely possible
<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.
<jekstrand> :-/
<jekstrand> They like they're "we're both a tiler and immediate" stuff
<jekstrand> *their
erlehmann has joined #panfrost
<anholt> yeah, having magic tuning knobs critical for performance that your apps don't know the rules for is SO GREAT.
<jekstrand> hehe
<anholt> bcm is strictly tiler, though, and does the gs/tess as full stages.
<jekstrand> Also, why would you ever want to not bin unless you're a blit shader.
<anholt> all those fullscreen blit-ish shaders. apparently not writing to gmem then copying gmem to real mem actually matters.
<alyssa> mali has a trick for blitting without binning, sort og
<alyssa> *of
<jekstrand> Yeah, extra memory traffic does matter at least some. I guess some of it depends on your dispatch pattern.
<alyssa> anholt: maybe you'd know -- is there any way to do XFB with binning?
<jekstrand> If it's reasonably cache-friendly, running without the binning is probably fine.
<alyssa> I assume no because of interactions with culling
<anholt> alyssa: bcm and qc write out the XFB outputs during the binning shader, since that happens once on all the draws in order.
<alyssa> oh, I see.
<jekstrand> Yeah, that's probably the sensible thing to do
<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.
<alyssa> then the binning shader needs to do arbitrary varying outputs (potentially) (to feed back to the frag shader)
<alyssa> or the XFB writes need to be duplicated between the binning shader and the varying shader
<alyssa> (which might not be the end of the world.. but means higher memory traffic)
<anholt> alyssa: or just ignore what xfb computed and recompute during the rendering phase. that's what we do.
<alyssa> right.. I guess mareko's new store_output makes that feasible to lower entirely in NIR, too.
<alyssa> atm I just disable binning shaders if xfb is used
<alyssa> no idea how the hit from disabling binning shaders (IDVS) compares to the hit from duplicating XFB stores
<alyssa> I suspect it's content dependent
<alyssa> never got around to checking what Arm's driver does
<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.
<alyssa> Alas
<alyssa> Valhall actually has 3 modes for vertex shaders
<alyssa> "compute shaders, write varyings to memory you allocate"
<alyssa> "binning shaders and varying shaders separately, write varyings to memory you allocate"
<alyssa> "binning shaders and varying shaders separately, memory for varyings is dynamically allocated by the hardware"
<alyssa> (modes introduced with Utgard/Midgard, Bifrost, and Valhall respectively.)
camus1 has joined #panfrost
<anholt> oh? i thought dynamically allocating memory for binning output was older than that.
<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
<alyssa> Nope :(
<alyssa> Arm has a delicate series of hacks to allocate said memory in kernel space, but yeah..
<alyssa> anyway, given the breadth of hardware supported in panfrost, support for all three modes is maintained
<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
camus has quit [Ping timeout: 480 seconds]
<anholt> ah, the kernel hacks are what I was thinking of
<daniels> anholt: grow-on-GPU-pagefault BO flag
<alyssa> + JIT alloc, i think
Major_Biscuit has quit [Ping timeout: 480 seconds]
tlwoerner_ has quit []
tlwoerner has joined #panfrost
camus has joined #panfrost
camus1 has quit [Remote host closed the connection]
macc24 has quit [Ping timeout: 480 seconds]
macc24 has joined #panfrost
tjcorley has quit [Ping timeout: 480 seconds]
tjcorley has joined #panfrost
vstehle has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]