ChanServ changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://oftc.irclog.whitequark.org/etnaviv
JohnnyonFlame has joined #etnaviv
JohnnyonF has quit [Ping timeout: 480 seconds]
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #etnaviv
mvlad has joined #etnaviv
pcercuei has joined #etnaviv
Guest2377 has joined #etnaviv
Guest2377 has quit [Remote host closed the connection]
Guest2416 has joined #etnaviv
JohnnyonF has joined #etnaviv
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Guest2416 has quit []
JohnnyonF has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #etnaviv
JohnnyonFlame has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #etnaviv
<marex> seems like the gc600 in mx8mm is a bit on the slower side
<cphealy> increase the GPU freq? ;-)
<cphealy> GC7000 in i.MX8M supported running 20% faster than BSP number without issue so perhaps something similar can be done with the i.MX8MM.
<marex> cphealy: very different GPU in M and MM
<cphealy> agreed
<cphealy> That doesn't negate the possibility of being able to run the GPU at a higher clock though.
<marex> cphealy: can I run the GPU at 8 times its designated clock frequency or so ?
<pcercuei> < marex> seems like the gc600 in mx8mm is a bit on the slower side
<pcercuei> If it's like the GC680 in the ingenic SoC, the bottleneck is the memory bus speed
<pcercuei> If you reduce the state changes and draw calls as much as possible, you should gain some speed
<marex> so yes, the GPU is on the slower side
<cphealy> marex: not sure. If you get it to run at 8 times the designated clock frequency let me know as that would be quite impressive... ;-)
<dv_> on the imx8mq, the GPU seems to struggle with 4K30 content
<dv_> I wonder how much it would help to stick to tiled frames
<dv_> any idea how much of an impact the tiling makes?
<cphealy> dv_: what freq are you running the 3D GPU at? I was running the 3D GPU at 1GHz and was able to do a 4K60 UI with multiple 1080p video from the Hantro G1.
<cphealy> This was with DEC400 enabled between the 3D GPU and the DCSS though which saves a 30-70% DRAM bandwidth.
<cphealy> The most likely issue with 4K video through the 3D GPU is DRAM bandwidth. You may want to check DRAM bandwidth using the i.MX8M perf PMU driver.
<cphealy> Ideally, for 4K content, you want to do VP9 or HEVC with the Hantro G2 in the i.MX8mq and use the compressed format and scan it out in the 2nd or 3rd planes of the DCSS which supports this compressed format.
<dv_> no this is based on qt5
<dv_> so this uses video frames as part of a composite output that is controlled by a QML script
mvlad has quit [Remote host closed the connection]
<cphealy> dv_: ack That's a common problem as Qt5 doesn't support subsurfaces which would be needed to put video in HW plane when running on Wayland
<cphealy> dv_: are you driving a 4K display or just doing 4K video on lower resolution display?
<dv_> I'm using a 4K display
<dv_> hmm 4K30 can be processed well for the most part
<dv_> still, using the tiled formats helps conserve bandwidth
<dv_> question is, can gstreamer-gl handle those tiled formats
<cphealy> Look at the last commit here
<cphealy> What format are you using for 4K video? H.264? HEVC? VP8? VP9?
<dv_> heh, I was talking to ndufresne about this
<dv_> HEVC & VP9
pcercuei has quit [Quit: dodo]