ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel has landed in mainline, userspace driver is part of mesa - Logs at https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=lima and https://freenode.irclog.whitequark.org/lima - Contact ARM for binary driver support!
<anarsoul> it all depends on gpu and memory frequency
<linkmauve> Due to the CPU?
<linkmauve> Oh, I see.
<anarsoul> mostly due to memory :)
<linkmauve> That makes sense, IIRC these boards were severely bandwidth-limited when doing 1080p60.
<anarsoul> also it seems to have only 16-bit dram bus width
<linkmauve> MESA-LOADER: failed to open sun4i-drm (search paths /usr/lib/dri)
<linkmauve> failed to load driver: sun4i-drm
<linkmauve> anarsoul, did I miscompile Mesa?
<linkmauve> I only enabled the lima gallium driver.
<linkmauve> I do get a /usr/lib/dri/lima_dri.so
<linkmauve> Ah, missing kmsro apparently.
<linkmauve> anarsoul, no, I get the same issue on master in kmscube.
<anarsoul> linkmauve: anything in dmesg?
<anarsoul> also how much CMA did you allocate?
<linkmauve> The top vertex of the cube seems to want to be lower every other frame, the rest of the vertices are placed correctly.
<linkmauve> Absolutely nothing in dmesg, do you want a specific value in /sys/module/drm/parameters/debug?
<linkmauve> No idea what CMA even is, how can I check?
<linkmauve> [ 0.000000] Reserved memory: created CMA memory pool at 0x4a000000, size 96 MiB
<anarsoul> linkmauve: well, maybe that's some errata for older mali400 that's not handled in lima
<linkmauve> Ah, quite possible.
<linkmauve> [ 29.975693] lima 1c40000.gpu: gp - mali400 version major 1 minor 1
<linkmauve> [ 30.072357] lima 1c40000.gpu: pp0 - mali400 version major 1 minor 1
<linkmauve> Meh, ARM removed their resources at http://infocenter.arm.com/help/topic/com.arm.doc.set.graphics/
<linkmauve> Where do you get your errata docs?
<anarsoul> linkmauve: there's no public errata for mali
dllud has quit [Ping timeout: 264 seconds]
dllud has joined #lima
dllud_ has joined #lima
dllud has quit [Quit: ZNC 1.7.4 - https://znc.in]
dllud_ has quit [Read error: Connection reset by peer]
dllud has joined #lima
dllud has quit [Remote host closed the connection]
dllud has joined #lima
dllud has quit [Read error: Connection reset by peer]
dllud has joined #lima
dllud has quit [Read error: Connection reset by peer]
dllud has joined #lima
dllud has quit [Read error: Connection reset by peer]
dllud has joined #lima
dllud has quit [Ping timeout: 256 seconds]
dllud has joined #lima
dllud has quit [Read error: Connection reset by peer]
dllud has joined #lima
dllud has quit [Ping timeout: 260 seconds]
dllud has joined #lima
dllud has quit [Read error: Connection reset by peer]
dllud has joined #lima
<linkmauve> :(
<linkmauve> I’ll open an issue anyway, so that this bug can be tracked.
yann has quit [Ping timeout: 260 seconds]
yann has joined #lima
kaspter has joined #lima
yann has quit [Remote host closed the connection]
yann has joined #lima
<marex> anarsoul: hey, there was one thing I was pondering about, if I use the mali400 to sample linear buffer (not pre-tiled), is there some performance impact / memory bandwidth impact ?
<marex> anarsoul: I guess the tiling is useful when the shader core needs to do access to neighboring texels ?
kaspter has quit [Quit: kaspter]
dllud has quit [Read error: Connection reset by peer]
dllud has joined #lima
<anarsoul> marex: yes, linear is slower (likely due to worse cache hit rate)
<anarsoul> marex: note that it's tiling GPU
<anarsoul> so it renders into 16x16 tile buffer before doing write out
<anarsoul> GPU has L2 cache, size depends on implementation
<anarsoul> marex: btw your low pass rate deqp result with mali was likely due to wrong visual. You have to specify depth buffer explicitly
<anarsoul> *with lima
dllud has quit [Ping timeout: 258 seconds]
dllud has joined #lima
<marex> anarsoul: ah, thanks
_whitelogger has joined #lima
Elpaulo has joined #lima
Ntemis has joined #lima