08:00 <lynxeye> bl4ckb0ne: Flat shading did work on older GPU generations until 4e102a6de726 ("etnaviv: fix incorrect varying interpolation") did break it. I suspect that there are some generational differences somewhere in the halti range, which requires to handle those bits differently. I guess the commit fixed some things on GC7000, but broke older HW in the process.

08:02 <austriancoder> lynxeye: GC7000 uses a different register range with a different encoding .. this commit fixed it (maybe) for GC3000

08:04 <lynxeye> austriancoder: It probably "fixed" the u_blitter case by making sure none of the varying components are flat shaded. Which is fine for texture coordinates, etc. but breaks actual flat shading for the color varying.

08:05 <austriancoder> lynxeye: think so too.

08:06 <austriancoder> lynxeye: my road to gles3 is to start with GC7000 and work down to GC3000 and maybe GC2000. I would keep the the ect patching thing until it is really a showstopper/problem. Oh and it passed spec/!opengl es 3.0/oes_compressed_etc2_texture-miptree_gles3 tests when I added this patching.

08:09 <lynxeye> austriancoder: this test uploads complete miplevels, so it probably would not hit any issues. The thing that I suspect is broken is if you do a glTexSubImage to update parts of a miplevel.

08:11 <austriancoder> lynxeye: do you know off the top of your head a test that triggers this?

08:12 <lynxeye> I'm currently trying to untangle and clean up the transfer code and etc2 patching is one of the things where we do things differently to all other up-/downloads by doing the in-place patching. So if we want to keep it I need rework it to be more like the new way of caching transfers I image, which will take some time and the test coverage for this case is lacking.

08:13 <lynxeye> austriancoder: Nope, that's one of my issues with this special case: I don't know of any test exercising the corner cases, so I would either have to write some tests or accept that the untested corner cases are probably broken after my rework of the transfer code.

08:16 <lynxeye> austriancoder: It would make my life quite a bit easier if we can removing the code for now. I mean it isn't lost, as it's still in the git history and if we make our way down to gles3 support on GC2000, we can always revive it.

08:16 <austriancoder> lynxeye: in-place patching felt like the correct solution for the problem. I do not want to put work on your shoulders but .. hmm .. remove it and I will dig it out when I need it.

08:27 <lynxeye> austriancoder: thx. I'll try to keep it, but it may get in the way of my intended rework.

08:30 <lynxeye> I see how in-place patching looked like the right solution for the issue and it's probably quite okay from a performance standpoint, but it adds yet another path to the transfers. They are quite hard to reason about today, as there are so many paths depending on HW support and flags. I would like to try to cut down on the number of code paths there.

08:33 <pH5> lynxeye: you are right, I got this mixed up with desktop 3.0. on gles 3.0, rgba32f is not required at all, and gles 3.1 requires texture filtering only.

13:50 <bl4ckb0ne> intersting commit, thanks lynxeye

13:54 <lynxeye> bl4ckb0ne: Basically the PA flatshade state just sets the global flatshade enable and then there are other per-varying (component) bits that tell the interpolator if the varying is affected by the global flatshade setting

14:01 <bl4ckb0ne> so in this commit, it should take account of `interpolate_always` when doing pointcoord in the if statement?

14:13 <lynxeye> bl4ckb0ne: The pointcoord naming is probably a RE mistake. Those bits influence how the components are interpolated (at least on < halti5 hw) and should be set according to how the compiler specifies the varying interpolation. I guess those bits don't work this way on newer hardware, where you probably need the new halti5 interpolation bits mentioned by austriancoder.

14:38 <bl4ckb0ne> im a bit out of my depth on this issue but it sounds like a decent challenge

15:41 <bl4ckb0ne> the halti5 architecture is used in the GC7000L only or also in GC7000 ?

16:39 <austriancoder> bl4ckb0ne: https://github.com/etnaviv/etna_viv/commit/c3d81c93e887c639f0b56cf149d57ffe77239bcf

16:52 <bl4ckb0ne> thanks! ill take a look in detail after lunch

18:30 <lynxeye> bl4ckb0ne: Unfortunately VeriSilicon has renamed a lot of old cores to GC7000, so the name doesn't really tell anything. halti5 is a coarse architecture version, but there are also lots of individual feature bits that define what the specific GPU core can or cannot do. That's where the hwdb enters the picture.

18:31 <bl4ckb0ne> makes sense, i havent found a lot of information on the constructor's website