ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
<anarsoul> adjtm: I checked glxinfo output and it reports that GL_OES_texture_border_clamp is supported :)
<anarsoul> OES_texture_3D is not there though
<anarsoul> nevermind, it's there as well
<anarsoul> (made typo in grep cmd)
<anarsoul> they're exposed regardless of whether they're supported, so yeah, it may fix something for android
mripard has quit [Ping timeout: 480 seconds]
mripard has joined #lima
adjtm has quit [Quit: Leaving]
adjtm has joined #lima
<rellla> anarsoul: i do it this way https://paste.centos.org/view/raw/ade5ea8d
anarsoul has quit [Ping timeout: 480 seconds]
anarsoul has joined #lima
dllud_ has quit [Read error: Connection reset by peer]
<rellla> anarsoul: i would say, this is a really good piglit result -> http://lima.imkreisrum.de/piglit/38c34bf..a5e50fc-lima-3d-texture/changes.html
dllud has joined #lima
adjtm has quit [Quit: Leaving]
dllud has quit [Remote host closed the connection]
dllud has joined #lima
adjtm has joined #lima
megi has quit [Remote host closed the connection]
megi has joined #lima
megi has quit [Quit: WeeChat 3.3]
megi has joined #lima
Danct12 has joined #lima
adjtm is now known as Guest2105
adjtm has joined #lima
Guest2105 has quit [Ping timeout: 480 seconds]
mmind00_ has joined #lima
mmind00 has quit [Ping timeout: 480 seconds]
mmind00_ has quit [Remote host closed the connection]
mmind00 has joined #lima
Biblical has joined #lima
drod has joined #lima
<tlwoerner> i'm investigating trying to increase the clock(?) rate of my mali450 gpu in the rock64
<tlwoerner> a while back someone mentioned i should add a gpu_opp_table to this device's DT
<anarsoul> yep, that was me
<tlwoerner> after doing so, https://paste.ee/p/IcEMC, my rates are still the same and now i'm getting https://paste.ee/p/H6ylB
<tlwoerner> running a build done today with the latest updates and using linus' kernel, glmark2-es2 is running much better (but it would still be nice to get the gpu rates up)
<anarsoul> [ 1.926011] lima ff300000.gpu: dev_pm_opp_set_regulators: no regulator (mali) found: -19
<tlwoerner> yes
<anarsoul> sounds like you need a regulator? :)
<tlwoerner> would that imply more tweaks to the DT?
<anarsoul> see rk3328-a1.dts for example
<anarsoul> it has mali-supply = <&vdd_logic>; in gpu node
<anarsoul> you need to check schematics to see what regulator supplies mali
<anarsoul> and add it to dts
<anarsoul> and I don't think that you need power domain
<tlwoerner> okay, i'll try without the power domain
<anarsoul> you still need a regulator :)
<anarsoul> btw, I'd appreciate if you share glmark2 results when you get it working
<anarsoul> i.e. before and after results
<tlwoerner> okay, and i can also run deqp things too
<anarsoul> it's unlikely that deqp run will be faster :)
sarbes has joined #lima
<tlwoerner> anarsoul: hmm, ended up with an OOPS: https://paste.ee/p/ZuQbz
<anarsoul> what regulator did you use? :)
<tlwoerner> vdd_logic (also referred to as VDD_LOG) https://files.pine64.org/doc/rock64/ROCK64_Schematic_v2.0_20171019.pdf
<tlwoerner> the only difference between rk3328-a1's vdd_logic and rk3328-rock64's is:
<tlwoerner> regulator-ramp-delay = <12500>;
<tlwoerner> (this line added to rock64's)
<tlwoerner> sadly the bus and mod rates are unchanged
<anarsoul> tlwoerner: I think it's not happy with downvolting it to whatever voltages you have in OPP
<anarsoul> you can try to get away without a regulator, just drop voltage from your opp table
<tlwoerner> those come from the vendor kernel
<tlwoerner> okay
Biblical has quit [autokilled: Client violated network policy - Contact support@oftc.net for help. (2021-10-07 19:35:10)]
agoldmints[m] has quit [Ping timeout: 480 seconds]
mvnetbiz[m] has quit [Ping timeout: 480 seconds]
apol[m] has quit [Ping timeout: 480 seconds]
icecream95 has quit [Ping timeout: 480 seconds]
<tlwoerner> if i just drop the opp-microvolt lines: lima ff300000.gpu: opp_parse_supplies: opp-microvolt missing although OPP managing regulators
<tlwoerner> if i additionally remove the regulator then i'm back to: lima ff300000.gpu: dev_pm_opp_set_regulators: no regulator (mali) found: -19
<tlwoerner> or did you mean something else?
<anarsoul> I'll look into it later tonight
<tlwoerner> awesome thanks! :-)
<tlwoerner> let me know if you need anything
<anarsoul> tlwoerner: I think you need to remove both opp-microvolt and regulator
<anarsoul> that's what sun8i-h3.dtsi has
<tlwoerner> this diff (no regulator, no microvolt): https://paste.ee/p/wM1IZ
<tlwoerner> gives: https://paste.ee/p/4tdcs
<xdarklight> tlwoerner: also I suggest checking whether VDD_LOG is shared with other IP cores within the SoC. Amlogic SoCs for example use a so-called VDDEE supply which is not exclusive to the GPU but shared with other IPs (video encoders/decoders, HDMI transmitter, ISP, ...). that's why on Amlogic we use the same voltage for all frequencies. if we used different voltages the whole SoC could become unstable
<anarsoul> yeah, you can also grab what's the voltage for it in working state
<anarsoul> it should be in /sys/kernel/debug/regulator/regulator_summary
<anarsoul> and use it in opp
<tlwoerner> for all frequencies?
<xdarklight> tlwoerner: also I just double-checked the code: the "mali" regulator error which you're seeing is ignored here: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/lima/lima_devfreq.c#L125:L130 - and the cooling device error is ignored here: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/lima/lima_devfreq.c#L164:L168
<xdarklight> tlwoerner: devfreq should still work after you start putting some load on the GPU (at idle it'll just sit at it's lowest rate)
<tlwoerner> is there a way to change/set the rate? some sysfs entry?
<xdarklight> not that I'm aware of
<xdarklight> only reading is possible through /sys/kernel/debug/clk (clk_summary in that directory is handy because it shows the whole clock tree including rates and so on)
<anarsoul> tlwoerner: nope
<xdarklight> tlwoerner: if you forcefully want to change the clock rate to a fixed value (until devfreq changes the rate) you can do it from within the .dts, see https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/meson8.dtsi#L311:L312 (for experimenting this is fine, for "productive" usage I wouldn't recommend unless there's a specific reason, such as https://github.com/torvalds/linux/commit/44cf630bcb8c5ec78125805c9447dd5766792224)
<tlwoerner> an unmodified kernel gives: https://paste.ee/p/oFLSB
<anarsoul> so vdd_logic is 1.1V
<anarsoul> and you want opp-microvolt = <1100000>; for each frequency
<tlwoerner> ok
<tlwoerner> and i want the regulator too?
<tlwoerner> (pretty sure yes)
<anarsoul> sure, why not
<anarsoul> tlwoerner: does it work?
<tlwoerner> everything works, but the glmark2 score is the same. i'm trying the DTS trick to force the clock rate
<tlwoerner> i am running it fullscreen
<tlwoerner> i'm pretty sure glmark2 is smoother with the update
<tlwoerner> but that could be subjective
<anarsoul> tlwoerner: it's likely limited at 60fps
<anarsoul> try weston and wayland version of glmark?
daniels has quit [Ping timeout: 480 seconds]
narmstrong has quit [Ping timeout: 480 seconds]
cwabbott has quit [Ping timeout: 480 seconds]
<anarsoul> tlwoerner: I tried a quick hack from xdarklight to set freq to 500mhz on my rock64 and I get:
<anarsoul> glmark2 Score: 86 for default freq
<anarsoul> glmark2 Score: 272 for 500MHz
jstultz has quit [Ping timeout: 480 seconds]
<anarsoul> and 2-3x FPS boost in most of benchmarks
robher has quit [Ping timeout: 480 seconds]
daniels has joined #lima
narmstrong has joined #lima
jstultz has joined #lima
cwabbott has joined #lima
robher has joined #lima
<tlwoerner> okay, i can switch to wayland/weston (i'll have to start a new build)
<tlwoerner> i know everyone's going to roll their eyes, but i like that i can run gui things from the console
<tlwoerner> running glmark2 fullscreen was definitely pinning the output at 60fps, running without fullscreen gives me a score of 105
<tlwoerner> i thought you didn't have a rock64, you were doing all your testing with an amlogic board (?)
<tlwoerner> by the way, setting the clock to its highest setting gives: lima ff300000.gpu: mod rate = 491520000
<anarsoul> tlwoerner: our CI only uses amlogic boards
<anarsoul> personally, I have pine64, rock64 and rockpro64
<anarsoul> I mostly focus on allwinner devices though (pine64, pinebook)
<anarsoul> and I don't do any kernel development for rk3328
<tlwoerner> what other tests do you recommend?
<anarsoul> well, whatever you planning to use on this board
<tlwoerner> me personally? nothing. i'm just interested in maintaining a rockchip bsp, testing, and seeing all boards perform well :-)
<xdarklight> tlwoerner: I suggest running something that loads up the GPU for some time and monitoring the thermals. on Amlogic SoCs the GPU has a much bigger impact on thermals (with the CPU alone I can't make my Odroid-C1 reach 70°C, but by loading the GPU this is easy to reach). that's one of the reasons why fixed clocks are a bad thing
<tlwoerner> an unmodifed kernel running glmark2-es2 on x11 (without fullscreen) gives me a glmark2 score of: 61
<xdarklight> "lima ff300000.gpu: Failed to register cooling device" means the GPU will not clock down when the SoC temperature goes up - so keep monitoring the temps!
<tlwoerner> same test with the tweaked kernel with the opp table and forced to the highest freq gives a glmark2 score of 105
sarbes has quit []
<anarsoul> xdarklight: I guess it needs gpu in thermal-zone description?
<anarsoul> xdarklight: great, thanks!
<anarsoul> I guess I need to add it to A64 dts
<anarsoul> however it has 3 thermal sensors, 1 for CPU, 2 for GPU
<xdarklight> anarsoul: newer Amlogic SoCs have a thermal sensor called "ddr" which (from my understanding) is physically close to the GPU. that's why we use: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi#L189:L214
<xdarklight> not sure how to use two thermal sensors for the GPU though, but I'm sure that the linux-thermal people are able to give some hints there
<anarsoul> xdarklight: thanks!
drod has quit [Remote host closed the connection]
<tlwoerner> i don't know if this is just a coincidence, but i've tried this 2-3 times each
<tlwoerner> with no modifications glmark2 score = 41 and system is stable
<tlwoerner> if i just add the opp table glmark2 score = 103 and system is stable
<tlwoerner> if i add the opp table and the regulator the system is unstable and crashes before glmark2 can complete
<tlwoerner> if i add the opp table, the regulators, and force the clock to 491520000 glmark2 score = 105 and the system is stable again
<anarsoul> mmind00: ^^ any ideas what could be wrong?
<mmind00> hmm, maybe some (missing) stabilization time for the regulator?
<mmind00> aka new (higher) voltage not stable when the gpu starts running at the new higher speed?
<mmind00> tlwoerner: can you check what happens when you set your opp-table entries to the voltage value of the fastest entry?
<mmind00> alternatively ... some voltages in the opp table could simply be too low for the board
<tlwoerner> mmind00: all voltages are set to the same value, namely 1100000
<tlwoerner> explicitly setting the speed to the highest value is stable
<tlwoerner> what's not stable is defining the opp table and adding the regulator
<anarsoul> I'd suggest to check regulator_summary in debugfs if you can get to this point