On 12/8/18 7:03 PM, Rhys Perry wrote:
A small number of questions/concerns:
- sampleLocationCoordinateRange[1] should probably be set to 0.9375,
because of how the sample locations are encoded
That doesn't matter much but we can update it yeah.
- gl_SamplePosition doesn't seem like it
On Sat, Dec 8, 2018 at 7:03 PM Rhys Perry wrote:
>
> A small number of questions/concerns:
>
> - sampleLocationCoordinateRange[1] should probably be set to 0.9375,
> because of how the sample locations are encoded
> - gl_SamplePosition doesn't seem like it would return the new sample
>
A small number of questions/concerns:
- sampleLocationCoordinateRange[1] should probably be set to 0.9375,
because of how the sample locations are encoded
- gl_SamplePosition doesn't seem like it would return the new sample
locations
- R_028BD4_PA_SC_CENTROID_PRIORITY_{0,1} isn't updated. I'm
Basically, this extension allows applications to use custom
sample locations. This only implements the barely minimum.
It doesn't support variable sample locations during subpass.
Most of the dEQP-VK.pipeline.multisample.sample_locations_ext.*
CTS now pass.
Only enabled on VI+ because it's