stikonas_ has quit [Remote host closed the connection]
<endrift>
alyssa: oh, what emu? Also I don't think I have any bifrost or midgard hardware soooooo
<endrift>
still waiting on the Pinebook Pro
BenG83 has quit [Ping timeout: 258 seconds]
BenG83 has joined #panfrost
BenG83 has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 268 seconds]
afaerber has quit [Quit: Leaving]
<HdkR>
Oh look, it's that endrift person
afaerber has joined #panfrost
afaerber has quit [Remote host closed the connection]
afaerber has joined #panfrost
chewitt has quit [Max SendQ exceeded]
chewitt has joined #panfrost
Elpaulo1 has joined #panfrost
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo1 is now known as Elpaulo
_whitelogger has joined #panfrost
chewitt has quit [Quit: Adios!]
hlmjr has quit [Remote host closed the connection]
hlmjr has joined #panfrost
vstehle has joined #panfrost
BenG83 has joined #panfrost
pH5 has joined #panfrost
<narmstrong>
endrift: it must have been a very long time ago... the C2 is stable for a few years now, but honestly this board is very badly designed
<endrift>
I haven't ever actually used it
stikonas_ has joined #panfrost
andrii82 has joined #panfrost
stikonas_ has quit [Remote host closed the connection]
<tomeu>
endrift: we mostly just scratch our itches and try not to break stuff in the meantime
<tomeu>
endrift: it's very possible that when you try to run your favorite GL-using program, you will find problems that need to be fixed
<tomeu>
alyssa: what's your availability for fixing the dEQP-GLES2.functional.fragment_ops.blend.* regressions on rk3288??
<tomeu>
they pass in rk3399
<tomeu>
alyssa: anyway, I think we could consider for the time being only the RK3399 as the authoritative results for CI
<tomeu>
and we can fix RK3288 on a best effort basis
<tomeu>
just so we have a functional CI in the meantime
BenG83 has quit [Ping timeout: 276 seconds]
<narmstrong>
tomeu: I haven't got time to properly review the `drm/panfrost: Select devfreq` from ezequielg, but it effectively fails to probe on the Amlogic S912 socs
<ezequielg>
yeah, it fails on rk3288-rock2 as well (ouch).
<ezequielg>
wasn't expecting that, tbh.
<narmstrong>
`select PM_DEVFREQ` is ok, but leaving the otional code path is better
<ezequielg>
well, the v1 was improving the optional path.
<tomeu>
yeah, guess that would be the best that can be done in this case
<narmstrong>
ezequielg: I have a patch ready to revert the optional code, is it ok, or you want to deal with it ?
<ezequielg>
sorry, revert the optional code? enoparse :-)
marex-cloud has quit [Ping timeout: 264 seconds]
lvrp16_ has joined #panfrost
endrift has quit [Ping timeout: 258 seconds]
HdkR has quit [Ping timeout: 244 seconds]
<narmstrong>
ezequielg: revert back the optional code :-)
<ezequielg>
i am under the impression the v1 patch would work here.
lvrp16 has quit [Ping timeout: 252 seconds]
travankor has quit [Ping timeout: 252 seconds]
lvrp16_ is now known as lvrp16
<ezequielg>
so, on these platforms we don't want devfreq? tomeu ?
travankor has joined #panfrost
<tomeu>
ezequielg: well, if we don't have operating points...
<narmstrong>
I'm ok with tomeu to enforce PM_DEVFREQ to be selected
<tomeu>
we would like devfreq everywhere and definitely don't want to support building without devfreq
<narmstrong>
We don't have OPPs yet, but it's a goal to have them at some point
<tomeu>
but if the bindings say that the operating points are optional, then we cannot rely on that
<ezequielg>
in that case, instead of reverting maybe there is a way to deal with this and e.g. warn the user?
<ezequielg>
given it's something we don't want to support?
<narmstrong>
no since it's allowed to not have OPPs
<tomeu>
I think we want: 1. to select DEVFREQ, 2. to be able to run without devrfeq if there's no opps, 3. to warn the user if we do so
<tomeu>
ezequielg: we don't want to support building without devreq, but looks like we must support running without it
adjtm_ has quit [Ping timeout: 245 seconds]
<narmstrong>
warn is too much, I don't think it's mandatory from ARM to have a non-glitch changeable clock for the GPU power domain
<tomeu>
but f we leave the GPU running at 100% all the time, the thermal budget is decreases quite a bit
<narmstrong>
for laptops
<tomeu>
the nanopc I have here for example, just shuts off once I compile something with more than one core
<tomeu>
and has a quite big heatsink
<narmstrong>
tomeu: it's part of the implementation, you can't enforce it
<narmstrong>
amlogic socs runs fine with the GPU at max clock and no DVFS
<narmstrong>
anyway, for now it's a regression since it break the DT bindings
<tomeu>
narmstrong: aren't the CPUs being throttled all the time?
<narmstrong>
tomeu: nop
<tomeu>
sure, we are discussing only the warning part of it
* tomeu
hopes ezequielg has some time for this :)
<narmstrong>
tomeu: we can run with cpus + gpus at max freq without thermal issues
<tomeu>
ok, that's cool
<tomeu>
guess info would be considered clutter in those cases?
<tomeu>
in some cases it could be information interesting to the user, but not always
<narmstrong>
I mean, it's part of the system description, if the SoC can't have the GPU at max freq all the time, they need to add the OPPs, but you can't make it mandatory, but you can et we need to enforce PM_DEVFREQ, it's different
<narmstrong>
multi-SoCs IPs is a pain to support !
<tomeu>
yeah, I'm thinking of CI here, because at this point the number of hands is really tiny compared with the variety of hw our code could run on
<tomeu>
narmstrong: do you have panfrost-capable boards in your lava lab, btw?
<tomeu>
I'm thinking of adding the panfrost igt tests to kernelci, they would have caught this
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
cwabbott has quit [Client Quit]
cwabbott has joined #panfrost
<ezequielg>
tomeu: narmstrong: i have some time next week for this.
<ezequielg>
this works? would you rather just submit a revert now?
<tomeu>
ezequielg: narmstrong has submitted already a patch that restores the optional code paths
<ezequielg>
cool.
<tomeu>
could you review, please?
<narmstrong>
tomeu: Khadas gave use 4x VIM2 board to run panfrost testing, but we lacked time to put it in our lab
<narmstrong>
tomeu: I'd be very interested to also have igt and deqp ran on our lab
<ezequielg>
done
<alyssa>
tomeu: I have RK3288 hardware, but it's not in useable dev shape right now (needs a new kernel, etc). So I'm able to look into it but it's a bit of time investment first :)
<alyssa>
Still figuring out scheduling
jeez_ has joined #panfrost
mmind00 has quit [Quit: No Ping reply in 180 seconds.]
mmind00 has joined #panfrost
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #panfrost
adjtm has joined #panfrost
jeez_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pH5 has quit [Quit: bye]
chewitt has joined #panfrost
endrift has joined #panfrost
stikonas has joined #panfrost
pH5 has joined #panfrost
cwabbott has quit [Quit: cwabbott]
cwabbott has joined #panfrost
cwabbott has quit [Client Quit]
cwabbott has joined #panfrost
marex-cloud has joined #panfrost
_whitelogger has joined #panfrost
pH5 has quit [Quit: -_-]
<ezequielg>
fwiw, i will look at this on monday - i'm working on the rk3288 vpu anyway, so it's not at all a bother.
<alyssa>
ezequielg: You sure? The stuff that regressed is (afaik) deep into obscure parts of the compiler ;)
<Lyude>
bugs are always a good way to learn!
<Lyude>
i started with driver bugs myself
<anarsoul>
*sigh*
<Lyude>
?
<anarsoul>
too many bugs may provoke NIH syndrome, so be careful
<Lyude>
ah, that is true
<ezequielg>
lol - i was just talking about the devfreq thing.