I would have expected explicit qualifiers to trump everything. I
wonder why that was removed -- Ian?
It seems there's a clear precedent established by the other drivers,
though -- so I think we should stick to it.
Bonus for us: since our centroid support is a bit bogus and requires
workarounds, w
On Mon, Jan 13, 2014 at 1:06 PM, Anuj Phogat wrote:
>
> On Fri, Jan 10, 2014 at 5:25 PM, Anuj Phogat wrote:
> > On Thu, Jan 9, 2014 at 4:34 PM, Chris Forbes wrote:
> >> Hi Anuj,
> >>
> >> There's one fiddly interaction that I don't think this handles quite
> >> right, although I think it does co
On Fri, Jan 10, 2014 at 5:25 PM, Anuj Phogat wrote:
> On Thu, Jan 9, 2014 at 4:34 PM, Chris Forbes wrote:
>> Hi Anuj,
>>
>> There's one fiddly interaction that I don't think this handles quite
>> right, although I think it does conform.
>>
>> Suppose we have this fragment shader:
>>
>>#versio
On Thu, Jan 9, 2014 at 4:34 PM, Chris Forbes wrote:
> Hi Anuj,
>
> There's one fiddly interaction that I don't think this handles quite
> right, although I think it does conform.
>
> Suppose we have this fragment shader:
>
>#version 330
>#extension ARB_gpu_shader5: require
>
>sample in
Hi Anuj,
There's one fiddly interaction that I don't think this handles quite
right, although I think it does conform.
Suppose we have this fragment shader:
#version 330
#extension ARB_gpu_shader5: require
sample in vec4 a;
in vec4 b;
...
Then `b` is being evaluated at the samp
Current implementation of arb_sample_shading doesn't set 'Barycentric
Interpolation Mode' correctly. We use pixel barycentric coordinates
for per sample shading. Instead we should select perspective sample
or non-perspective sample barycentric coordinates.
It also enables using sample barycentric
