08:48 <dv_> hey, I could use some suggestions. in a computer vision project, I am facing the problem that the AI engine that gets DMA buffers (with rendered content inside) delivered from the imx8m board via PCIe expects 24-bit BGR data.

08:48 <dv_> and, of course, vivante GPUs don't do 24-bit GBR.

08:49 <dv_> I think I could do RGBA -> BGR conversions in a pixel shader with a little bit of double texel fetching trickery. the bigger problem is the row size of a texture.

08:53 <dv_> so for example I let opengl think that this is an RGBA texture, but internally, in the pixel shader I write it as [RGBR] [GBRG] [BRGB] ... and ad the very end, there may be no room for one full RGB triplet

08:55 <dv_> one solution would be to create a 1-scanline texture. so, <total pixel amount> x 1. but can the vivante GPU even handle something like that? and if not, are there any vivante GPU specific tricks that could be done to achieve RGBA -> BGR ?

08:57 <dv_> oops, made a mistake. I meant a renderbuffer & EGLImage, not a texture. as said, the output goes as DMA buffer to the AI engine over PCIe. so, i create an FBO, attach a renderbuffer to it, and that renderbuffer uses an EGLimage, which in turn has a DMA-BUF FD as backing store.

08:57 <dv_> can I use a 1-scanline EGLimage like that?

08:58 <lynxeye> dv_: the BLT engine on the GC7000 should support packed RGB, so you could maybe do a blit from the render target to a RGB buffer. But I don't think there is any easy way to use this capability exposed, yet.

08:58 <dv_> is BLT exposed as G2D in vendor kernels?

08:59 <lynxeye> dv_: I don't think so. The BLT can't do all the composition ops that are exposed via G2D normally.

08:59 <dv_> hmm. and is BLT available on imx8m? I don't recall what GPU the imx8m has. I do know that G2D is not available on imx8m, only on imx8m mini.

09:28 <dv_> ah, it seems to be the GC7000 Lite

19:18 <Marex> flto: so this float_dynamic_vertex_read is broken on gc3000 too

19:21 <Marex> austriancoder: ^

19:25 <Marex> flto: and the binary_operator stuff too

19:38 <austriancoder> Marex: more details please

19:43 <Marex> austriancoder: run the gles2 deqp and you'll see it

19:43 <Marex> austriancoder: with mesa master

19:50 <austriancoder> k

19:58 <Marex> austriancoder: do you need the specific test which fails ?

19:58 <Marex> -n dEQP-GLES2.func*binary_oper* should fail

19:59 <Marex> and also s@binary_oper@float_dynamic_vertex_read@

20:17 <austriancoder> Marex: with tgsi the binary_ops stuff passes 100% - with nir I get the first assertion with dEQP-GLES2.functional.shaders.operator.binary_operator.div.lowp_int_vertex

20:18 <Marex> austriancoder: jupp

20:19 <Marex> austriancoder: it's been broken for a while

20:19 <Marex> austriancoder: on gc7000l too

20:21 <austriancoder> that might be one of the reasons that the nir compiler is not the default

20:26 <Marex> austriancoder: nir works on everything but gc3000/gc7000l though ? :)

20:32 <austriancoder> it works but has some rough edges

21:33 <Marex> mntmn: hey uh, I recall you had problems with glclear

21:46 <mntmn> Marex: yep

22:10 <Marex> mntmn: do you know any details ?

22:11 <Marex> mntmn: I am trying to debug another problem introduced by flto in 64c7cdcae51 ("etnaviv: add missing formats")

22:13 <flto> austriancoder, Marex: its supposed to pass all of dEQP-GLES2.functional.shader.* so its a regression somewhere

22:14 <Marex> flto: RGB10A2/RGB10X2 is not GLES2 format

22:14 <Marex> so of course it passes

22:14 <flto> talking about the deqp fails, not your RGB10A2/RGB10X2-related issue

22:16 <Marex> flto: oh right, that one crashes on binary_operations, which I think isn't in the functional.shader group

22:16 <mntmn> Marex: no, also i'm not sure if the glClear problem still exists. back when i had the problem, it would corrupt textures or something

22:17 <mntmn> Marex: so when just removing it, things would start to work (for example xwayland). but i believe there was also a fix for it in mesa

22:17 <mntmn> my memory is bad

22:36 <Marex> is it possible that the RGB10A2/RGB10X2 is completely broken on everthing ?

22:38 <Marex> sigh, GLES3 dEQPs for rgb10a2 keep crashing

22:41 <flto> Marex: it was working on GC3000 and GC7000L - I never ran GLES3 tests on GC2000

22:41 <Marex> flto: this fails on at least GC880 and GC3000

22:42 <flto> IIRC some of the GLES2 tests actually test RGB10A2 (available in GLES2 as an extension)

22:42 <Marex> flto: I literally have mesa/master on gc3000 here, now, and it fails

22:44 <flto> I haven't worked on etnaviv for 2 months now so I haven't tried it recently..

22:44 <Marex> it was broken ever since your patch though

22:44 <Marex> flto: that's how this issue was found, it was functionaly that was used and it suddenly didn't work

22:45 <Marex> flto: git bisect pointed that patch out

22:46 <flto> I understand the patch enabled the format and broke an application that started trying to use it. but GC3000/GC7000L should definitely be passing the tests for those formats, if the tests are not working then another patch broke it

22:46 <Marex> flto: which test tests those formats ?

22:49 <Marex> flto: it seems like if the RGB10A2 is source buffer for texture sampler, the result is just black frame ; the other way around, if it's destination, nothing is rendered

22:51 <flto> there should be same under functional.texture.*rgb10_a2* and functional.fbo.*rgb10_a2* (or maybe its not exactly rgb10_a2 but a different name)

22:52 <Marex> flto: yes, those are gles3