ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
<anarsoul>
we call PP0_SUBPIXEL_SPECIFIER dubya in lima, it's value is always 0x77
<anarsoul>
and PP0_ORIGIN_OFFSET_Y seems to be unused_2 in lima
<anarsoul>
so we don't have 2 regs that are called "one" and "supersampled_height"
<anarsoul>
so if documentation is correct I've no idea how lima may work on zynqmp
<anarsoul>
OK, I think dEQP-GLES2.functional.multisample.stencil fails because we have reload in the middle :)
<anarsoul>
so msaa state is lost
<enunes>
anarsoul: I remember hitting the GL_MAX_SAMPLES GL_INVALID_ENUM thing when looking at the multisample implementation
<enunes>
anarsoul: I came up with this patch for it back then https://paste.centos.org/view/raw/d39472c3 , should I send a separate MR for it or should we integrate it with yours?
<anarsoul>
you can send it as a separate MR
<enunes>
if you just force 3.0 with MESA_GLES_VERSION_OVERRIDE it also works, for debugging purposes
<anarsoul>
let me try that...
<anarsoul>
yeah, it works with MESA_GLES_VERSION_OVERRIDE=3.0
<marex>
anarsoul: uh ... it works rather well on zynqmp
<anarsoul>
marex: then doc is incorrect
<marex>
anarsoul: I need one clock patch for the kernel which was rejected because xilinx didn't provide any helpful feedback on the clock topology, so I carry it downstream
<marex>
anarsoul: I can report that to xilinx if you want
<anarsoul>
marex: up to you :)
<anarsoul>
oh, looks like reload for multisample is more complex for stencil
<anarsoul>
blob does 4 draws instead of 1, one for each sample
<anarsoul>
and it iterates over sample
<anarsoul>
s/sample/sample_mask
<anarsoul>
enunes: rellla: I just noticed that vertex selector for reload job is points
<anarsoul>
so looks like it uses point sprites for reload
<anarsoul>
(that's in case if anyone is looking into implementing point sprites)
<marex>
anarsoul: give me a minute, NMI, I will be back in say 30 minutes
<anarsoul>
oh, and it uses 4 different textures for reload :\
<anarsoul>
hehe
<anarsoul>
turns out MSAA 4x is not that free if you need to preserve depth/stencil buffer
<anarsoul>
it needs 4x size of depth/stencil buffer
<anarsoul>
OK, I think our lima_pp_wb_reg definition is incorrect
<anarsoul>
zero should be named flags and should go before mrt_bits
<anarsoul>
in this case wb_reg definition matches zynqmp docs, however pp_reg still lacks 2 regs
<anarsoul>
so for MSAA blobs enables 4 MRTs for depth/stencil buffer and allocates 4x buffer size
<anarsoul>
then for reload it reloads each MRT individually