[Mesa-dev] [PATCH 1/3] gallium: add per-sample interpolation control into rasterizer state

Marek Olšák maraeo at gmail.com
Fri Oct 2 10:56:34 PDT 2015

On Fri, Oct 2, 2015 at 7:50 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Fri, Oct 2, 2015 at 1:48 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> On Fri, Oct 2, 2015 at 4:12 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>> Am 02.10.2015 um 12:19 schrieb Marek Olšák:
>>>> On Fri, Oct 2, 2015 at 3:13 AM, Roland Scheidegger <sroland at vmware.com> wrote:
>>>>> Can't say I'm a big fan of doing essentially the same thing with
>>>>> different methods, but well it's coming from GL, and if it helps some
>>>>> drivers...
>>>>> Acked-by: Roland Scheidegger <sroland at vmware.com>
>>>> If all drivers start supporting the CAP, we could remove the st/mesa
>>>> emulation. Just as we could remove the color clamping emulation.
>>>> Marek
>>> Yes, but that just moves the logic to the drivers. It's still (mostly)
>>> the same thing handling per-sample inputs, or forcing them to per sample
>>> via ARB_sample_shading.
>> Yes, that's the main point. For performance, we should do the
>> translation to TGSI at link time, so that the GLSL->TGSI overhead can
>> be removed from draw calls. Because of that, all shader state
>> dependencies should be moved to and implemented/emulated in drivers.
>> This will be difficult to do because of the lack of interest from
>> other driver maintainers, therefore we need CAPs until they realize
>> it's good for them too.
> In case that was directed at me, I realize it's good for me too. I
> just don't know if I can do it on your schedule and I'd rather nouveau
> not be broken in the meanwhile :)

No, that wasn't directed at you. The "lack of interest" can also be
translated as the lack of manpower.

I'll try to do my best to ensure that no driver will be broken.


More information about the mesa-dev mailing list