[Mesa-dev] gallium and GL interpolation intersection issue

[Marek Olšák]

Sorry, I mean flatshade, not flatshade_first.

Marek

On Mon, Jan 9, 2012 at 5:30 PM, Marek Olšák <maraeo at gmail.com> wrote:
> 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