alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
Stary has quit [Ping timeout: 240 seconds]
vstehle has quit [Ping timeout: 250 seconds]
_whitelogger has joined #panfrost
mixfix411 has quit [Ping timeout: 256 seconds]
cwabbott has joined #panfrost
vstehle has joined #panfrost
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
jernej has joined #panfrost
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
chewitt has quit [Quit: Zzz..]
cwabbott has quit [Ping timeout: 246 seconds]
chewitt has joined #panfrost
_whitelogger has joined #panfrost
guillaume_g has joined #panfrost
nerdboy has joined #panfrost
nerdboy has quit [Ping timeout: 240 seconds]
mias has joined #panfrost
icecrea105 has joined #panfrost
icecream95 has quit [Ping timeout: 250 seconds]
icecrea105 has quit [Client Quit]
pH5 has joined #panfrost
cwabbott has joined #panfrost
icecream95 has joined #panfrost
jernej has quit [Ping timeout: 246 seconds]
<icecream95> I've now got Tesseract rendering things, but I wouldn't say it looks exactly like it's supposed to: https://gitlab.freedesktop.org/snippets/923
<icecream95> As can be seen in the last screenshot, only small sections of the map are rendered at a time, which seems similar to what happens with the Polymer renderer for EDuke32
jernej has joined #panfrost
<HdkR> TFW I'm waiting for Kirin 980/990 SBCs to arrive so I can throw them in CI
<HdkR> Or a Snapdragon 865 devboard running Linux :P
davidlt has joined #panfrost
MastaG has quit [Quit: The Lounge - https://thelounge.chat]
icecream95 has quit [Ping timeout: 240 seconds]
stikonas has joined #panfrost
raster has joined #panfrost
robmur01_ has joined #panfrost
<tomeu> narmstrong: I'm seeing erratic behavior with panfrost on the n2, wonder if it's operating with the correct voltage and clock frequency
<tomeu> it's similar to what I observed on the rk3399 due to the voltage being fixed and not sufficient for some frequencies in the OPP
<tomeu> only that happens a bit more often
<tomeu> I saw some hack in the odroid kbase that effectively disabled devrfeq and fixed a given frequency
<narmstrong> tomeu: the freq change is not supported yet but with the current freq it works perfectly fine with kbase without devfreq
<narmstrong> The voltage of the gpu is fixed
<tomeu> then wonder if the problem isn't MMU-related
<tomeu> basically, sometimes stuff works and panfrost is also able to read back the command descriptors after submission (and execution)
<tomeu> other times, I get faults from the GPU and when we read back the descriptors from mesa, they contain random garbage
<robmur01_> TBH that sounds more like some descriptor pointer is wrong and causing the GPU to scribble over its own command stream
<robmur01_> T620 seemed to do that sometimes back before SFBD got more attention
<tomeu> robmur01_: I get different faults though, I would have expected it to be more predictable in that case
<tomeu> though I suspect something about the tiler, though in this specific case I don't have any draws, just a single clear
<tomeu> narmstrong: what frequency is that?
<tomeu> in one kernel, I have found 285000000
<tomeu> that's much slower than the 800MHz I'm using here
<narmstrong> tomeu: the freq is set in the DT
<narmstrong> Look in g12-common.dtsi
<tomeu> narmstrong: and the kbase you are using is respecting that?
<narmstrong> Yes
<narmstrong> We use the same mechanism for Midgard here
<tomeu> yeah, you seem to be right, I see the same erratic behavior at 266666663
MastaG has joined #panfrost
robmur01_ has quit [Ping timeout: 250 seconds]
robmur01_ has joined #panfrost
mias_ has joined #panfrost
mias has quit [Read error: Connection reset by peer]
<tomeu> some of the faults are TILE_RANGE_FAULT, so I guess we have a suspect
MastaG has quit [Quit: The Lounge - https://thelounge.chat]
MastaG has joined #panfrost
Stary has quit [Read error: Connection reset by peer]
Stary has joined #panfrost
robmur01_ has quit [Ping timeout: 264 seconds]
robmur01_ has joined #panfrost
raster has quit [Ping timeout: 264 seconds]
Stary has quit [Ping timeout: 246 seconds]
raster has joined #panfrost
robmur01_1 has joined #panfrost
robmur01_ has quit [Ping timeout: 264 seconds]
robmur01_1 is now known as robmur01_
<alyssa> tomeu: TILE_RANGE_FAULT is from the min/max_tile_coord arguments being wrong
jolan has quit [Quit: leaving]
jolan has joined #panfrost
<alyssa> tomeu: Anyway, yes, the job stuff can do writes
<alyssa> so it's possible we have something so corrupted that that's writing to the fragment payload
<tomeu> alyssa: so maybe the min/max_tile_coord fields get overwritten if the job descriptor isn't aligned correctly?
<tomeu> well, the header
<alyssa> Yeah, I'm wondering if that could be something ish
<alyssa> Probably not exactly that but
<alyssa> Ohhhh this is interesting
<alyssa> Hold your horses~
<alyssa> tomeu: mali_payload_fragment is too slow
<alyssa> *small
<alyssa> Ithink
<alyssa> idk how that would result in the corruption we're seeing but could be a hw bug
<alyssa> Bifrost - even the bugs have bugs~
<tomeu> mali's mali_job_descriptor_header is aligned to 512 in this trace
<alyssa> and ours?
<alyssa> Modifying pandecode to make payload_fragment larger, I see there is stuff after what we decode. It's not clear to me if it's part of the structure or the adjacent thing.
<tomeu> to 256
<tomeu> ok, those are really good hints
<alyssa> tomeu: I'd give 512 alignment a try then. Seems like a very silly thing but maybe they were aggressively optimizing the job handling logic and wanted to simplify the address computation :p
<tomeu> hehe
<tomeu> would you do something like that? :p
<alyssa> tomeu: absolutely.
<alyssa> Note job_descriptor_header is 32 bytes
<alyssa> payload fragment on Midgard is 16 bytes
<alyssa> The next 16 bytes are zero
<alyssa> Then data only starts showing up again after that
<alyssa> which indicates either that the payload is a LOT bigger than we thought, or that it's no bigger at all and that's spurious data from another unrelated descriptor (midgard blobs do that too)
<alyssa> isn't Mali fun? :3
robertfoss has quit [Quit: WeeChat 2.3]
<tomeu> it works and fails regardless of the alignment (the gpu address doesn't change between runs)
<tomeu> so I guess I will look at missing descriptor fields on monday
robertfoss has joined #panfrost
robertfoss has quit [Client Quit]
robertfoss has joined #panfrost
<alyssa> alright~
<alyssa> Next up for me - implementing load_uniform
<alyssa> and then attributes and varying writes
<alyssa> in the packing
unoccupied is now known as _4of7
_4of7 is now known as leah
leah is now known as unoccupied
robmur01_ has quit [Ping timeout: 264 seconds]
robmur01_ has joined #panfrost
<alyssa> in the packing
<alyssa> oops
buzzmarshall has joined #panfrost
robmur01_ has quit [Ping timeout: 264 seconds]
robmur01_ has joined #panfrost
<alyssa> Okay, I have packing for varying writes now.
guillaume_g has quit [Quit: Konversation terminated!]
nerdboy has joined #panfrost
stikonas_ has joined #panfrost
stikonas has quit [Ping timeout: 250 seconds]
nerdboy has quit [Ping timeout: 264 seconds]
robmur01_ has quit [Ping timeout: 264 seconds]
<alyssa> tomeu: narmstrong: What are folks using for kernels on the N2?
<alyssa> (I assume it's not mainline..)
<narmstrong> alyssa: you mean hardkernel ?
<narmstrong> I personally only use mainline
<narmstrong> Same for chewitt
<chewitt> everything needed for N2 is already upstream
raster- has joined #panfrost
<chewitt> minus some bits for hardware video decode, but that's mostly done for 5.7 and no something needed for panfrost work
nerdboy has joined #panfrost
raster has quit [Ping timeout: 264 seconds]
<alyssa> chewitt: Oh, awesome !
<alyssa> narmstrong: what about panfrost? iirc you had patches for panfrost.ko for amlogic issues?
raster- has quit [Quit: Gettin' stinky!]
raster has joined #panfrost
<chewitt> ^ ignore the last commit, pick the previous four commits
<alyssa> Ack
<alyssa> chewitt: (and that works?)
<chewitt> it will probe and load the driver
<alyssa> Alrighty.
raster has quit [Quit: Gettin' stinky!]
<chewitt> kmscube tried to use swrast last time I tried it
<alyssa> Well yes :)
<alyssa> I assume there's a defconfig for odroid n2?
<alyssa> also userspacs uh
<alyssa> I am so thoroughly entrenched in my Chromebook world :p
stikonas_ has quit [Remote host closed the connection]
<alyssa> Thank you
stikonas has joined #panfrost
<chewitt> Armbian supports N2 well if you need a pre-built full OS
<chewitt> ^ that defcoonfig might be a little LE specific
<chewitt> but works fine on N2/VIM3 etc.
robmur01_ has joined #panfrost
raster has joined #panfrost
<alyssa> NOrmAlrighty
<HdkR> "Alrighty then~"
<HdkR> Oop, showing my age, old person quote
<alyssa> HdkR: Bwah?
<alyssa> chewitt: what's the preference between odroid.com's Ubuntu images and armbians?
<HdkR> Ace Ventura quote :P
<chewitt> I've never used Odroid's ones
<chewitt> so couldn't give an opionion
<alyssa> "Classic movie, only gets *overtly* transphobic at the end" --Brooklyn 99 on Ace Ventura
<chewitt> but, the folks in #armbian will be delighted to help with anything should you get stuck so that would be my personal preference
<chewitt> or .. roll your own distro
<alyssa> Fair. I think I'll go with armbian for now then
<alyssa> Normally I'd be a Debian user but not really in the mood to fight with debootstrap.
<alyssa> Armbian is close enough anyway
<HdkR> alyssa: Oof, six year old me must have not picked up on that. Pretty poor film overall though
<alyssa> odroid n2 is aarch64 yes? no need for x compiler?
<HdkR> yea :D
<alyssa> Sweet
<alyssa> Next up is cull the config
<alyssa> I don't need virtualization, etc
nerdboy has quit [Ping timeout: 250 seconds]
<HdkR> Six core device should have a decent amount of perf behind it
<chewitt> the LE defconfig is already pretty minimal
<chewitt> you could turn off some dvb and wifi drivers, but that's about all
<alyssa> Won't be needing AMD or nouveau gpu :p
<chewitt> definitely not enabled in that defconfig
<chewitt> we use project (SoC) specific configs
<alyssa> They were?
<chewitt> the Armbian one will be more generic
<alyssa> shrug
<alyssa> Yeah idk
<alyssa> Oh I dumb
<alyssa> okay you're good to go
<alyssa> make -j6 now!
<alyssa> ` usr/gen_initramfs.sh: Cannot open '@INITRAMFS_SOURCE@'
<alyssa> `
<alyssa> seems le specific ;)
<chewitt> Ace Ventura is ~1994 IIRC .. which makes @HdkR .. lots younger than me :)
<alyssa> make -j6 again
<alyssa> and off to go do normal people things~
<HdkR> normal people things for a few minutes while it compiles :)
<chewitt> we sed a couple of things via build scripts
<alyssa> sed no evil
<chewitt> @DISTRONAME@ is there too IIRC
<HdkR> alyssa: That's the downfall of having faster hardware. Less time standing on chairs and swordfighting while code is compiling
<HdkR> 2990WX too fast, can't have any fun :P
<chewitt> I have 2950X which is slower but still damn fast
<HdkR> I'm concerned about what will happen once I upgrade to 64 cores
<chewitt> LE images (entire distro) take ~25 mins if I shut down all the work VMs that are normally in the backgroound
<HdkR> nice
<chewitt> I've spotted 2990WX chips going for about $1k .. so might have to find some way to get an upgrade via work
<chewitt> @HdkR if you're upgrading I highly recommend https://www.quietpc.com
<chewitt> the box I have is completely silent .. even under sustained heavy compile loads
<chewitt> kids have hamsters in a cage near the server .. hamsters make way more noise :)
<chewitt> I'm using nvme ssd .. spinning rust would prob. add some noise
<HdkR> ah, I have a custom 360 rad water loop on my 2990WX. Once I upgrade to a 64core then I'm going to throw two 360mm rads at the problem :P
<HdkR> 64core upgrade will be waiting on Zen3 though, 2990WX->3990X isn't enough of a leap yet
<HdkR> Gaming rig will be upgraded to Zen3 when that happens as wel. Since it'll have better than Intel perf
* alyssa compiling network drivers apparently now
robmur01_ has quit [Ping timeout: 264 seconds]
nerdboy has joined #panfrost
<alyssa> it finished while I was eating I guess
robmur01_ has joined #panfrost
davidlt has quit [Ping timeout: 264 seconds]
<alyssa> Okay time to figure out how to use this
nerdboy has quit [Ping timeout: 250 seconds]
adjtm has joined #panfrost
adjtm_ has quit [Ping timeout: 246 seconds]
robmur01_ has quit [Ping timeout: 250 seconds]
robmur01_ has joined #panfrost
nerdboy has joined #panfrost
robmur01_ has quit [Ping timeout: 250 seconds]
nerdboy has quit [Ping timeout: 256 seconds]
cwabbott has quit [Ping timeout: 246 seconds]
MistahDarcy has quit [Ping timeout: 268 seconds]
MistahDarcy has joined #panfrost
nerdboy has joined #panfrost
nerdboy has quit [Ping timeout: 264 seconds]
icecream95 has joined #panfrost
jernej_ has joined #panfrost
jernej has quit [Read error: Connection reset by peer]
jernej_ is now known as jernej
stikonas has quit [Ping timeout: 246 seconds]
stikonas_ has joined #panfrost
paulk-leonov has quit [Ping timeout: 246 seconds]
paulk-leonov has joined #panfrost
Moe_Icenowy has joined #panfrost
MoeIcenowy has quit [Ping timeout: 246 seconds]
paulk-leonov has quit [Ping timeout: 246 seconds]
stikonas_ has quit [Read error: Connection reset by peer]
Moe_Icenowy is now known as MoeIcenowy
stikonas has joined #panfrost
<alyssa> chewitt: narmstrong: Any magic tricks to get mainline to boot?
raster has quit [Quit: Gettin' stinky!]