[Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers

[Jeff Gilbert]

Ok, great. Do you have any idea if RENDERBUFFER_SAMPLES will return the lie or 0/1?

-Jeff

----- Original Message -----
From: "Eric Anholt" <eric at anholt.net>
To: "Jeff Gilbert" <jgilbert at mozilla.com>, "Benoit Jacob" <bjacob at mozilla.com>
Cc: mesa-dev at lists.freedesktop.org
Sent: Wednesday, April 18, 2012 3:07:17 PM
Subject: Re: [Mesa-dev] WebGL WG interested in 1.0.1 conformance test results on real drivers

On Wed, 18 Apr 2012 03:32:46 -0700 (PDT), Jeff Gilbert <jgilbert at mozilla.com> wrote:
> It depends how much of the spec its in violation of.
> 
> Hopefully, querying GL_RENDERBUFFER_SAMPLES on the RB should show it
> with 0 or 1 sample(s). Per spec, this is not okay, since
> RENDERBUFFER_SAMPLES is guaranteed to be >= the 'samples' value used
> at allocation, but at least 0 or 1 would reflect reality. However,
> since the spec requires that it gives at least what was requested,
> there's no reason the user should check the value afterwards, if all
> they care about is the minimum.
> 
> I think the most spec-safe way to signal it would be to trigger
> GL_OUT_OF_MEMORY in response to requests for renderbuffers with
> samples>1 of any size. This is at least theoretically plausible, since
> no amount of memory will give what was requested. This doesn't give a
> great indication of what happened, since the assumption will be that
> it's actually OOM, but seems technically compliant. At least this
> would give some indication something exceptional or unexpected is
> happening.
> 
> It seems (at least for 3.3) that specification of what multisampled
> sampling requires is pretty minimally-defined, result-wise. If it's as
> 'up to the implementation' as it seems, it could technically
> 'multisample' by 'checking' the pixel in the same place N times, so
> long as GetMultisamplefv(SAMPLE_POSITION, [0-MAX_SAMPLES], ret) gives
> back the same center-of-pixel (0.5,0.5) location for each. This seems
> to be technically correct in the worst sort of way, but is checkable
> by the user, and doesn't appear to be otherwise-guaranteed.
> 
> The spec is long though, so I am quite possibly missing something.
> 
> Also, is there a bug open against Mesa for this?

The lying about MSAA came about from a last-minute "oh crap, GL 3.0
guarantees GL_MAX_SAMPLES of 4, but we don't do MSAA.  What do we do?"
We resolved to lie about GL_MAX_SAMPLES so that GL 3.0 applications
would at least run even though they would render single-sampled, and add
MSAA as soon as possible.  Paul's been working on it, and he's got a
prototype up and running.  Mostly we're limited by how hard it is to
write all the tests we need for msaa functionality.