<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)
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]