alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - https://gitlab.freedesktop.org/panfrost - Logs https://freenode.irclog.whitequark.org/panfrost - <daniels> avoiding X is a huge feature
stikonas has quit [Remote host closed the connection]
chewitt has joined #panfrost
alyssa_ has joined #panfrost
<alyssa_> Okay, I'm back
<alyssa_> I'm still super mad at git, though
* alyssa_ grumbles
<alyssa_> (I want to put STK on the C201 for demo value but I need to free up a lot more space first)
<alyssa_> TBH I'm just going to squash my 12-patch series because.... meh
<alyssa_> I can already see the headlines
<alyssa_> "Mesa developer rage quits, returns 4 hours later"
<HdkR> Do you need external storage?
<alyssa_> HdkR: I have disks, I'm just adverse to using them :p
<HdkR> I mean, do you need external NAND storage? :P
<alyssa_> I have an SSD, it's just extra annoyance
<HdkR> mmhm
<alyssa_> Although I do recall on this machine I built stuff over USB and that was faster than trying to wrangle internal storage so
<alyssa_> Yeah let's do that
<alyssa_> STK build started
<alyssa_> I'm kinda curious how long this'll take on my poky C201
<alyssa_> While that's going, let's squash 12 patches into 1 on the other machine
<alyssa_> ("Do you really have to have 3 laptops out simultaneously to work?" "...Yes?")
<HdkR> Nothing unusual
<mifritscher> indeed^^
<HdkR> A worse situation is being surrounded by like four Android devices in addition to the three x86 machines
<HdkR> The horror
<alyssa_> HdkR: Nah, I just have my two Kevins, a Veyron, and a Nexus phone
<alyssa_> It's ironic how deeply intertwined I am into the Google ecosystem, given my politics :p
<alyssa_> As an aside: I don't see how checksumming is supposed to work with MRT enabled. Maybe it isn't?
<alyssa_> Yas!
<alyssa_> I've got STK running on my C201
<alyssa_> Look ma, no blobs! :)
<alyssa_> Strangely, all the karts are invisible, among other rendering bugs that I'm sure didn't affect the other machine...
<alyssa_> ....Seriously, where are these karts
<alyssa_> Also, did they remove Oliver's Math Class? I loved that course! D:
<alyssa_> I should really implement mipmapping :blush:
<HdkR> How else will people remove aliasing and have fun LOD effects? :P
<HdkR> <3 mipmap based LOD effects
<alyssa_> :p
<alyssa_> Performance is surprisingly good on the C201
<alyssa_> Although that might be related to none of the carts rendering :P
<alyssa_> Uniroincally though why are there just no karts
<HdkR> If there aren't any other racers then I think you win the race
<alyssa_> HdkR: No like
<alyssa_> The karts are there on the minimap
<alyssa_> THey're just not rendering (including my own kart)
<alyssa_> I know the models are fine since they're rendering in the choose-a-kart panel
<alyssa_> It's fine on Kevin (though that's an older tree, maybe they changed something)
<mifritscher> if the lovers math class isn't here by default, it is available by plugin
<mifritscher> you could try to change the animated car option
<alyssa_> mifritscher: It was, just wasn't loading at first for some reason
<mifritscher> ah
<chewitt> robher: minor request .. could we (you) move the "obj-$(CONFIG_DRM_PANFROST) += panfrost/" in drivers/gpu/drm/Makefile to somewhere other than the end of the file, at least temporarily
<chewitt> lima is doing the same and it creates a clash in patchsets
<chewitt> I have a common kernel source for both lima / panfrost using images
<alyssa_> Ideally both will be merged soon..
<chewitt> drivers/gpu/drm/panfrost/Kconfig also has a hard dependency on DRM_ROCKCHIP
<alyssa_> --Yup, that one's wrong :P
<chewitt> and .. a rebase against 5.0.0 (or 5.0.1) would be nice, there's some patch fragments that are already merged in later sources
<alyssa_> Isolated the issue in glmark -btexture as well under glmark2-es2-wayland
<alyssa_> But it's fine in -drm
<alyssa_> Wat?!
<alyssa_> Note to self: fix non-tile strides already, gah
<HdkR> What's messing up stride?
<alyssa_> Fixed the glmark bug but still no karts
<HdkR> Might want to double check the GL stride limits in case any of those are violated :P
<alyssa_> Seriously, karts render fine on Kevin, just not Veyron.. what gives?
<alyssa_> No relevant fault
<chewitt> robher: squashing commits would be nice too .. lima became a lot easier to track once @yuq reduced 65+ commits to ~10
<alyssa_> Squish
<chewitt> also, what magic might be required for T820 support
<chewitt> I think i've seen explicit mention of T860 and T760 only in changes
<alyssa_> chewitt: For user or kernel?
<chewitt> kernel
<alyssa_> chewitt: Probably shouldn't be much any magic
<alyssa_> Add a compatible line
<alyssa_> See where it takes ya
<alyssa_> I think there's a place where we hardcode settings for t860, try copying those..
<chewitt> actually looks like it's covered in later commits
<chewitt> theoretical support for bifrost too (at least in gpu props)
<chewitt> might have to put this on an S905X2 board and see what crashes :)
<chewitt> (G31)
<HdkR> Bifrost isn't supported in userspace yet though :P
<chewitt> ahh.. okay
<chewitt> time for work anyway :)
<HdkR> Being worked on, I've just been too busy to continue the past couple weeks
<chewitt> I have G31 hardware that boots mainline "almost everything" now so am keen to poke stuff whenever basic support appears
chewitt has quit [Quit: Adios!]
Elpaulo has joined #panfrost
Elpaulo has quit [Client Quit]
Elpaulo has joined #panfrost
<tomeu> alyssa_: thanks a lot for shepherding the patches to mainline!
_whitelogger has joined #panfrost
TheKit has quit [Read error: Connection reset by peer]
<bbrezillon> alyssa_: Hi
<bbrezillon> tomeu probably already told you I was planning on working on the HW perfmon support for the drm panfrost driver
<bbrezillon> just wanted to know if what I have in mind for the HW perfmon API matches what you need
<tomeu> bbrezillon: have you seen how the nondrm backend calls into kbase regarding perf counters?
<bbrezillon> I was basically planning on doing something similar to the vc4/etnaviv drivers
<bbrezillon> tomeu: yep, I had a look, but the approach taken there is a bit different from the one used in VC4/etnaviv
<tomeu> bbrezillon: different enough that those callbacks cannot be implemented with the uapi used in vc4/etnaviv?
<bbrezillon> in the nondrm driver, there's an ioctl to enable/disable/dump HW counters values, but that means you don't know how each GPU job impacted the counters, unless you keep resetting HW counters between each GEM_SUBMIT call
<bbrezillon> the approach taken by the etnaviv/VC4 driver is a bit different => you say which counters you'd like to track on a per-job basis
<bbrezillon> in VC4 this is done by creating a perfmon instance that list the counters the user would like to track and the current counter values, and then attaching the perfmon handle to the gem_submit req
<bbrezillon> and, IIRC, on etnaviv the counters to track are directly listed in the gem_submit request, instead of having this perfmon instance abstraction
<bbrezillon> tomeu: do you mean that you want to emulate the old behavior with the new driver?
<tomeu> well, we need to get the new uapi right, no matter what
<tomeu> but it would be nice if mesa mainline could keep using the nondrm backend for some more time
<bbrezillon> tomeu: not even sure HW counters were used by the mesa driver
<tomeu> bbrezillon: which mesa driver?
<bbrezillon> the mainline one
<bbrezillon> (panfrost)
<tomeu> bbrezillon: they are being written to a mdgprf file atm
<bbrezillon> tomeu: I see
<bbrezillon> tomeu, alyssa_: which brings me to the next thing I wanted to discuss => how do we want to expose those counters to mesa users
<tomeu> bbrezillon: how are vc4 and etnaviv users making use of counters?
<bbrezillon> making use of it is yet another topic :)
pH5 has joined #panfrost
<bbrezillon> VC4/freedreno/etnaviv all expose their counters through pipe_query
<bbrezillon> tomeu: I'll see what I can do to keep the existing counter dump logic to work with the new interface
<tomeu> yeah, guess it would be ideal iof we could have a uapi similar to that of other drivers, and support both the current dumping as done with kbase, and expose it to gallium with pipe_query
BenG83 has quit [Quit: Leaving]
BenG83 has joined #panfrost
adjtm_ has joined #panfrost
adjtm has quit [Ping timeout: 268 seconds]
adjtm_ has quit [Remote host closed the connection]
adjtm has joined #panfrost
pH5 has quit [Ping timeout: 259 seconds]
afaerber has quit [Quit: Leaving]
adjtm_ has joined #panfrost
adjtm has quit [Ping timeout: 245 seconds]
afaerber has joined #panfrost
<alyssa_> tomeu: Baaaa
<alyssa_> bbrezillon: Thank you for the input on uapi, I haven't started reading on that stuff yet but this will be heplful :)
<alyssa_> At the moment, performance counters are for my use only; they're not exposed anywhere really
<alyssa_> (I.e. for debugging driver performance, not for debugging user app performance)
TheCycoONE has quit [Quit: ZNC 1.7.2 - https://znc.in]
<tomeu> alyssa_: forgot to tell you that I have rebased your series on top of master: https://gitlab.freedesktop.org/tomeu/mesa/commits/mainline-driver
adjtm_ has quit [Remote host closed the connection]
BenG has joined #panfrost
BenG83 has quit [Ping timeout: 268 seconds]
TheCycoONE has joined #panfrost
stikonas has joined #panfrost
pH5 has joined #panfrost
_whitelogger has joined #panfrost
lyudess has joined #panfrost
Lyude has quit [Ping timeout: 244 seconds]
raster has joined #panfrost
jolan has quit [Quit: leaving]
afaerber has quit [Quit: Leaving]
raster has quit [Remote host closed the connection]
<robher> **** I pushed in panfrost-5.0 to panfrost/linux tree. This plus mesa master are working now (though tomeu has a branch with more mesa changes). ****
<lyudess> nice!
lyudess is now known as Lyude
afaerber has joined #panfrost
jolan has joined #panfrost
<alyssa_> <3
Guest24641 has left #panfrost ["User left"]
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
urjaman has quit [Quit: WeeChat 2.2]