austriancoder changed the topic of #etnaviv to: #etnaviv - the home of the reverse-engineered Vivante GPU driver - Logs https://freenode.irclog.whitequark.org/etnaviv
tlwoerner has joined #etnaviv
flto has quit [Quit: Leaving]
flto has joined #etnaviv
dv_ has quit [Quit: WeeChat 2.8]
dv_ has joined #etnaviv
<DPA> lynxeye: It's still incomplete, but doing a flush_resource there does indeed seam to fix my problem: https://gitlab.freedesktop.org/DPA/mesa/-/commit/e15277985e8b441e3965051cbe6784c0a85f3e47
<DPA> Is there some way to check how much bandwith this is using up?
<austriancoder> DPA: there are some bandwidth perfmon counters but they are not yet available
<DPA> Ok, thanks.
lynxeye has joined #etnaviv
berton has joined #etnaviv
berton has quit [Remote host closed the connection]
berton has joined #etnaviv
_whitelogger has joined #etnaviv
<cphealy> DPA: regarding your question about how much bandwidth this is using, austriancoder's method is a good one for knowing the amount of bandwidth used by the 3D GPU per frame rendered. Another tool available for measuring bandwidth on the i.MX8M is the perf counters of the DRAM controller. Those have been available for some time now and will give you an instantaneous total read/write load. This could also be useful for testing
<cphealy> bandwidth deltas.
<cphealy> Here's how to get system wide DRAM bandwidth:
<cphealy> perf stat -a -e imx8_ddr0/cycles/,imx8_ddr0/read-cycles/,imx8_ddr0/write-cycles/ sleep 1
<cphealy> 801934278 imx8_ddr0/cycles/
<cphealy> Performance counter stats for 'system wide':
<cphealy> 2457849 imx8_ddr0/write-cycles/
<cphealy> 128195623 imx8_ddr0/read-cycles/
<cphealy> 1.002500561 seconds time elapsed
<cphealy> With the above output, one can derive the DRAM busy (or idle) percentage by dividing the cycles with the combination of read-cycles and write-cycles. So, in the above example, we can see that the DRAM interface was ~16% busy (or ~84% idle).
<DPA> Nice, thank you very much!
<cphealy> With the older i.MX6q and the newer i.MX8MP, the DRAM controller exposes counters on a per-AXI bus master basis which is more helpful. What austriancoder is referring to with the additional 2 3D GPU perf counters is really the best for your needs though.
lynxeye has quit [Quit: lynxeye]
mauz555 has joined #etnaviv
mauz555 has quit []
<marex> austriancoder: is LIBGL_ALWAYS_SOFTWARE=true supposed to affect kmscube too , even for non-debug build of mesa ?
mauz555 has joined #etnaviv
berton has quit [Remote host closed the connection]
pcercuei has joined #etnaviv
mauz555 has quit []
_whitelogger has joined #etnaviv