alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - https://gitlab.freedesktop.org/panfrost - Logs https://freenode.irclog.whitequark.org/panfrost - Transientification is terminating. Memory reductions in progress.
stikonas has quit [Remote host closed the connection]
hanetzer is now known as toastdust
toastdust is now known as hanetzer
<alyssa> Oh, this is interesting
<alyssa> Re black rectangles in Weston
<alyssa> If I launch Weston nested inside sway
<alyssa> The places that are normally black are now..... the sway background there
<alyssa> It's not just black, it's _transparent_
<anarsoul|2> :)
<alyssa> anarsoul|2: Any brilliant idea? :P
<anarsoul|2> nope
<alyssa> (Mind you, the black is also not the same as clear colour... It's just, like, 0,0,0,0 I guess)
<alyssa> I really suspect tile writeback but not sure how to debug that per se
<alyssa> FBOs are definitely to blame somehow, I think
<alyssa> It might be worth it to do the grand FBO overhaul
<alyssa> And hope that this issue sorts itself out as a consequence (since it probably might)
<alyssa> Er wai
<alyssa> So, weston doesn't even use FBOs apparently, at least not according to Panfrost's is_scanout
<alyssa> Suspicous
<alyssa> Suspicious since there is definitely FBO usage in the code
<alyssa> .....in connection to ReadPixels of the FBO??
<alyssa> Okay, yeah, nope, maybe not fbos
<alyssa> Well, if it's not FBOs, I have to wonder
<HdkR> alyssa: It could be a misinterpretation of RGBX
<HdkR> RGBA8 has the same value packing as RGBX which is what things use for windowing and I know has caused X issues in the past
<alyssa> HdkR: Hmm
<alyssa> HdkR: The issue is specifically, like
<alyssa> The last frame after opening or closing a window has black (transparent) where the window was/is
<alyssa> The immediate next frame is fine
<alyssa> Aside: 3D textures in a 2D UI? really? >_<
<alyssa> Oh, it's 1x1x1...
<alyssa> for some reason
adjtm_ has joined #panfrost
NeuroScr_ has joined #panfrost
maciejjo_ has joined #panfrost
ezequiel1 has joined #panfrost
Moe_Icenowy has joined #panfrost
NeuroScr has quit [*.net *.split]
adjtm has quit [*.net *.split]
tgall_foo has quit [*.net *.split]
mmind00 has quit [*.net *.split]
MoeIcenowy has quit [*.net *.split]
ezequielg has quit [*.net *.split]
maciejjo has quit [*.net *.split]
Moe_Icenowy is now known as MoeIcenowy
NeuroScr_ is now known as NeuroScr
<alyssa> ...You know what, maybe just do some simpler cleanup
anarsoul|2 has quit [Ping timeout: 268 seconds]
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #panfrost
<hanetzer> dill flavored sunflowe seeds :P
<alyssa> Blink
<hanetzer> oh, and mali_kbase is not building for me; mali_kbase_gpuprops.c: error: called object totalram_pages is not a function or a pointer
<hanetzer> mah! there's a wierd cat outside! Are you even a cat? blink motherfucker!
<alyssa> ?
<hanetzer> its a dub thing :P
<alyssa> Please keep the language professional in this channel
<hanetzer> alyssa: https://www.youtube.com/watch?v=sJeuWZNWImE a rather funny vid. aight
NeuroScr has quit [Quit: NeuroScr]
<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> much even
<HdkR> mobile typing
<alyssa> Also, raster ^^ but they're not here rn
<HdkR> alyssa: Is using abs correct there?
<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]
tlwoerner has joined #panfrost
raster has joined #panfrost
rhyskidd has quit [Quit: rhyskidd]
rhyskidd has joined #panfrost
<alyssa> tomeu: Alright, cool
<alyssa> Thank you re the crate :P
<alyssa> cwabbott: Hm?
<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> that i used
<raster> google for it
<raster> or well ayufan's 4.20 deb pkgs
<raster> thats the dts i hacked up
<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> hanetzer: Yeah..?
<alyssa> I'm on:
<alyssa> mali_kbase, `rk3399` branch,
<alyssa> Only patch is
<alyssa> - err = reservation_object_reserve_shared(obj);
<alyssa> + err = reservation_object_reserve_shared(obj, 1);
<alyssa> To let it compile on slightly newer kernels
<alyssa> No patches to the kernel
<alyssa> Kernel is commit fc2fd5f0f1aa85925be2322275ee2dc5ac3acdf4
<hanetzer> wait, there's a rk3399 branch? I've been trying master
<alyssa> ...Yes
<hanetzer> and this is panfrost/mali_kbase.git on freedesktop?
<alyssa> Uh
<alyssa> tomeu's
<alyssa> I'm not sure which branch is master on Lyude's
<hanetzer> link?
<Lyude> alyssa: huh?
<Lyude> the panfrost mali_kbase branch only has one branch, master
<Lyude> mine is probably old and outdated at this point
<alyssa> Lyude: panfrost/mali_kbase is yours as far as I'm concerned ;p
<Lyude> are there currently merge requests waiting on mali_kbase btw? I don't think I've gotten any emails
* Lyude is wondering why we aren't all just pushing our stuff/putting mr's on that
<alyssa> No idea
<alyssa> I don't touch kernel unless forced to :p
<alyssa> Okay, lemme add that remote and diff
<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
<hanetzer> oh, its a bit of both