GC7000L - comparison to GC3000

[Wladimir J. van der Laan]

On Tue, Oct 17, 2017 at 10:52:42AM +0200, Lucas Stach wrote:
> Hi Wladimir,
> 
> Am Montag, den 16.10.2017, 20:47 +0200 schrieb Wladimir J. van der Laan:
> 
> [...]
> > - Something strange seems to be the case with pixel shaders, I haven't
> >   investigated in detail yet but at least texture instructions are sometimes 
> >   duplicated:
> > 
> >    void main()
> >    {
> >        gl_FragColor = 3.0 * vVaryingColor * texture2D(in_texture, coord);\n"
> >    }
> > 
> > Gets assembled to:
> > 
> >    0: texld      t3, tex0, ?4?1.xyyy, void, void ; !bit_3_13=1!
> >    1: texld      t3, tex0, ?4?1.zwww, void, void ; !bit_3_24=1!
> >    2: mul        t1, u0.xxxx, t2, void   ; tex not used but fields non-zero (id=0,amode=5,swiz=0)
> >    3: mul        t1, t1, t3, void        ; tex not used but fields non-zero (id=0,amode=5,swiz=0)
> > 
> > Could it be that two invocations of the pixel shader are somehow combined into one shader?
> > It might be that this is only done for simple pixel shaders.
> 
> Could this be some strange way to drive the shader when only half
> precision aka FP16 is used and it's packing 2 pixel colors into a
> single output register?
> 
> Does the assembled shader change if you use the highp attribute in
> GLSL?

Yes, that was it, so that's what the dual16 stuff is about! with highp
fragment precision we simply get:

  0: texld      t2, tex0, t2.xyyy, void, void
  1: mul        t1, 3.0, t1, void       ; tex not used but fields non-zero (id=0,amode=4,swiz=0)
  2: mul        t1, t1, t2, void        ; tex not used but fields non-zero (id=0,amode=4,swiz=0)

I also think I've found the relevant state bit:

-            0x00011f03, /*   [01008] PS.INPUT_COUNT := COUNT=3,UNK8=31(residue:0x00010000) */
+            0x00001f03, /*   [01008] PS.INPUT_COUNT := COUNT=3,UNK8=31 */

Thanks,
Wladimir