alyssa changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs - <daniels> avoiding X is a huge feature
macc24 has quit [Ping timeout: 260 seconds]
stikonas has quit [Ping timeout: 272 seconds]
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #panfrost
rhyskidd has quit [Remote host closed the connection]
rhyskidd has joined #panfrost
rhyskidd has quit [Remote host closed the connection]
davidlt has joined #panfrost
vstehle has quit [Ping timeout: 258 seconds]
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #panfrost
icecream95 has joined #panfrost
icecrea105 has joined #panfrost
vstehle has joined #panfrost
icecream95 has quit [Ping timeout: 264 seconds]
macc24 has joined #panfrost
fysa has quit [Ping timeout: 256 seconds]
icecrea105 has quit [Quit: leaving]
icecream95 has joined #panfrost
anarsoul|2 has quit [Ping timeout: 256 seconds]
anarsoul has joined #panfrost
guillaume_g has joined #panfrost
robmur01_ has joined #panfrost
robmur01 has quit [Ping timeout: 240 seconds]
raster has joined #panfrost
<tomeu> narmstrong: chewitt: can you remind me what's the mali_kbase that should work on the odroid n2?
<tomeu> thanks~
<tomeu> thanks!, even
<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
<l-as> what patch is this?
maccraft has quit [Quit: WeeChat 2.8]
ckeepax has joined #panfrost
<l-as> thanks!
<chewitt> tomeu with the patch added all GPUs start and reach "[drm] Initialized panfrost 1.1.0 20180908 for d00c0000.gpu on minor 1" with no errors
<chewitt> errors come afterwards
<tomeu> chewitt: yeah, but kbase seems to do fine without that
<l-as> chewitt: I assume this patch supersedes `drm/panfrost: add support for custom soft-reset on Amlogic GXM` ?
stikonas has quit [*.net *.split]
ckeepax has quit [*.net *.split]
TheKit has quit [*.net *.split]
nlhowell1 has quit [*.net *.split]
rtp_ has quit [*.net *.split]
gcl has quit [*.net *.split]
<chewitt> it's the same patch but also including the meson-g12-mali compatible
raster has quit [Quit: Gettin' stinky!]
<l-as> huh, thanks
ckeepax has joined #panfrost
TheKit has joined #panfrost
stikonas has joined #panfrost
nlhowell1 has joined #panfrost
rtp_ has joined #panfrost
gcl has joined #panfrost
<tomeu> robmur01_: robher: is there a branch somewhere collecting all panfrost patches?
raster has joined #panfrost
<robmur01_> tomeu: not that I'm aware of, beyond the ones that you and narmstrong were keeping a while back
icecream95 has quit [Ping timeout: 260 seconds]
robmur01_ is now known as robmur01
<tomeu> robmur01: ok, thanks
<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]
nlhowell1 has joined #panfrost
gtucker has joined #panfrost
stikonas_ has joined #panfrost
stikonas has quit [Ping timeout: 240 seconds]
nlhowell1 has quit [Ping timeout: 256 seconds]
<daniels> chewitt, robmur01: I find this more friendly FWIW
nlhowell1 has joined #panfrost
Ntemis has joined #panfrost
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?
<alyssa> isn't H970 bifrost?
<mchehab> [ 3.475015] panfrost e82c0000.gpu: clock rate = 550000000
<mchehab> [ 3.636768] panfrost e82c0000.gpu: mali-g72 id 0x6221 major 0x0 minor 0x0 status 0x1
<mchehab> [ 3.662139] panfrost e82c0000.gpu: Features: L2:0x07130206 Shader:0x00000000 Tiler:0x00000809 Mem:0x101 MMU:0x00002830 AS:0xff JS:0x7
<mchehab> [ 3.681561] panfrost e82c0000.gpu: shader_present=0xfff l2_present=0x1
<mchehab> [ 3.694680] [drm] Initialized panfrost 1.1.0 20180908 for e82c0000.gpu on minor 0
<mchehab> [ 3.645063] panfrost e82c0000.gpu: features: 00000000,13de77ff, issues: 00000000,00000400
<alyssa> G72/X isn't supported yet
<mchehab> does it work with Wayland?
<alyssa> haven't tried
<alyssa> so a firm maybe
<mchehab> tomeu: both drivers were built with "Y"
<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
<narmstrong> tomeu: on our android kernel (with kbase integrated)
<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.
<alyssa> 7 files changed, 66 insertions(+), 195 deletions(-)
<alyssa> So no complaints here I think
<alyssa> bbrezillon: Annoyingly, drmSyncobjWait itself is eating up a lot of cpu time
<alyssa> like, even when it's only called when strictly necessary in panfrost_fence_finish
remexre has quit [Read error: Connection reset by peer]
<alyssa> drm_syncobj_wait_ioctl is not a speed demon
remexre has joined #panfrost
davidlt has quit [Ping timeout: 264 seconds]
stikonas has joined #panfrost
TheMojoMan has joined #panfrost
TheMojoMan has quit [Ping timeout: 240 seconds]
buzzmarshall has joined #panfrost
raster has quit [Quit: Gettin' stinky!]
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
raster has joined #panfrost
karolherbst has quit [Quit: duh 🐧]
karolherbst has joined #panfrost
cwabbott_ has joined #panfrost
cwabbott has quit [Ping timeout: 260 seconds]
cwabbott_ is now known as cwabbott
raster has quit [Quit: Gettin' stinky!]
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost