On Fri, Jan 10, 2014 at 5:25 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
On Thu, Jan 9, 2014 at 4:34 PM, Chris Forbes chr...@ijw.co.nz 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
On Mon, Jan 13, 2014 at 1:06 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
On Fri, Jan 10, 2014 at 5:25 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
On Thu, Jan 9, 2014 at 4:34 PM, Chris Forbes chr...@ijw.co.nz wrote:
Hi Anuj,
There's one fiddly interaction that I don't think this handles
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,
On Thu, Jan 9, 2014 at 4:34 PM, Chris Forbes chr...@ijw.co.nz 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
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
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
