11:35 <ahartmetz> hello! do you guys have any hints about enabling (temporal, i assume) dithering? it's for an i.mx6 duallite - it seems that banding appeared after switching from vivante to etnaviv about 2 years ago.

11:36 <ahartmetz> the connected lcd only has 16 bit color depth

11:38 <ahartmetz> force-enabling would be fine since it's single hardware. probably easier than setting up detection.

11:59 <lynxeye> ahartmetz: etnaviv programs the hardware dither state according to the GL_DITHER, which is default enabled in a GL context. So if your application doesn't explicitly disable GL_DITHER this should work as expected.

12:02 <ahartmetz> lynxeye: will that enable temporal dithering? i figure that it must have been temporal dithering with vivante, but i might be wrong.

12:10 <ahartmetz> seems to me that, for GL_DITHER to be effective, the 24 or 32 bit -> 16 bit transition needs to be in the right place. let's say the framebuffer is 24 bits, then "dither color components or indices before they are written to the color buffer" (GL_DITHER docs) does nothing.

12:40 <lynxeye> ahartmetz: No, etnaviv doesn't (and can't do) any temporal dithering. That would require repainting the entire framebuffer, which the driver/hardware can not assume. The dithering is a static pattern dither.

12:42 <lynxeye> Sure, if you render to to a 24bpp framebuffer, the hardware isn't aware that you need any dithering. So if you display on does 16bit color it would make a lot of sense to render to a 16bpp framebuffer, which is also beneficial with regard to memory bandwidth both on the GPU and scanout side.

12:46 <ahartmetz> alright, thanks!

12:48 <ahartmetz> i'll see what i can do with this information. otherwise, the problem is mostly with one particular image for which it's easy enough to dither it in an image editor. dithering is just nice to have otherwise.