03:44 <marex> austriancoder: mntmn: https://gitlab.freedesktop.org/marex/mesa/-/commits/stm32-texcoord-v3 I pushed updated pointcoord stuff here , it now uses nir_lower_texcoord_replace for NIR

03:44 <marex> neverball stars work, so does eglretrace pointcoord.trace

11:37 <agx_> Did someone already look at the etnaviv side of imx8mq DEC400D support?

12:29 <austriancoder> agx_: I think flto did some work on this but maybe cphealy knows the best

12:44 <flto> there wasm

12:44 <flto> there wasn't a modifier to expose it with when I worked on it, but etnaviv already uses it internally

12:45 <flto> lynxeye should have a patch to add the missing parts

15:41 <austriancoder> marex: I added some comments to your v3

15:45 <marex> austriancoder: thanks

15:46 <marex> austriancoder: there was some discussion in dri-devel, alyssa/kusma mentioned that just dropping the PIPE_CAP_POINT_SPRITE didnt work well and I ran into trouble with that too

15:46 <marex> austriancoder: also, I still need that for the TGSI part

15:46 <marex> ... or does the ST magically optimize the TGSI part too then ?

17:44 <agx_> flto: thanks - lynxeye is that code around somewhere? Would be keen to check if it makes 4K@60Hz DCSS plug mxsfb 720x1440 workable.

17:53 <austriancoder> marex: nowadays the path is: glsl -> nir ->tgsi (if tgsi is preferred) so yes it does magically optimize the TGSI part too

17:53 <marex> austriancoder: is there still any reason why the etnaviv tgsi is in place ?

17:53 <marex> austriancoder: btw this is fixed pipeline stuff, so no glsl, right ?

17:54 <austriancoder> marex: there are reasons and I am working on them.. there are regressions, crashes and miss optimizations

17:56 <marex> austriancoder: is there a list or somesuch ?

17:56 <austriancoder> no..

17:57 <austriancoder> I tackled almost all but upstreaming takes longer

17:59 <marex> austriancoder: how come ?

18:02 <austriancoder> marex: I need several rounds to get stuff in: good example is https://cgit.freedesktop.org/mesa/mesa/commit/?id=9b6516ac249ee479b78e399e1a54a293e53e9676 - I tried different other approaches until it was accepted. First I tried to patch core nir but that was not quite successful and it took some time to find the correct/best solution

18:05 <austriancoder> currently I am reworking/moving rect_tex lowering into st

18:11 <marex> austriancoder: I saw the patch :)

18:12 <marex> austriancoder: I think with the help in dri-devel, I might even be getting somewhere too

18:14 <austriancoder> marex: with your point sprit work?

18:16 <marex> yes

20:09 <marex> austriancoder: util_varying_is_point_coord is nice

20:09 <marex> austriancoder: I updated the v3 branch and addressed your feedback, I hope, but see https://gitlab.freedesktop.org/marex/mesa/-/commit/a87cc1d45498a865c91d8362e0a7fa610fc20ad6#c7cb3abafce1f6875bc8b14e9567930bdc201802_1242_1249

20:10 <marex> I have no idea how to eliminate the glTexCoord while keeping the glPointCoord in the compiled NIR shader

21:17 <cphealy> agx: I don't have any comment on the state of DEC400 patches for upstream. I've worked with various stacks that do have DEC400 enabled and can state that this does help with the 4K60 DCSS use case. For a demo I was working with, it was possible to hit 4K60 rendering (though this was with the GPU overclocked to 1GHz from 800MHz and a pretty optimal 2D GUI with embedded video.)

21:19 <cphealy> Due to the architecture of DEC400 compression (like with other vendor frame buffer compression algorithms, if you have tiles that are solid color, the compression ratio can be very efficient, like instead of any pixel data being transferred for a tile from DRAM to the display controller, it can be completely skipped and just the small amount of tile metadata shared between DRAM and display controller.