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
<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
<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?