[Mesa-dev] gallium and GL interpolation intersection issue

Marek Olšák maraeo at gmail.com
Mon Jan 9 08:30:35 PST 2012


On Mon, Jan 9, 2012 at 5:06 PM, Brian Paul <brianp at vmware.com> wrote:
> On 01/09/2012 06:35 AM, Dave Airlie wrote:
>>
>> Okay so we have a gallium/GL/GLSL problem with interpolation, lets see
>> if I can describe the issue:
>>
>> In the beginning there was GL interpolation rules, glShadeModel was
>> the only information you had.
>>
>> Then came GLSL which allowed overriding the GL defaults using specifiers.
>>
>> So the gl_FrontColor variant, if left unspecified would take the value
>> of the glShadeModel, if specified
>> it would over-rule the current ShadeModel setting.
>>
>>
>> So we end up something like this
>>
>> if (glFrontColor attrib>  0) result = glFrontColor_attrib; else result
>> = shademodel.
>>
>> Now when we convert to gallium we lose the unspecified interpolation,
>> and we generate a default interpolation
>> attribute, which should usually be SMOOTH. Now we've no idea then
>> inside the gallium drivers whether this smooth
>> is due to an explicit smooth at the GLSL level which we can't
>> override, or whether this smooth is something that we really
>> wanted to be overruled by the ShadeModel bit.
>>
>> Now as discussed previously most hardware has support for the
>> ShadeModel bit so generating multiple shaders
>> for the unspecified case would be suboptimal for it.
>>
>> So the options I see are:
>>
>> (a) do it anyways, apply the patch I had earlier that derives the
>> setting at the glsl->tgsi translation stage, and pretty
>> much ignore it.
>>
>> (b) add unspecified interpolation support for Color inputs, only
>> colors are affected by this, and since TGSI supports
>> Colors we should probably support all the features of the GL Color
>> output/inputs.
>>
>> Anyone any other ideas?
>
>
> I'd probably go with (b), add a new TGSI_INTERPOLATE_COLOR mode that means
> "look at pipe_rasterizer_state::flatshade."
>
> IMO, it's still attractive to get rid of pipe_rasterizer_state::flatshade
> someday.  glShadeModel no longer exists in OpenGL 3.2 core profile and
> later.

Please note that the GLSL interpolation modes are a GLSL 1.3 feature.
We can't remove pipe_rasterizer_state::flatshade_first for non-GL3
drivers. And even with the interpolation modes available,
recompiling.shaders when glShadeModel changes is an anti-optimization
if drivers can do pipe_rasterizer_state::flatshade_first just fine. I
would prefer that if there's a driver which cannot do
pipe_rasterizer_state::flatshade_first (just svga?), let's add a CAP
for it and handle it in the state tracker.

Marek


More information about the mesa-dev mailing list