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
<icecream95>
Of course Gallium Nine support got broken in the N months since I last tried it
<icecream95>
I guess I'd better get started on bisecting through 9000 commits...
Guest834 has quit [Ping timeout: 480 seconds]
<macc24>
alyssa: i like your funny words
davidlt has joined #panfrost
<icecream95>
alyssa: Can I get a point for breaking the driver?
<icecream95>
"panfrost: Only upload UBOs when needed" *doesn't* set NULL UBOs when a UBO doesn't need to be uploaded, it instead tells the hardware that there is a 64kb UBO starting at address 0...
<icecream95>
But... then wouldn't the existing code for not uploading empty UBOs be broken as well? So why is the hardware complaining?
<icecream95>
("Fault Pointer" is set to the address of the uniform buffers array)
<alyssa>
10 points to ~~Gryffindor~~ icecream95
<alyssa>
*!
<alyssa>
**1
<icecream95>
Maybe it's not the uniform buffers that are at fault, but whatever is before it. I'll try adding some padding to pool allocations...
<icecream95>
Okay, so it seems the *actual* problem is with teh samplers
vstehle has quit [Ping timeout: 480 seconds]
vstehle has joined #panfrost
<tomeu>
alyssa: wow, your valhall driver already renders text beautifully!
<macc24>
yes it just needs LIBGL_ALWAYS_SOFTWARE=1 to work \o/
<tomeu>
hehe
<icecream95>
Today's stupid idea: Compiling Mesa to WASM, then using WebSockets to stream BO contents to a server to be submitted to the GPU
* robmur01
realises he may be missing something important from yesterday's tinkering and needs to investigate opp_table->enabled...
davidlt has joined #panfrost
warpme_ has quit [Quit: Connection closed for inactivity]
<robmur01>
urgh, I think there's actually a hole in the OPP API here :(
<macc24>
robmur01: well
<macc24>
for some reason linux just disables this regulator after booting
<macc24>
causing havoc with anything 3d
<robmur01>
Yeah, I figured that, but AFAICS it should get reenabled once panfrost binds - that's the curious thing
<macc24>
it is disabled long after panfrost binds
<macc24>
i can even run kmscube and see in real time it crash because linux turned off that reg
<macc24>
if i'm fast enough
<robmur01>
so the regulator_get/regulator_enable isn't happening from anywhere?
<macc24>
uh i don't know
<robmur01>
does $DEBUGFS/regulator/regulator_summary show any users?
<robmur01>
anyway, forget my patch from yesterday, it's wrong
<macc24>
yea there is something
<macc24>
hmm there is 0mV next to '13040000.gpu_sram'
<macc24>
it's a miracle that it works
<robmur01>
I've updated the branch (with a WIP commit that intentionally doesn't compile) but gonna have to shelve it for now
<macc24>
ugh so getting it running with the mainline kernel properly is my job, isn't it?
<robmur01>
if enable_count > 0 I think that might just mean nobody's requested a specific voltage, just that it's turned on at whatever
<robmur01>
I figure at this point I'd need to talk to Viresh about how the ->set_opp flow is expected to deal with this and possibly make more fundamental changes to the OPP core - happy to pick it up again at some point in future, but I don't have the time to get into that now
<alyssa>
tomeu: Pffff
<macc24>
o/ alyssa
wwilly has quit []
camus1 has joined #panfrost
camus has quit [Remote host closed the connection]
camus has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
davidlt has quit [Ping timeout: 480 seconds]
<macc24>
holy shit
<macc24>
re3 runs a bit better
<macc24>
almost playable
<alyssa>
macc24: :)
<alyssa>
g31 or g72?
<macc24>
g31
<alyssa>
cute
<macc24>
with a 640x854 screen
<macc24>
or 854x480 i don't remember
<macc24>
still far away from 60fps
<macc24>
alyssa: i'm fairly certain that g72 would just bruteforce through re3
<macc24>
i assure you, this wasn't posted on fex discord server
<alyssa>
HdkR: Please confirm this 😉
<HdkR>
It's not there
<macc24>
how many times is g31 slower than g72?
<macc24>
turns out i can drop the draw distance A LOT in config file
<macc24>
and now it's playable \o/
<macc24>
even on g31
<macc24>
alyssa: the perf debug option seems to be missing something... or g31 is /that/ slow
<anholt>
tile restores?
<macc24>
anholt: i have literally no idea what this means
<anholt>
on a tiler, usually there's a fast path for clearing color/depth at the start of rendering, and if the app doesn't then you have to do an expensive load from memory into your tile at the start. various driver issues can cause those to happen more than they should.
<anholt>
I don't think I perf_debug warned on those on broadcom or freedreno, but honestly we probably should.
<macc24>
okay, how would i check for that?
<anholt>
(it means glamor would do a lot of perf warnings, but it's not exactly wrong about X rendering on a tiler either)
warpme_ has joined #panfrost
<alyssa>
anholt: Same issue applies to mali. I have perf_debug for all the flushes except for gallium->flush(), not sure that's enough by itself though.
<alyssa>
If you write the freedreno patch I'd gladly translate back to panfrost
<anholt>
that seems like it should cover the cases I'm thinking about at least
<alyssa>
cool 👍
camus1 has joined #panfrost
camus has quit [Ping timeout: 480 seconds]
davidlt has joined #panfrost
davidlt has quit [Ping timeout: 480 seconds]
camus has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
warpme_ has quit [Quit: Connection closed for inactivity]
camus has quit [Remote host closed the connection]