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

[Jeff Gilbert]

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?

-Jeff


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

> GL_MAX_SAMPLES tells you how many samples you can ask for from a
> multisample renderbuffer (GL 3.0 spec page 285), while to ask about
> the
> number of samples in a particular GLX visuals you have to check the
> GLX_SAMPLE_BUFFERS_ARB of the visual (GL_ARB_multisample spec).  We
> currently expose GL_MAX_SAMPLES of 4 (GL 3.0 spec page 391), but
> that's
> a lie and if you ask for a 4-sample renderbuffer we don't actually
> multisample it.  We don't expose any GLX visuals with nonzero
> GLX_SAMPLE_BUFFERS_ARB, which is conformant but disappointing.

Thanks for that information. WebGL antialiasing relies in multisample renderbuffers (ARB_framebuffer_multisample), not on multisample GLX visuals. So GL_MAX_SAMPLES is really what we care about. If the value returned by Mesa for getIntegerv(GL_MAX_SAMPLES) can't be used to tell whether multisample renderbuffers are actually supported, then how can we determine that?

Benoit