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
robink_ has joined #panfrost
<alyssa> setting this bit causes even the serial port to go dead
<alyssa> how I love undocumented vendor code
robink has quit [Ping timeout: 480 seconds]
<alyssa> wait what
<alyssa> did that just make it work
<alyssa> um. ok.
<urja> ?
<alyssa> this nonsense ^
<alyssa> Admittedly I don't think clk-mt8192.c is mainline yet so there's also that.
<alyssa> shrug
<alyssa> there's a new mali chromebook on the market,
<alyssa> I'll be damned if there aren't FOSS drivers for its GPU ;)
<alyssa> ("Does anything other than the GPU work on mainline?" "That's not my problem! ;-p")
<alyssa> Unfortunately, the gpu on this platform is.. broken
<HdkR> uh oh
<alyssa> running any gpu work panics the kernel, good work alyssa
camus has joined #panfrost
rasterman has quit [Quit: Gettin' stinky!]
<alyssa> panfrost_gpu_power_off doesn't write any cores, it just writes 0's
<alyssa> how can that work? :|
<alyssa> [ 164.479580] panfrost 13000000.gpu: gpu sched timeout, js=1, config=0x0, status=0x0, head=0x0, tail=0x0, sched_job=000000001207ac71
<alyssa> mumble mumble.
<alyssa> I can run jobs from inside kernel space, so why not from userspace?
hyrc_ has joined #panfrost
jolan has quit [Quit: leaving]
jolan has joined #panfrost
hyrc has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #panfrost
hexdump01 has quit [Ping timeout: 480 seconds]
atler is now known as Guest10682
atler has joined #panfrost
Guest10682 has quit [Ping timeout: 480 seconds]
remexre has quit [Remote host closed the connection]
remexre has joined #panfrost
rasterman has joined #panfrost
rasterman has quit [Quit: Gettin' stinky!]
nlhowell has joined #panfrost
<HdkR> Already ordered some
<HdkR> Here's hoping the kernel bits just work :)
<spawacz> woow rk3588 finally
<spawacz> is the gpu going to be supported by panfrost?
<HdkR> It's Valhall so it will take a while
rasterman has joined #panfrost
<HdkR> But at some point in the future, yes.
<spawacz> So for now it would require a propertiary firmware?
<HdkR> Proprietary software stack
<HdkR> New uarch always takes a bit of time to bring up since there isn't any public hardware documentation
<alyssa> HdkR: G610MC4
<alyssa> that's worse than 'just' Valhall, that's Valhall with CSF
<alyssa> I started poking at CSF for funsies but it's a whole new challenge beyond 'just' a new uarch
liberium has joined #panfrost
<HdkR> alyssa: Luckily I didn't say it was "just" Valhall :D
<HdkR> Will be a fun distraction once I receive it at least
<alyssa> Heh
<HdkR> A little late but with that board I can justify a vacation :P
<alyssa> hahaha
<alyssa> before Christmas, I started poking at the CSF firmware ... I should upload that code anywhere
<alyssa> s/anywhere/somewhere/
<alyssa> wanted to see if I could figure out the register-level interface of the actual hardware
<alyssa> (So we don't have to rely on a proprietary mystery blob when the time comes to support it in mainline)
<alyssa> (Un)fortunately I have an actual day job :-p
<HdkR> Fortunate
nlhowell is now known as Guest31
nlhowell has joined #panfrost
Guest31 has quit [Ping timeout: 480 seconds]
<alyssa> ...and Mali G57 just passed its first igt test
<alyssa> million thanks to mmind00.
<HdkR> \o/
<alyssa> Hmm so do I do the responsible thing or do I install Mesa onto the board and see if 3D works
<alyssa> I mean. Y'all have literally never known me to be responsible...
* alyssa installs VK-GL-CTS surfaceless
<alyssa> It's important that it's surfaceless because the display drivers don't work.
<alyssa> Test case 'dEQP-GLES31.functional.shaders.builtin_functions.common.abs.float_highp_compute'..
<alyssa> [ 330.094748] panfrost 13000000.gpu: js fault, js=1, status=DATA_INVALID_FAULT, head=0x6087140, tail=0x6087140
<alyssa> pandecode: dump command stream to file pandecode.dump.0000 Fail (Result comparison failed)
<alyssa> Boooring
<alyssa> But kinda cool that the work got queued at all..?
<alyssa> I guess debugging Mesa is next though I should really be doing, umm, not this right now.
liberium has quit [Ping timeout: 480 seconds]
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #panfrost
jernej has quit []
cphealy has quit [Quit: Leaving]
Elemental has joined #panfrost
<Elemental> It looks like my Duet is stable after setting the GPU min_freq and max_freq to the same value. I've tried 300 MHz and 800 MHz. I have since not seen any panfrost related kernel errors and no lockups as before. I'll create a bug report if there isn't one already.
<alyssa> Elemental: wait
<alyssa> isn't Duet MT8183?
<Elemental> Yes
<alyssa> Panfrost doesn't support frequencing scaling on that chip.
<alyssa> So the values of min/max_freq should have /no/ effect
<alyssa> WTF?
<alyssa> *frequency
<Elemental> After boot min_freq is 300000000 and max_freq is 800000000.
<alyssa> Grumble
<alyssa> [ 1.925772] panfrost 13000000.gpu: [drm:panfrost_devfreq_init] More than 1 supply is not supported yet
<alyssa> do you see something like this?
<alyssa> (`dmesg | grep panfrost`)
<Elemental> Was getting lockups and lots of panfrost errors prior to setting them to be the same. It is kernel 5.16.0-rc3-cadmium.
<Elemental> One sec, looking through stored logs.. dmesg no longer has any panfrost errors, since it has been a few days.
<Elemental> Not finding a message like that.
<alyssa> what.
<alyssa> ummmm
cphealy has joined #panfrost
<alyssa> macc24: Any patches I should know about? :-p
<Elemental> Here are some I'm seeing though that may be relevant: panfrost 13040000.gpu: clock rate = 511999970
<Elemental> [drm:panfrost_devfreq_init] Failed to register cooling device
<alyssa> This won't do what you want.
<alyssa> Please drop this patch.
<alyssa> Elemental: Please drop that patch.
<Elemental> There are a few panfrost feature log messages too, if you want those.
<alyssa> Chalking this up to a Cadmium bug.
<alyssa> Take this as a reminder to use mainline, please...
<Elemental> OK. Apologies. I'll make sure of that in the future.
<alyssa> I realize mainline isn't always possible and projects like Cadmium fill stopgap measures for ChromeOS silliness etc
<alyssa> but the closer you are to a pure upstream configuration (mainline, Debian/Fedora, ...) the better upstream can help you
<alyssa> As for the bug itself-- as you have discovered first hand, mainline does not support devfreq on MT8183 since it requires careful platform-specific code
<alyssa> [insert the usual MTK grumbling]
<Elemental> I'll keep that in mind, in regards to mainline. Only had this Duet for a week,so I'm still getting familiar with development. Thank you for your efforts!
<alyssa> Sure :)
<alyssa> none of what I said is Duet specific, fwiw
<alyssa> The "do I use downstream or not?" question has been plaguing Arm Chromebook users in particular for years ...
<alyssa> I guess the more nuanced answer then is, if you do choose to use a downstream (Cadmium, PrawnOS, etc), bug reports should be directed there first.
<alyssa> upstream bug reports should be possible to reproduce with unpatched upstream kernel + mesa
<Elemental> Sounds like a good policy ;-)
<alyssa> Oh, how.. delightful.
<alyssa> Valhall changed data structure alignment requirements since Midgard.
<HdkR> ooo
Elemental has quit [Quit: Page closed]
<alyssa> Passed: 8/19 (42.1%)
<alyssa> That's 8 more tests passing with mainline + Mesa + Mali-G57 than were passing this morning!
<alyssa> (Fragment jobs work.)
<HdkR> That's some good proggers right there.
Elemental has joined #panfrost
Elemental has quit []
jernej has joined #panfrost
marcodiego has joined #panfrost
<alyssa> ....pandecode should really use a red-black tree of mmap's
<alyssa> Mumble.
<alyssa> am I going to rewrite pandecode mmap handling again? yeah, probably.
* alyssa groan
<alyssa> Funny data structures in /my/ driver? Likelier than you think
<alyssa> ("rb-trees are incredibly basic, alyssa" "everything is funny if you have the right attitude :-p")
remexre has quit [Remote host closed the connection]
remexre has joined #panfrost
nlhowell has quit [Ping timeout: 480 seconds]
nlhowell has joined #panfrost
<alyssa> ok, now I have nice buffer dumps
<alyssa> and can see the VS is sending /every/ vertex in (87.0, 123.0, 0.5, 1.0)
<alyssa> so the triangle degenerates.
<alyssa> also the 123.0 is just slightly above the scissor box
<alyssa> something like stride=0, or gl_VertexID not getting preloaded
<alyssa> or all vertex data reading back zero and that's the viewport
<alyssa> Really there are lots of reasons this could be broken :-p
<alyssa> the output x is determined by
<alyssa> u1 + u0 * (attrib.x / attrib.w)
<alyssa> u0 = 64.0, u1 = 151.0
<alyssa> so for that to be 87.0 means that
<alyssa> attrib.x / attrib.w = -1.0
<marcodiego> I know it is not the best place to ask, but I know some people here have a lot of knowledge about rockchips soc's state... For some time it is already possible to run some rk3399 boards entirely blob-free. Will the same be possible with rk3566?
<alyssa> which one is that?
<alyssa> attrib[0].x = -1.0
<alyssa> attrib[0].w = +1.0
<alyssa> attrib[1].x = -0.5
<alyssa> attrib[w].w = +1.0
<alyssa> So the value for the first vertex is correct, but second (and all other) vertices are wrong
<alyssa> That narrows down the problem a bit
<alyssa> ah
<alyssa> blink-and-you-miss-it compiler bug
<alyssa> 3d 3e 01 32 08 80 66 08 LD_ATTR_IMM.v4.f32.slot0.wait0 @r0:r1:r2:r3, r61, r62, index:0x0, table:0x1
<alyssa> that should be (r60, r61) instead -- the ABI changed from Bifrost
<alyssa> Fail (Fail)
<alyssa> how dreadfully boring
<alyssa> Woo, now we're passing tests on Valhall in bulk :-)
<alyssa> ("Wasn't there something non-computer related you were going to do this weekend?" "Hmmm.... later...")
<alyssa> dEQP-GLES2.functional.shaders.operator.unary_operator.* passes in full
<alyssa> I must say, as hell as the Mediatek platform integration side of things is, the Arm side of things is very well behaved.
<alyssa> Passed: 400/400 (100.0%)
<alyssa> common_functions.* is a go
<alyssa> angle_and_trigonometry too
<alyssa> including all the goofy atan2 stuff which historically has found bugs in every compiler I've brought up
<alyssa> AFBC is raising an IMPRECISE_FAULT, guess we're disabling AFBC on Valhall until I can at least get to gles3 texture tests
<marcodiego> alyssa, where can I track Mali T-860 tests passing rate? Also, AFAIK it is vulkan capable, are there efforts to support vulkan on it?
<alyssa> we're hoping to support t860 in panvk, but that's low priority right now
<marcodiego> nice! Thanks!
<alyssa> for the moment, mali-g52 is the "flagship"
<marcodiego> rk3566, right?
<alyssa> no particular SoC
<alyssa> (mali-t860 had that honour before 2021)
<marcodiego> alyssa, any info if rk3566 will be able to run blob-free like rk3399?
<alyssa> TBD
<marcodiego> ok, Thanks!
<alyssa> It's blob-free on the GPU side
<alyssa> You'd have to ask #linux-rockchip about the non-GPU stuff
<marcodiego> oh, thanks! I'll do that!
<alyssa> on libera, not oftc
atler has quit [Quit: atler]
rasterman has quit [Quit: Gettin' stinky!]
floof58_ has joined #panfrost
floof58 has quit [Read error: Connection reset by peer]
floof58_ has quit [Read error: No route to host]
floof58 has joined #panfrost
floof58_ has joined #panfrost
floof58 has quit [Read error: No route to host]