15:14 <lynxeye> austriancoder: Are you planning on working on full GLES3 support on GC2000? Reason I'm asking is that I suspect that there are some bugs in the halti0 ETC2 patch/unpatch code when the transfer doesn't update the whole miplevel, but all that code is dead for spec compliant apps until GC2000 exposes GLES3. Personally I feel like GC3000+ is a much more reasonable target for GLES3 and it would allow us to get rid of the ETC2 workaround

15:14 <lynxeye> , instead of sinking time into fixing the corner cases. What do you think?

15:24 <cphealy> GC2000 is emulating other GLES3 features as it's not GLES3 HW feature complete, right?

15:34 <lynxeye> cphealy: It's not black and white, but a spectrum. Only halti5 (mostly GC7000) added all the features to support GLES3 without any emulation, i.o.w. with minimal effort from the driver side. Lower halti versions require gradually more features emulated with halti0 aka GC2000 being the first one that has just enough features in hardware to support GLES3 with lots of emulation done on the driver side.

15:35 <cphealy> Ahh, so even GC3000 requires some level of emulation?

15:39 <pH5> I thought even GC7000 would require some amount of emulation, e.g. 32-bit float rgba renderbuffers? I only see 2-component 32f modes in rnndb.

15:39 <lynxeye> cphealy: Yep, afaik GC3000 can't do sRGB rendering and RG render targets, which are mandatory for GLES3.

15:43 <lynxeye> pH5: Right, those use 2 MRT slots. But for that one you could argue that the hardware is designed to work that way. At least you don't need to take an extra expensive path to implement them like using XRGB buffers to implement RG render targets.

15:43 <lynxeye> So depends on your definition of emulation. ;)

15:44 <cphealy> tnx for the detail @lynxeye

15:49 <lynxeye> pH5: Also, aren't 32bpc float rendertargets a gles 3.2 feature? For now I'm just concerned about base gles3.0.

17:14 <bl4ckb0ne> is there any doc (from constructor or reverse engineering) regarding flat/smooth shading ? I saw this https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/etnaviv/etnaviv_rasterizer.c?ref_type=heads#L48 but it doesn't looks like its used down the line

17:16 <austriancoder> bl4ckb0ne: register docs are here https://github.com/etnaviv/etna_viv/tree/master/rnndb what soc are you targeting?

17:17 <bl4ckb0ne> thanks

17:17 <bl4ckb0ne> GC7000 rev 6069

17:19 <austriancoder> bl4ckb0ne: I have some not yet pushed bits for rnndb for this topic

17:19 <bl4ckb0ne> anything interesting in for this case?

17:23 <austriancoder> yes .. interpolation modes ..

17:24 <bl4ckb0ne> huh neat

17:37 <austriancoder> dinner is calling but I can push the rnndb changes tomorrow

17:54 <bl4ckb0ne> sounds good, thanks

17:54 <bl4ckb0ne> anything i can do to help in the meantime?

17:57 <austriancoder> keep in mind that this are just the register definitions .. the driver (state emit, linker, ..) does not make use of it

17:57 <austriancoder> and flat/smooth shading is broken for etnaviv - I think - on all models

17:59 <bl4ckb0ne> thats what i understood while grepping the driver

18:00 <austriancoder> great

18:01 <austriancoder> a good starting point would be to fix this line: bool interpolate_always = true; - found in etnaviv_compiler_nir.c

18:03 <bl4ckb0ne> ill get on that, thanks