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

[Marek Olšák]

FWIW, I think Draw needs to know if a driver does or does not support
integers, so that it can return system values in the correct type (not
sure if that includes gallivm too). The reason for that is that
glsl_to_tgsi generates *different* shaders depending on the native
integer cap. I think this is good; the drivers which don't have
integer system values and integer instructions just get shaders
prepared to be executed on floating-point units only.

However the aforementioned modification of Draw would only be required
if there were a driver using Draw for fallbacks, i.e. if a driver
doesn't know in advance whether a shader will be executed in software
or hardware (that's only svga, I guess?).

The software drivers and the drivers using Draw on hardware without
vertex shaders can always use Draw with full integer support (and
glsl_to_tgsi should generate vertex shaders with integers*) and
nothing would need to be changed. Such drivers should return
draw_get_shader_param(..) in get_shader_param, so that the state
tracker knows exactly what the Draw module expects.

* I just realized there is a bug in glsl_to_tgsi which doesn't follow
the integer shader cap correctly. I'll send patches.

Marek

On Tue, Jul 3, 2012 at 10:43 PM, Olivier Galibert <galibert at pobox.com> wrote:
> On Tue, Jul 03, 2012 at 12:39:47PM -0700, Jose Fonseca wrote:
>> 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 did test the patch with a llvmpipe in a glsl 120/no native integer
> setup.  draw_instanced worked.  I didn't try a full piglit though.
>
>
>> 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...
>
> It could be argued that dtype being TGSI_TYPE_FLOAT is the
> documentation on what is expected.  But I'm quickly reaching the point
> where I don't really care, just tell me what you want.  As long as
> textureFetch stays the only issue between llvmpipe and 1.30 I'm ok.
>
> Of course doing textureFetch right is going to require an interesting
> overhaul of the texture allocations... need to finish fixing the gm45
> interpolation/clipping first.
>
> Best,
>
>   OG.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev