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

[Eric Anholt]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120418/62250d51/attachment.pgp>