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" <bja...@mozilla.com>
To: "Eric Anholt" <e...@anholt.net>, "Jeff Gilbert" <jgilb...@mozilla.com>
Cc: mesa-dev@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to