<tomeu>
narmstrong: was meaning that the code that prints "error powering up gpu" probably shouldn't be executed at all, otherwise on each pm runtime wake up we need to wait quite some time just to realize it didn't work
<chewitt>
I have noticed that mesa/panfrost LE images boot a little slower than blob images
<chewitt>
kodi.target reached after 1.645s in userspace
<chewitt>
ahh, although not an entirely fair comparison as faster times are N2+ and slower is ye olde N2
<stollejocke>
chewitt, I will try your sources, too. The only thing I noticed are more problems with hdmi with superna9999 sources. Normally 1080p is quite stable, but with that kernel it has flickering.
<narmstrong>
stollejocke: which source ? my source is upstream mainline linux
afaerber has quit [Remote host closed the connection]
afaerber has joined #panfrost
<chewitt>
it's an experimental branch
<chewitt>
I saw deadlocks with the last two commits in that branch added to mine
<chewitt>
so, err, avoid :)
<stollejocke>
the odroid is just for testing panfrost, so no problem with hickups :)
<stepri01>
chewitt: Have you tried increasing the timeouts in the readl_relaxed_poll_timeout() calls - i.e. is it just slow, or is it really never reporting 'READY'?
<stepri01>
I'm surprised it works if the 'READY' bit is never getting set
<chewitt>
@stepri01 your incorrect assumption is that I have any idea about code :)
<chewitt>
i'm pretty competent at testing the patches of people who do have an idea
<stepri01>
:)
<stepri01>
try increasing the 1000 at the end, say 10000 to start with
<stepri01>
admittedly 10ms is a long time to be waiting
<stepri01>
kbase has a much more sophisicated approach, but ultimately you need to wait for the GPU to turn on in some manner
<chewitt>
an earlier invocation of readl_relaxed_poll_timeout also uses 10000
<chewitt>
in panfrost_gpu_soft_reset
<stepri01>
yeah - I'm not sure quite where the timeout numbers came from - TBH I would expect reset to be faster in most cases
<chewitt>
will respin the image and see what happens
<stepri01>
thanks
<chewitt>
I no longer get the "error powering up gpu L2" message
<chewitt>
I still see "error powering up gpu shader" .. but only 3x
<stepri01>
interesting
<chewitt>
whereas before it was spamming the journal constantly
<stepri01>
it's certainly an improvement then ;)
<chewitt>
indeed .. I shall update my HACK patch!
<chewitt>
combined with a dev_err > dev_warn_once should leave things clean
<tomeu>
oh, interesting
<tomeu>
so it ends up working...
<bbrezillon>
I have this timeout on shader core bringup too
<tomeu>
stepri01: guess kbase powers it up asyncly?
<tomeu>
then submits jobs when it comes up?
<bbrezillon>
but it seems to work fine
<stepri01>
yes kbase just waits (async) for the interrupt to say the core state has changed
<tomeu>
bbrezillon: guess once the shader cores are to be used, it is up by then
<stepri01>
it is possible to submit jobs before the shader cores are powered (at least on some GPUs) and the hardware will just wait for the cores to come up before trying to run the job
<stepri01>
I can't remember when we got that feature added though - I wouldn't trust it on T604 certainly ;)
<bbrezillon>
tomeu: maybe. I thought it was an amlogic-specific issue
<tomeu>
stepri01: ah, that's cool
<bbrezillon>
like CORE_READY bit never updated
<tomeu>
bbrezillon: but apparently it just takes a longer time?
<bbrezillon>
but maybe it's just that the timeout is too short
<tomeu>
maybe we shouldn't check for CORE_READY at all
<tomeu>
could get us first frames to render faster by a few ms
<stepri01>
ah, I remember now (been looking at the kbase source), all GPUs should support the "submit job while the core is powering up" case, but...
<bbrezillon>
chewitt: did you try to increase the timeout on shader-core readiness?
<stepri01>
...you can't start another transition while the first is happening
<stepri01>
so you need to ensure you e.g. don't try to turn off while the shader cores are still powering up
<stepri01>
The h/w feature that got added is BASE_HW_FEATURE_PWRON_DURING_PWROFF_TRANS
<stepri01>
i.e. you start start powering up again before a power down is complete (but only on some GPUs)
<chewitt>
bbrezillon see previous comment about me, patches, and code :)
<chewitt>
if you point me to the correct line and what value to modify/change-to .. I'm happy to test
<chewitt>
unless you mean the SHADER_PWRON_LO value .. I changed this to 10000 too
<tomeu>
stepri01: hmm, in which circumstances we would want to power down the GPU before all submitted jobs have finished?
<daniels>
tomeu: traces for rpm requests vs. completion would be nice?
<stepri01>
tomeu: I'm not sure if Panfrost does it or not. kbase has issues around performance counters - you can end up powering up/down the GPU because something wanted access to the counters but never actually submitted a job
<tomeu>
stollejocke: bifrost CI is still at its very beginning, is very possible that regressions have happened
<stepri01>
you can completely deadlock the GPU if you submit conflicting power requests
<tomeu>
ah, I see
<bbrezillon>
stepri01: oh
<bbrezillon>
tomeu: could it be something like that happening on the hangs we've seen on amlogic?
<stepri01>
SOFT_RESET implictly turns cores off, so if you've deadlocked the power control that fails and you have to fall back to a HARD_RESET. Panfrost doesn't have that fallback (yet)
<bbrezillon>
hm, actually it looked like CPU hangs, not GPU hangs
<bbrezillon>
nope, no support for HARD_RESET yet
<stepri01>
HARD_RESET isn't something you want to do - if it's done in the middle of a bus transaction you can lock up the bus
<stepri01>
of course turning the clocks/power off to the GPU block is equivalent to HARD_RESET, and we will do that ;)
<tomeu>
everything that kbase does but panfrost doesn't is a bug, right? :p
<stepri01>
you could always try increasing the timeouts higher - but I'm not sure how much sense that makes - it seems very odd if it's taking many milliseconds to power up
<stepri01>
but I don't think kbase actually has any timeout
<stepri01>
certainly kbase works with very slow models/FPGAs
<chewitt>
I'll have a play.. see if I can lose the gpu shader message
<chewitt>
it's gone with 20000
<stepri01>
cool - feel free to send a patch! ;)
<chewitt>
do I spend time trying to find a lower value? .. since this sounds like an arbitrary randomly-chosen value?
<stepri01>
well we don't want it too low (i.e. we need some headroom so it doesn't randomly fail occasionally)
<chewitt>
and .. same value for all three timeouts?
<chewitt>
L2/shader/tiler?
<stepri01>
since you've got a platform which demands the higher value then it makes sense to change it - it won't have any impact on other platforms
<chewitt>
I haven't seen the tiler message in testing
<stepri01>
you might as well go for the same value - I've no reason to believe they should be significantly different
<stepri01>
On most GPUs the tiler doesn't actually have any power control - so that one is just an enable/disable bit
<chewitt>
include the dev_err > dev_warn_once change?
<chewitt>
I guess not needed now
<stepri01>
I'm less keen on the warn_once change - if the GPU really fails to power up then we're going to be hitting timeout faults afterwards (which aren't rate limited)
<chewitt>
k
<narmstrong>
maybe we may power up all cores in sequence and wait /after/ for all cores to power up ? with this we may sleep less time ?
<stepri01>
there's certainly room for optimisation. In theory there's no need to separately do the L2 because powering up the shaders and/or tiler will automatically power up the L2
<stepri01>
there is a reason for the comment "Just turn on everything _for now_" ;)
<stepri01>
kbase has a complex state machine which keeps track of the desired state and submits power requests as they become possible to transition to that state
<stepri01>
chewitt: Looks good to me - I'd suggest droppping the "HACK" before posting ;)
<chewitt>
Yup, I need to rebase against drm-next too
<chewitt>
any suggestions on what might be missing for "[drm:panfrost_devfreq_init [panfrost]] Failed to register cooling device"
<stepri01>
it suggests there is something wrong with the devfreq description in device tree - but I'm not that familiar with how that stuff is meant to work
stikonas has quit [Remote host closed the connection]
stikonas has joined #panfrost
buzzmarshall has joined #panfrost
<chewitt>
which is the upstream repo/branch to submit the patch against?
<felipealmeida>
hi, does panfrost vulkan work in T720? It says in wikipedia that T720 doesn't have Vulkan support. But that T760 has it. If T720 doesn't, why? Does it lack some specific important feature or has some bug that stops it from possibly supporting vulkan?
<HdkR>
Panfrost isn't a Vulkan driver
<alyssa>
...yet
<felipealmeida>
mesa src/panfrost has a vulkan directory
<felipealmeida>
is it experimental?
<alyssa>
it does?
<felipealmeida>
at mesa from panfrost gitlab it does