[Mesa-dev] Mesa (master): draw: fix flat shading and screen-space linear interpolation in clipper

[Jose Fonseca]

----- Original Message -----
> On Mon, Jul 02, 2012 at 06:44:37AM -0700, Jose Fonseca wrote:
> > But I think that this fix is too ad-hoc, and I suspect it may
> > introduce other regressions.
> > 
> > If I understood the problem correctly, the issue here is that some
> > drivers want system values in floats, others want in
> > integers. Right?
> 
> It's slightly more perverted than that.  GLSL 1.20 says "if a value
> is
> an integer, it will be forced into a float but don't expect more than
> 16 bits precision", while 1.30 has native integers.  Next to that,
> some extensions (and gl versions) introduce integer system values but
> require native integer support to have them implemented.  The glsl
> parser handles that correctly by adding the needed type conversions
> when accessing these values from a 1.20 shader.
> 
> But then in mesa someone decided to extend the extensions and
> implement things like draw_instanced without native integer support.
> st_glsl_to_tgsi behaves very differently when native integers aren't
> there, forcing evey type to float and ignoring the integer->float
> type
> conversions.  What tells you that is that the requested type (dtype)
> is float while the system value itself is integer.
> 
> In fact, I suspect the conversion code is ill-advised.  It was picked
> up from the previous code, but actually it should only check that the
> types are identical or that float is requested for an int, and bitch
> otherwise.  

Note that all registers are stored as floats (for convenience, and because LLVM has no unions), so integers are bitcasted into floats while storing/loading.
And I'm not sure if your patch would break that.

I still think that having draw/gallivm guessing whether native integer support is intended or not is bad. Either:
1) TGSI is extended (e.g., more type annotations) so that native-integer support can inferred from it
2) draw/gallivm need to now if the driver has native-integer or not

I'm inclined towards 1), as TGSI should be self-documented. That is, it should not be necessary to know if the driver has or not native integer support to know whether system values should be assumed to be integers or floats...

> Still, it would be interesting to know if that patch
> works
> for i915g, even if we make things more cranky afterwards.


Jose