09:19 <mwalle> marex: is there any documentation about the pta/mtlb/stlb?

09:21 <austriancoder> mwalle: I think there should be some information: https://github.com/etnaviv/etna_viv/blob/master/rnndb/state_hi.xml

09:22 <mwalle> austriancoder: thnanks

09:23 <austriancoder> sravn: thanks... keep you up to date how our route from Sweden to Austria will look like :-)

09:47 <austriancoder> mwalle: or have a look at the vendor kernel GPU driver... I think there are some comments

09:50 <marex> austriancoder: indeed, I can highly recommend that

09:51 <marex> preferrably on empty stomach

09:51 <austriancoder> :-)

09:52 <marex> interestingly enough, the ... vendor driver ... uses 1 MiB pages

09:52 <marex> any reason why etnaviv uses 4k pages ? maybe its more efficient ?

09:56 <T_UNIX> hi

09:56 <mwalle> current status: if i start/stop/start glmark2 i (most of the time) get an SMMU fault. It seems that the GPU is trying to access an old stlb entry which is already unmapped when the first glmark2 process closed the device

09:57 <T_UNIX> since I didn't have any luck in getting a response in #linux-imx, maybe I'm more lucky here.

09:57 <T_UNIX> could anybody point me to more information about https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/etnaviv/etnaviv_gpu.c?id=b98c66887ee1aec661dcb88fe17399d5d112ed98 ?

09:58 <shoragan> T_UNIX, do you have such a gpu? which soc is that?

09:58 <marex> T_UNIX: there are some vivante cores which implement openvg

09:58 <T_UNIX> imx6q

09:59 <marex> since all the svg stuff is done on 3d gpu these days, there is not much use for those cores

09:59 <shoragan> etnaviv doesn't use the 2d-gpu at all

09:59 <T_UNIX> https://github.com/etnaviv/etna_viv/blob/master/doc/gpus_comparison.html

10:00 <shoragan> at least in mesa. the armada x11 driver has support for 2d blits, i think

10:02 <T_UNIX> https://github.com/qt/qtbase/blob/40143c189b7c1bf3c2058b77d00ea5c4e3be8b28/src/platformsupport/eglconvenience/qeglconvenience.cpp#L383

10:03 <marex> T_UNIX: isnt that openvg done using gles ?

10:04 <marex> shoragan: you could use the 2d gpu in mesa as YUV-to-RGB blit engine to avoid hammering the 3d gpu with that, but that needs extra patch

10:05 <T_UNIX> TBH I have no clue. All I can say is that the rendering (of svg containing UIs) appears to be fast on a dual lite, while it is quite slow on a quad.

10:06 <T_UNIX> so I figured, maybe the gpu is advertising it's "theoretical" Open VG skills, yet fails to initialize the core. Finally rendering stuff in SW instead of GL

10:06 <T_UNIX> * so I figured, maybe the gpu is advertising its "theoretical" Open VG skills, yet fails to initialize the core. Finally rendering stuff in SW instead of GL

10:11 <marex> nah, there is no openvg advertised by the GPU

10:11 <marex> fast on DL and slow on quad , hum

10:12 <marex> that is GC880 vs GC2000, right ?

10:12 <marex> same display configuration ? same DRAM configuration ?

10:13 <austriancoder> mwalle: sounds like the mmu context teardown needs to wait until the last cmd buffer of that context is done.

10:15 <T_UNIX> yes, GC880 vs. GC2000

10:15 <marex> mwalle: in my case it looks more like the STLB entry should be there, but from the GPU perspective it is not there

10:15 <marex> but in the devcoredump it already is there

10:15 <T_UNIX> I'll try to find a more specific benchmark that exposes the observed behaviour

10:15 <marex> so maybe the STLB gets refilled somehow ... incorrectly

10:42 <mwalle> austriancoder: it happens after the second glmark start, so i think there are no more cmd buffers pending (?)

10:58 <marex> mwalle: around those dma_alloc_wc page tables ?

10:58 <marex> mwalle: I was pondering about the same thing

10:58 <mwalle> marex: yep, the pta/mtlb/stlb entries

10:58 <marex> mwalle: or at least some barrier between STLB update (first) and then MTLB update (second)

11:00 <mwalle> i mean if the CPU write the mtlb entry, how is it ensured, that the GPU will see the updated value

11:00 <marex> mwalle: that

11:00 <mwalle> there must be a cache flush on the cpu side and a cache invalidation on the gpu side, no?

11:01 <marex> mwalle: the WC mapping is still cacheable, so there must be some sync, yes

11:01 <marex> or barrier

11:14 <mwalle> but inserting dma_sync_single_for_device() after the pte/mtlb/stlb is written by the CPU doesn't help either in my case

11:32 <austriancoder> mwalle: the mmu should have a flush bit - as I am not in front of a laptop I can not have a deeper look at the kernel driver where it gets used

12:29 <T_UNIX> <shoragan> "etnaviv doesn't use the 2d-gpu..." <- are you referring to https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/etnaviv/etnaviv_screen.c#L977 ?

12:30 <T_UNIX> i.e. only the 3d pipe is initialized by mesa?

12:30 <shoragan> T_UNIX, i think so

12:42 <mwalle> austriancoder: There is a VIVS_MMUv2_CONFIGURATION register, but it seems it is only accessed through command buffers which looked somewhat weird given that I wanted to flush the pages which also containes the command buffers

12:43 <mwalle> are the GPU registers accessible from both the command buffers and the CPU

13:03 <mwalle> marex: could you have a look at etnaviv_iommuv2_restore_nonsec()? it seems that this will set the mtlb base address, but it will only be set once (?), that is when VIVS_MMUv2_CONTROL_ENABLE is not set. I presume that bit will not be cleared ever again (just on a GPU reset?)

13:04 <mwalle> But on the other hand, the mtlb will be allocated when the device is opened and freed when the device is closed

16:24 <marex> mwalle: isnt the VIVS_MMUv2_CONFIGURATION supposed to be used for context switching (which includes MMU context) ?

16:25 <marex> mwalle: afaik the device can be opened multiple times though ?

16:25 <marex> mwalle: btw in my case, the problem happens after etnaviv_iommuv2_restore_nonsec() was called and the MMU bit was enabled already, so nothing was restored