<hanetzer>
Lyude: so, thoughts on the kbase build failure?
<alyssa>
...Where does that even come from
<hanetzer>
where does what come from?
<HdkR>
have I mentioned recently how mich I love vim? I just enabled a few additional quality of life things in the YouCompleteMe plugin and it is so good
<HdkR>
What if someone a negative for w? Not even sure if it is valid :P
<alyssa>
HdkR: Not sure. I saw it in blob shaders and it shouldn't cost anything, so..
<alyssa>
(Actually, they were doing a csel thing.. for some reason)
<HdkR>
hm
<HdkR>
Good enough, w/e :P
<alyssa>
:p
<alyssa>
+1
<alyssa>
I wonder how indirect uniform loads work
_whitelogger has joined #panfrost
<alyssa>
Okay, indirect uniform loads don't seem too terrible
<alyssa>
For a simple, like,
<alyssa>
uniform ubuf[16];
<alyssa>
ubuf[idx]
<alyssa>
The index gets moved into r27.w
<alyssa>
And then it does
<alyssa>
ld_uniform_32 r0, 0, 0x8700
<alyssa>
FWIW, normal reads from UBOs use ld_uniform_32 with unknown set to 0x1E00
memeka has left #panfrost [#panfrost]
<alyssa>
...Here's a much weirder case, like, some new ld/st ops and way too many ld_uniform instructions
<alyssa>
But in this case, the index is apparently moved into r26.y, with unknwon set to 0x8100
<alyssa>
From this, we can hypothesize the meaning of 3 of those bites
<alyssa>
0x7: r27.w
<alyssa>
0x1: r26.w
<alyssa>
Er
<alyssa>
*.y
<alyssa>
First of all, notice just the lower 2 bits
<alyssa>
0x3: w
<alyssa>
0x1: y
<alyssa>
That's a component index
<alyssa>
And then look at the top bit
<alyssa>
1: r27
<alyssa>
0: r26
<alyssa>
That's the register select (a similar construct is used in store_vary and texture ops, to choose between a register pair like that)
<alyssa>
Okay, total weird tangent:
<alyssa>
This _fragment_ shader ends with:
<alyssa>
- Moving the fragment output into r27
<alyssa>
- "ldst_op_D0 r1, 0, 0x27E"
<alyssa>
D0 is right in the neighborhood of store_vary (0xD4/D5 depending on size), so it's clearly a store; the r1 is clearly the register select thing going on (by analogy to store_Vary), 0 is probably just dummy since what other fragment output would you have, and... 0x27E is... hm
<alyssa>
store_vary is 0x1E9E
<alyssa>
Plenty of bits in common
<alyssa>
I don't know why they would have two ways to do FS shader out, but hypothesising that's what this is, it's pretty easy to test that hypothesis modifying the compiler
<alyssa>
(Arguably this would be easier to do with the assembler but w/e)
<alyssa>
Yeah, no, okay so what gives
<alyssa>
Flooded with faults about writing to unmapped memory at various addresses
<alyssa>
There's a.... second... shader?
<alyssa>
One with an actual (normal) fragment epilogue and nothing else, sourcing from r23 (a uniform)?
<alyssa>
Am I seeing things?
<alyssa>
...Multiple SET_VALUE jobs too?
<alyssa>
tiler meta is all different
<alyssa>
width/height is set to 128x128 somehow
<alyssa>
Actully the whole fbd is off in various ways
jolan has joined #panfrost
Marex has joined #panfrost
<tomeu>
alyssa: actually, I don't see any regressions after rebasing and rebuilding
<tomeu>
maybe I didn't have the kbase module loaded at the time
<tomeu>
was quite tired by then
<tomeu>
the crate scene in glmark looks much better now, congrats :)
<hanetzer>
is 'libEGL warning: DRI2: Failed to authenticate' a normal warning?
pH5 has quit [Quit: bye]
_whitelogger has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
mmind00 has joined #panfrost
<hanetzer>
ah, it never probed because it can't find the mali regulator... you guys do any patching to dts or what?
<tomeu>
hanetzer: the DT in mainline for the rk3399 should work just fine with the kbase in gitlab
<tomeu>
for meson, you need some special configuration of kbase
<tomeu>
hanetzer: what hw are you on?
<hanetzer>
kevin
BenG83 has quit [Quit: Leaving]
<tomeu>
hanetzer: hmm, and which kbase are you using?
<tomeu>
and, which kernel?
<hanetzer>
kbase from panfrost's gitlab, kernel is sys-kernel/gentoo-sources-4.20.1
pH5 has joined #panfrost
<cwabbott>
alyssa: what program is that?
<hanetzer>
tomeu: ^
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<tomeu>
hanetzer: maybe the kevin doesn't have the mali-supply property yet
<tomeu>
hrm, seems to have had it since 2017-07-17
<tomeu>
mali-supply = <&ppvar_gpu>;
<hanetzer>
yeah, I see that. but for whatever reason, it fails and I get the 'Failed to get regulator' message and end up without /dev/mali0
<tomeu>
hanetzer: guess we could debug it, but even in that case it could be better to run a more recent mainline
<hanetzer>
as in, some -rc or another?
<hanetzer>
or 4.20.2 ?
<tomeu>
hanetzer: 5.0-rc2 or so
<hanetzer>
beh... sure, I can give it a go. however, booting various kernels on this device is not yet in a situation where its easy :P
<hanetzer>
I don't have a working u-boot cooked for it, and petitboot seems to be regressed in kexec land for aarch64
<hanetzer>
I'll give 4.20.2 a go first, since its packaged for gentoo.
belgin has joined #panfrost
<tomeu>
hanetzer: guess you can check in sysfs if that regulator looks sane
<tomeu>
or well, guess that would be debugfs
<hanetzer>
hmm. what path would that be?
<tomeu>
hanetzer: maybe /sys/class/regulator ?
<tomeu>
dont' have an ARM board booted up to check
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
belgin has quit [Quit: Leaving]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
afaerber has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
raster has joined #panfrost
raster has quit [Ping timeout: 272 seconds]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
raster has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
robertfoss_ has quit [Quit: WeeChat 1.8-dev]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
ezequiel1 is now known as ezequielg
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
tlwoerner has quit [Quit: Leaving]
rhyskidd has joined #panfrost
raster has quit [Remote host closed the connection]
<raster>
oh hahah! thanking me for that! you did the work! :)
rhyskidd has quit [Quit: rhyskidd]
<alyssa>
raster: Still appreciated the pointer where to look! :)
rhyskidd has joined #panfrost
chewitt has joined #panfrost
<raster>
alyssa: no problems. any time. :) i'll try to help tho atm i'm not allowed to share any code
* alyssa
nods
<raster>
but i noted you have enough things still broken in glmark so you have a lot to get right there
<raster>
like i saw it OOMing
<raster>
this is with your mem management rework MR applied
<chewitt>
no noticeable improvements in LE/Kodi using current (as of 10 mins ago) master
<chewitt>
on the +ve side, this also means nothing has been broken either :)
<chewitt>
raster: do you have your changes for RK in public repo(s) anywhere?
<chewitt>
I'd like to see if I can patch/hack up an LE image with them
<raster>
chewitt: hey .. which changes?
<chewitt>
whatever you did to get a usable RockPro64 image
<raster>
like this images is a bastardized result of the ayfan debian image turned into testing with a special 4.20 kernel binary pkgs he ade with hacked dtb
<chewitt>
linux version + defconfig and any changes, plus mali_kbase, plus anything mesa related
<raster>
and i hand compiled mali_kbase from the rk3399 branch and just insmod by hand
<raster>
and i have a personal patch to panfrost to fix empty cbufs but i think tomeu will have his own variant coming soon
<raster>
i also merged the opengl + mem rework mr's
<raster>
i'm not totally sure how i should package up these changes... :)
<raster>
its a bit of a dogs breakfast
<raster>
i could give a rootfs tarball
<raster>
i actually user de-personalized it
<chewitt>
what kernel version is it using?
<raster>
4.20
<raster>
but not mainline as-is
<raster>
its aufan's repo with patches for hdmi in it
<raster>
plus i hand dropped in my custom dtb
rhyskidd has quit [Quit: rhyskidd]
<raster>
i was looking at maybe fixing up the dts in the linux tree i have
<raster>
but it'd take a while of compiling, rebooting, testing and i prioritized getting this image ready
rhyskidd has joined #panfrost
<raster>
so if it was a simple patch to mesa - easy to dist
<raster>
its a series of things i need to more cleanly fix up
<raster>
i can share my dtb/dts
<raster>
and pu panfrost mesa tree
<raster>
which are the main things
<chewitt>
it's always an interesting exercise to see if you can repeat miracles :)
<raster>
the rest is building on existing public pkgs
<raster>
hahaha
<chewitt>
if you can share the dts that would be cool
<raster>
no problems there
<chewitt>
i'll have have a look for ayufan's kernel repo
<raster>
ultimately i would like to have a "all working out of the box cleanly done" image
<chewitt>
LE is quite a nice test-bed for whether the packaging is in good shape .. since we build everything from source
<raster>
linux-image-4.20.0-1083-ayufan-g686e1f1aa461 (he has a deb of that)
<raster>
asit was decompiled its vastly different fro the dts in the kernel src tree
<raster>
so i was going to have to find a cleaner way to do this
<raster>
so i can just patch the kernel dts
<raster>
that'd be a good step and get that back to upstream kernel if its not there yet
<raster>
once i have an image dump i'mm clean that up a bit and remove unused blocks (zero it out and cleanly untar current state with a new mkfs setup)
<chewitt>
ok
<chewitt>
once I have a working default-ish kernel I can dump the working dts and then diff against yours
<raster>
mine has minimal changes
<raster>
really just the vdd fix
<raster>
i did notice the 4.4. kernel section for mali has a lot more like power domain stuff
<raster>
etc.
<raster>
so seemingly proper power management capabilities
<raster>
now is the time i can look at cleaning up the dt mess that i have things working (about as well as they can given current panfrost state)
pH5 has quit [Quit: bye]
raster has quit [Remote host closed the connection]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
BenG83 has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
tgall_foo has joined #panfrost
anarsoul|2 has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
rtp has joined #panfrost
afaerber has quit [Ping timeout: 264 seconds]
<hanetzer>
vdd fix?
stikonas has joined #panfrost
BenG83 has quit [Quit: Leaving]
afaerber has joined #panfrost
afaerber has quit [Quit: Leaving]
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
robert_ancell has quit [Ping timeout: 240 seconds]
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
NeuroScr has joined #panfrost
afaerber has joined #panfrost
Elpaulo has joined #panfrost
NeuroScr has quit [Quit: NeuroScr]
NeuroScr has joined #panfrost
<Lyude>
hanetzer: ok!
<Lyude>
*oh!
<Lyude>
I just noticed your message
<Lyude>
Did you figure out the kbase build failure?
<hanetzer>
Lyude: yeah. the 4.20 guard is wrong, narmstrong is gonna fix it :P
<Lyude>
aah ok
<Lyude>
sorry for the late response
<hanetzer>
also with kernel 4.20.2 and stock rk3399-gru-kevin.dtb mali_kbase doesn't probe properly; can't get regulator 'mali'
<Lyude>
huh, I thought I saw some discussion in the channel earlier up about that ?
NeuroScr has quit [Quit: NeuroScr]
NeuroScr has joined #panfrost
<alyssa>
chewitt: "this also means nothing has been broken either" Hehe
<alyssa>
chewitt: TBH, RK3399 is close enough to behaving sanely that you probably can do it all "natively" without magic from the various board-specific downstreams
<alyssa>
Mainline kernel + mali_kbase/rk3399 branch (but you have that going for S912 anyway, so same idea here) + HDMI patches apparently + maybe audio patches?
<alyssa>
The defconfig is reasonable close to what we care about
<hanetzer>
alyssa: heyo. so, mali_kbase is building for me but insmod'ing it is failing to find the mali regulator; are you guys using the stock rk3399-gru-kevin dtb?
<alyssa>
(Between master on panfrost/mali_kbase and what I had in my local tree)
<hanetzer>
hmm. nothing that touches where I'm erroring out.
<hanetzer>
yeah, and your its is more or less the same as mine
NeuroScr has quit [Quit: NeuroScr]
* hanetzer
stole his from archlinuxarm
<alyssa>
Hmph
<hanetzer>
can your provide your current dtb you're booted with? if you have dtc installed on the machine you can recreate the dtb from the sysfs path /sys/firmware/devicetree/base (or perhaps copy /sys/firmware/fdt; this appears to be the binary dtb )
<hanetzer>
ah nope, that one is apparently the coreboot embedded fdt for other things