08:17 <marex> lynxeye: oh hey, any hint on debugging those MMU faults ?

08:22 <lynxeye> marex: grab the devcoredump when it happens and try to work backwards from the programmed states

08:22 <marex> lynxeye: er, details please ?

08:23 <lynxeye> marex: when the GPU hangs etnaviv produces a devcoredump of the GPU state and currently running job. This can be inspected for post-mortem analysis.

08:23 <marex> lynxeye: is that a file generated somewhere ?

08:23 <lynxeye> By default only the first hang produces a devcoredump. If you want more you need to re-arm the coredump module parameter.

08:24 <lynxeye> It's a dump in vmalloc memory, that's why it also disappears after a while. You can grab it by reading the file. Give me a sec to look up my scripts.

08:25 <marex> lynxeye: thanks

08:29 <lynxeye> marex: I have a udev rule in my system to trigger when a coredump shows up. This starts a small script to compress and store the devcoredump. https://paste.debian.net/1191642/

08:30 <lynxeye> Once you have the dump you can decode it with the tools in https://github.com/etnaviv/etna-gpu-tools

08:35 <marex> lynxeye: all right, let's enable that, thanks

08:38 <marex> lynxeye: how do you rearm the devcoredump for the next sample then ?

08:48 <austriancoder> marex: you got now the same answer in a week - just use etna-gpu-tools :)

09:18 <marex> austriancoder: the documentation for this could be better :)

10:19 <dv_> the hardwired YUV -> RGB CSC on viv GPUs does not allow for choosing particular color spaces, right?

10:19 <dv_> specifically the coefficients for BT.601 , BT.709 etc.

10:20 <dv_> although, I do recall someone saying that the conversion matrix _can_ be overwritten?

10:23 <lynxeye> dv_: At least we don't know how to configure the color space if it is at all possible.

10:25 <lynxeye> dv_: The 2D GPU has a bit to switch between 601 and 709, so there _might_ also be a bit in the 3D sampler to change this, but nobody RE'ed it.

10:26 <dv_> ah, but the 601 and 709 coefficients themselves are supported at least

10:26 <dv_> cphealy ^

10:27 <dv_> but wait - the 2D GPU, so the PixelEngine?

10:27 <lynxeye> dv_: No, 2D GPU as in GC320, the totally separate core on i.MX6

10:27 <dv_> the block that samples YUV data and stores it into a texture (that is - what's behing the VIV_direct_texture extension) is something entirely different, right?

10:28 <dv_> hm so that switch is not available on imx8 devices then

10:30 <lynxeye> dv_: There is no block to store YUV into textures. There is a YUV tiler, which allows to reorder planar YUV into interleaved YUV. The 3D GPU texture sampler then reads interleaved YUV and gives you RGB as shader input.

10:31 <lynxeye> There is a hardwired CSC in the texture sampler and based on the knowledge that the totally separate 2D GPU, which can also do YUV->RGB conversion has a bit to configure the color space I speculate that there might be something similar for the 3D GPU sampler.

10:31 <lynxeye> But that's nothing more than speculation.