<chewitt>
I didn't figure out what changes are needed in kbase to fix for that yet (not a high priority)
stikonas has joined #panfrost
rhyskidd has joined #panfrost
<tomeu>
ok, I just commented those lines out in kbase
<tomeu>
got it working now
<chewitt>
btw, I did a bunch of testing after the amlogic email
<chewitt>
T820 with Neil's patch for gxm/g12 mali devices .. all fine
<chewitt>
G31 with the patch .. dmesg is clean
<chewitt>
G52 with the patch .. shows some faults
<chewitt>
T820 no patch .. shows some errors but Kodi still comes up and works fine
<chewitt>
G31 no patch .. shows errors and Kodi shows black screen but does appear to start in the background (can hear audio noises from the GUI)
<chewitt>
G52 no patch .. same as G31
<chewitt>
bifrost devices .. lots of scheduler faults and such at the same time
maccraft has joined #panfrost
<maccraft>
hello, is hardware video decoding supported?
<chewitt>
so Sky Zhou's comment that bifrost doesn't need the special handling and T820 does .. is the opposite of my findings :)
<chewitt>
maccraft panfrost has nothing to do with hardware video decoding.. that's another chip
<maccraft>
chewitt: oh
<chewitt>
panfrost is accelerated GL/GLED (GUI rendering) only
<chewitt>
GL/GLES
<tomeu>
chewitt: just did the same testing here, and with MALI_PLATFORM_NAME=devicetree and without MALI_PLATFORM_POWER_DOWN_ONLY, stuff works fine on the n2
<tomeu>
so looks as if the GPU integration on the soc on the n2 is just normal
<chewitt>
that's the search I use for tracking patches
<tomeu>
hrm, looks we have some work to do
<chewitt>
I was trying to pick stuff into my branch for testing but eventually I ran into bits that didn't apply clean or were part of other large series
<chewitt>
most of it looked like cleanup/ettiquette rather than a good old-fashioned fix
<chewitt>
then the day-job intervened and I got behind, and didn't work up the enthusiasm to catch-up again yet
nlhowell1 has quit [Ping timeout: 240 seconds]
rhyskidd has quit [Read error: Connection reset by peer]
Ntemis has quit [Read error: Connection reset by peer]
<alyssa>
tomeu: "MALI_PLATFORM_NAME=devicetree and without MALI_PLATFORM_POWER_DOWN_ONLY, stuff works fine on the n2" that much is good to hear
<mchehab>
hi, I'm trying to test the Panfrost driver on a SoC with a Mali T720... there is already a working drm/kms driver for such hardware, but when I'm trying to enable Panfrost, X doesn't start, returning:
<mchehab>
[ 360.880] (II) modeset(G0): using drv /dev/dri/card1
<mchehab>
[ 360.880] (EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices
<mchehab>
I'm using the version at Kernel 5.7
<tomeu>
mchehab: don't know about X any more, but I don't see anything in that referring to panfrost
<tomeu>
all seems to be display-related
<mchehab>
tomeu, basically, card0 there is the drm/kms driver, while card1 is the Panfrost driver
<urjaman>
you shouldnt be telling Xorg about panfrost
<urjaman>
or pointing it to the panfrost DRM device, that is
<mchehab>
I didn't make any changes at Xorg settings
<alyssa>
mchehab: What SoC is this?
<alyssa>
and specifically what drm/kms driver name?
<mchehab>
it is a HiKey970
<urjaman>
but yeah I dunno, it just works for my C201 so ... *shrug*
<tomeu>
mchehab: guess when you enabled panfrost, then it probed before the kms driver and thus the device file name changed?
<tomeu>
alyssa: actually, I may have to back that claim, as it's not working any more after some more kernel rebuilding
<tomeu>
I'm surprised though, because I did add instrumentation to make sure that the expected code paths were being hit
<tomeu>
hmm, I think it could have been a reboot
<tomeu>
that's an interesting possibility
<robmur01>
note that even with "PAN_MESA_DEBUG=bifrost" it's going to bail out on G72, without additional hacks
<tomeu>
right, I think that there's some configuration that happens with the meson PM backend that persists across module reloads
<mchehab>
are there too much things missed for G72?
<tomeu>
so if you load kbase first with it, then later the devicetree PM backend is enough
<tomeu>
narmstrong: any ideas?
<tomeu>
right, MALI_PLATFORM_POWER_DOWN_ONLY isn't needed at all apparently
<tomeu>
guess that on meson, because there isn't a regulator then the power is never lost
<tomeu>
so registers keep their previous values
rhyskidd has joined #panfrost
<tomeu>
ok, confirmed that setting GPU_PWR_KEY and GPU_PWR_OVERRIDE1 is enough to get panfrost probing correctly the shader cores, without any other changes
<tomeu>
but we still have the same instability as before
<robmur01>
tomeu: does suppressing RPM via sysfs help? (I forget how far we've gone down that path before...)
<tomeu>
just tried it, and no :/
<tomeu>
and there's no devfreq
<tomeu>
but when running glmark, it appears as if the first one or two jobs might be problematic, but the rest are fine
<robmur01>
so I guess the question is what exact state this "warm up" behaviour is relative to?
<robmur01>
if we rule out every possible way of anything getting powered off
<tomeu>
robmur01: yeah, that's what I'm wondering now
<tomeu>
afaics, the problem is that the GPU doesn't correctly read the cmdstream
<tomeu>
reading random stuff instead
<tomeu>
DATA_INVALID_FAULT is the most common fault, followed by TILE_RANGE_FAULT and then INSTR_INVALID_ENC
<tomeu>
and after that, faults trying to read from 0x0000000000000000
<chewitt>
timing? .. hardware needs to settle before you can use it
<chewitt>
(random guessing)
<tomeu>
yeah, but what part of the hw?
<tomeu>
daniels suggested poisoned cachesthat need to be flushed
<robmur01>
I think we had a suggestion before that something might be wonky with the caches
<tomeu>
yeah, played quite a bit with sending cache invalidation commands, without luck
<narmstrong>
tomeu: honestly, I have no idea what's going on... I would like to help, really
<narmstrong>
tomeu: I'll try to answer to sky.zhou, but reading the backlog you did try to use platform devicetree without MALI_PLATFORM_POWER_DOWN_ONLY and it worked ?
<tomeu>
narmstrong: yes, but only after having used kbase with the meson platform
<tomeu>
I'm looking at hacking the devicetree platform with PWR_KEY and PWR_OVERRIDE1 to see if it makes it work right away after boot
<narmstrong>
ok, so as you say the GPU_PWR_KEY and GPU_PWR_OVERRIDE1 are needed somehow
<tomeu>
yep
<narmstrong>
trying also on my side
<tomeu>
thanks, guess understanding what those values mean could help
<tomeu>
though it could be unrelated
<narmstrong>
tomeu: confirmed, with only devicetree it locksup, but with only GPU_PWR_KEY and GPU_PWR_OVERRIDE1 a single time works fine
<narmstrong>
tomeu: I suspect the GPU_PWR_OVERRIDE1 changes the default HW-based power control
<tomeu>
so the HW-based power control might be automatically powering up and down components that may require someu warm-up?
<narmstrong>
tomeu: yes, or maybe it disables auto powering down of some internal components
<tomeu>
but then, what could kbase be doingso it doesn't have this problem...
<narmstrong>
but I don't understand why panfrost doesn't require this for T820, but does for bifrost
<tomeu>
btw, without the override, panfrost failed to put the shader cores up during startup
<narmstrong>
for t820 ? but it still works later on
<tomeu>
ah no, here on the n2
<narmstrong>
ok
<tomeu>
SHADER_READY_LO never changed to the expected value
stikonas_ is now known as stikonas
* alyssa
hugs her rk3399
macc24 has quit [Quit: WeeChat 2.8]
guillaume_g has quit [Quit: Konversation terminated!]
* robmur01
glares at rk3530 being about a year late and counting
macc24 has joined #panfrost
macc24 has quit [Remote host closed the connection]
macc24 has joined #panfrost
macc24_ has joined #panfrost
macc24 has quit [Client Quit]
macc24_ has quit [Remote host closed the connection]
macc24 has joined #panfrost
<stikonas>
it will probably take a while before proper rk3530 support will be upstream. rk3399 has been out for years and still some features only just reached upstream
<stikonas>
(I can finally boot from M.2 (pcie) SSD without using sd or mmc cards with Uboot 2020.07)
<alyssa>
stikonas: audio is still borked for rk3399 mainline, unless it was fixed in the last few versions
<alyssa>
headphones/mic
<stikonas>
oh, I haven't tried audio... on rockpro64 there were some changes to split dtbs depending on board revision though... Not sure about which chip you use...
<alyssa>
chroembook
<alyssa>
(gru/kevin)
<robmur01>
as far as the SoC is concerned, "audio" stops at the I2S output - the rest is the board's fault ;)
<alyssa>
bbrezillon: if we submit two batches that depend on each other, we can queue them via NEXT, I think
<alyssa>
but I'm not sure how drm_sched interacts with that
<alyssa>
I guess the idea is to modify the `dependency` callback to drm_sched to skip over the fence for the job slot we're queueing to
<alyssa>
regardless that's transparent to userspace provided userspace specifies the right fences
<alyssa>
and we can still provide FIFO behaviour to userspace
<alyssa>
(at least, the appearance of FIFO behaviour)
<alyssa>
the operative question is, do we have to continue tracking deps on batches that are already submitted?
<alyssa>
with the current uabi, that's a no
<alyssa>
if we want to do entirely explicit deps with no ordering gaurantees in kernel, that's a yes
<alyssa>
but maybe there's a happy meidum
<bbrezillon>
I think that's what I was aiming for initially, which partly explains the way it's implemented
<alyssa>
right, yeah
<alyssa>
I'm just trying to figure out if that's needed the way our hw is structured, or if ensuring the order we submit batches is topologically sorted is enough
<bbrezillon>
the question is, are we good with BO-based dep tracking, or are there use cases which need explicit inter-job deps
<alyssa>
IIRC explicit deps via syncobjs are needed for vk
<alyssa>
so it's not like the api is going anywhere
<alyssa>
but for GL, I'm just really struggling to think of a case where BO-based tracking doesn't cut it, even once we throw concurrent vt/frag jobs and *_NEXT registers into the mix
<bbrezillon>
I meant for the gallium driver
<alyssa>
so I guess rip it out, and in the off chance we need something more, we'll fix it then because inevitably it'll look different anyway so not much is lost?
<bbrezillon>
indeed
<alyssa>
ack
* alyssa
tries to figure it out the better data struct then
<alyssa>
bbrezillon: reading about Rust is making me paranoid about getting the lifetimes right for this ;v
<bbrezillon>
yes, you'll still need an object that last longer than the batch, for BO access tracking
<bbrezillon>
maybe not actually
<alyssa>
Give panfrost_batch a set of parent and children nodes, entirely weak references
<alyssa>
when adding a dep, add it as a child and add yourself as parent to it
<bbrezillon>
if we really on BO to enforce inter-job dep, we can just remove the batch from the bo_access object when it's destroyed
<alyssa>
when destroying a batch, remove yourself as parent from each of your children
mixfix41 has quit [Ping timeout: 258 seconds]
stikonas has quit [Remote host closed the connection]
<alyssa>
bbrezillon: Might be artificial, but on an apitrace of chromium, I'm seeing a 10% reduction in frametime with the syncobj overhaul.