<cphealy>
If you are doing 4K GUI and 4K video, I think your only option is to put the video in a HW plane so you can take advantage of video buffer compression.
<cphealy>
Also, of note, if you are using the upstream Hantro G2 stateless decoder driver, you will want to apply the patches that enable RFC (reference frame compression) as this will save DRAM bandwidth too. RFC does NOT require DCSS support as it's all internal to the video decoder.
Guest2456 has joined #etnaviv
Guest2456 has quit []
mvlad has joined #etnaviv
pcercuei has joined #etnaviv
<dv_>
cphealy: ah good point about RFC, I'll enable that
<dv_>
I think if I limit playback to 30 fps, I can use the GPU for 4K output
<dv_>
anything above that though, nope
<dv_>
doesn't matter what the bitrate of the incoming video is, the decoded data is just too big, too many pixels per second to push through
<dv_>
your approach with DCSS has the advantage of using DRAM with max efficiency, but the disadvantage of not being nearly as flexible as what you can do with QML compositing
<eery>
:q
<eery>
ah yes, the right way to detach a tmux session
<cphealy>
dv_: You can use this command to see how much DRAM bandwidth is being used in realtime and compare different use cases:
<cphealy>
perf stat -a -e imx8_ddr0/cycles/,imx8_ddr0/read-cycles/,imx8_ddr0/write-cycles/ -I 100 sleep 100
<cphealy>
Obviously you need the perf driver enabled in the kernel and the perf binary in userspace.
<cphealy>
In addition to the DRAM bandwidth counters, as long as you have a new enough kernel and Mesa, you can watch the GPU bus bandwidth counters in Mesa and see how many bytes are read and written per frame rendered. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7398
<eery>
sorry for the clueless question, but is there any way to change the GPU clock live, or can it only be set when loading the DTB/first init?
<cphealy>
I'm sure code could be written to change the GPU freq live, but today I don't believe there is a way with etnaviv to do this. devicetree is the available option ATM.
<cphealy>
At some point, devfreq support may be added with etnaviv. This could be done to allow changing the GPU freq, but this would only be within the list of available OPP which are typically defined in devicetree... ;-)
<eery>
ah, okay
<eery>
I've been playing around with an imx8mq, managed to clumsily adjust the clock (via the device tree) to pretty awesome effect, but it increases the power draw enough it'd be nice to be able to switch in software
<cphealy>
eery: did you increase the GPU clock to 1GHz?
<cphealy>
From my experience 1GHz is stable with i.MX8mq as long as you stay within the thermal limits.
<eery>
I tried 1.1GHz, just to be daring and rebellious :)
<eery>
will definitely give that patch a shot, I'm fascinated by how far this thing can be pushed
<eery>
I suppose testing it would be *a* way to contribute too, at least. I'd like to help out but am pretty lost at 1) computer graphics 2) low level hardware
<cphealy>
Out of curiosity, when you were pushing to 1.1GHz, what HW were you working with? Was it the i.MX8mq EVK from NXP or some other HW? Specifically, I'm curious what the cooling solution was.
<cphealy>
Also, you may find it useful to monitor the GPU temperature which should be exposed via a HWMON driver. "ls /sys/class/hwmon"
JohnnyonF has joined #etnaviv
<eery>
Running it on an MNT reform laptop, so a nitrogen board with a pretty hefty heatsink -- temperatures didn't seem to get much higher than before, to the point I doubted if I actually changed it, but it was drawing, uh, 2~ watts more power
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<cphealy>
Cool, I've got a MNT reform laptop too but have not tried this yeet.
<eery>
I had an imx6 quad cubox-i as a teen and remember trying to get the awful proprietary DRM driver and armada stuff working, it's so cool where etnaviv is now
<cphealy>
Good to know you successfully ran at 1.1GHz though. What would be nice is to have etnaviv work with devfreq and allow people to overclock via some special mechanism.
<cphealy>
Yea, etnaviv has come a long ways for sure! Rumor is that it's flying on commercial aircraft with seatback entertainment systems... ;-)
<eery>
haha
<eery>
Less commercially relevant, but I've gotten quite a few commercial games like minecraft and mount&blade running on the etnaviv stack with no problems, it's very impressive
<eery>
my highly non-technical observation is it seems to struggle the most with painting large areas/buffers, so running applications in smaller windows/resolutions affects performance more than polygon/texture sizes
<eery>
which from what I can tell, that PR seems to be aimed at?
<eery>
er, MR.. :)
<cphealy>
Yes, this MR has multiple benefits. It will reduce DRAM bandwidth at the very least, and as Lucas pointed out, in some cases it will result in significant framerate improvements. Basically, for anything where we have solid colors, the compression ratio is considerable as the whole tile will not be transferred as the tile metadata will include the color for the whole tile.
mvlad has quit [Remote host closed the connection]
pcercuei has quit [Quit: brb]
pcercuei has joined #etnaviv
pcercuei has quit [Quit: brb]
pcercuei has joined #etnaviv
pcercuei has quit []
pcercuei has joined #etnaviv
pcercuei has quit [Quit: brb]
pcercuei has joined #etnaviv
<eery>
okay, very interesting results -- same glxgears result as mentioned in the MR, getting the "No space left on device" messages on at least one SDL2/OpenGL/Wayland application (OpenMW), some apps really aren't happy (rofi), and bizarrely minecraft of all things ran smoothly, with a significant performance boost
<eery>
will dive into this more thoroughly when I have spair cycles to document properly :)
<cphealy>
eery: very nice feedback. If you get a chance, please share your findings in that MR and include your kernel and Mesa versions.