Ok, great. Do you have any idea if RENDERBUFFER_SAMPLES will return the lie or 0/1?
-Jeff ----- Original Message ----- From: "Eric Anholt" <e...@anholt.net> To: "Jeff Gilbert" <jgilb...@mozilla.com>, "Benoit Jacob" <bja...@mozilla.com> Cc: mesa-dev@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 <jgilb...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
