[Piglit] [PATCH 3/9] all.py: Everything in MSAA_SAMPLE_COUNTS is already even
Dylan Baker
baker.dylan.c at gmail.com
Mon Nov 23 14:13:50 PST 2015
On Mon, Nov 23, 2015 at 12:16:33PM -0800, Ian Romanick wrote:
> On 11/20/2015 04:56 PM, Dylan Baker wrote:
> > On Fri, Nov 20, 2015 at 03:05:49PM -0800, Ian Romanick wrote:
> >> On 11/20/2015 02:14 PM, Dylan Baker wrote:
> >>> On Thu, Nov 19, 2015 at 08:00:09PM -0800, Ian Romanick wrote:
> >>>> From: Ian Romanick <ian.d.romanick at intel.com>
> >>>>
> >>>> If this test has problems with odd sample counts, the test should detect
> >>>> that and SKIP.
> >>>
> >>> I'm not sure I agree. I think it's pretty reasonable for all.py to only
> >>> pass valid inputs to a test binary.
> >>
> >> Presumably the test is going to do some sort of validation on the input
> >> anyway. Most do. Now we have input massaging / validation in two
> >> places, and we have to maintain it in two places. That seems bad. Right?
> >
> > I agree, but it also seems bad to me to have tests defined in all.py
> > that will always return 'skip', and on one has a plan to make them work,
> > right?
>
> But there aren't.
>
> # List of all of the MSAA sample counts we wish to test
> MSAA_SAMPLE_COUNTS = (2, 4, 6, 8, 16, 32)
>
> I could have sworn that I said in the commit message that all the sample
> counts are already even, but it looks like I didn't... Maybe it was in
> an earlier version.
Okay, then in that case you can have my r-b if you'll mention this in
the commit message.
Reviewed-by: Dylan Baker <baker.dylan.c at gmail.com>
>
> There are some hypthetical odd-count MSAA arrangements (flip-tri and
> Quincunx come to mind), but I don't know of *any* implementations that
> support them. Quincunx was supported on Geforce3 hardware, but I
> believe it was exposed as 2x MSAA with a special filter (see the
> overview section of
> https://www.opengl.org/registry/specs/NV/multisample_filter_hint.txt).
>
> > I guess the assumption that I'm making in my logic is that the other
> > tests can handle odd sample counts. Maybe that's a bad assumption?
>
> I don't know if they can or not. Other than inspecting the tests (which
> is potentially faulty), we don't have any way to find out... because
> there are no OpenGL implementations that can handle odd sample counts. :)
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20151123/99afc093/attachment.sig>
More information about the Piglit
mailing list