On Fri, Sep 16, 2016 at 4:42 PM, Brian Paul wrote:
> On 09/16/2016 08:07 AM, Marek Olšák wrote:
>>
>> On Thu, Sep 15, 2016 at 11:20 PM, Brian Paul wrote:
>>>
>>> Regardless of whether GL_MULTISAMPLE is enabled (it's enabled by default)
>>> we should not set the alpha_to_coverage or alpha_to_one f
We can't change how gallium is supposed to behave since other apis rely
on coverage-to-alpha working even if msaa is disabled.
Roland
Am 16.09.2016 um 18:58 schrieb Ilia Mirkin:
> FTR, the new piglit test passed as-is on NVIDIA hw (at least nv50 and
> nvc0). I'm not opposed to this new state depe
FTR, the new piglit test passed as-is on NVIDIA hw (at least nv50 and
nvc0). I'm not opposed to this new state dependency if Marek isn't
(he's analyzed these things a whole lot more than I suspect anyone
else), but just wanted to point it out in case the preference is to
instead change how gallium
On 09/16/2016 08:07 AM, Marek Olšák wrote:
On Thu, Sep 15, 2016 at 11:20 PM, Brian Paul wrote:
Regardless of whether GL_MULTISAMPLE is enabled (it's enabled by default)
we should not set the alpha_to_coverage or alpha_to_one flags if the
current drawing buffer does not do MSAA.
This fixes the
On Thu, Sep 15, 2016 at 11:20 PM, Brian Paul wrote:
> Regardless of whether GL_MULTISAMPLE is enabled (it's enabled by default)
> we should not set the alpha_to_coverage or alpha_to_one flags if the
> current drawing buffer does not do MSAA.
>
> This fixes the new piglit gl-1.3-alpha_to_coverage_n
Am 15.09.2016 um 23:20 schrieb Brian Paul:
> Regardless of whether GL_MULTISAMPLE is enabled (it's enabled by default)
> we should not set the alpha_to_coverage or alpha_to_one flags if the
> current drawing buffer does not do MSAA.
>
> This fixes the new piglit gl-1.3-alpha_to_coverage_nop test.
