[Mesa-dev] [RFC PATCH] i965/msaa: Disable unsupported formats.

[Eric Anholt]

On Fri, 15 Jun 2012 18:17:05 -0700, Paul Berry <stereotype441 at gmail.com> wrote:
> On 15 June 2012 14:44, Chad Versace <chad.versace at linux.intel.com> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 06/15/2012 11:12 AM, Paul Berry wrote:
> > > Due to hardware limitations, MSAA is unsupported on Gen6 for formats
> > > containing >64 bits of data per pixel.  From the Sandy Bridge PRM,
> > > vol4 part1, p72 ("Surface Format"):
> > >
> > >     If Number of Multisamples is set to a value other than
> > >     MULTISAMPLECOUNT_1, this field cannot be set to the following
> > >     formats:
> > >     - any format with greater than 64 bits per element
> > >     - any compressed texture format (BC*)
> > >     - any YCRCB* format
> > >
> > > Gen7 has a similar, but less stringent limitation: formats with >64
> > > bits of data per pixel only support 4x MSAA.
> > >
> > > This patch causes the unsupported formats to report
> > > GL_FRAMEBUFFER_UNSUPPORTED.
> > >
> > > Fixes piglit "multisample-formats" tests on Gen6.
> > > ---
> > >
> > > It is not 100% clear to me whether this approach is compliant with the
> > > spec.  On the one hand, the spec requires formats RGBA32F, RGBA32I,
> > > and RGBA32UI to be color-renderable.  On the other hand, the spec
> > > allows for the implementation to report GL_FRAMEBUFFER_UNSUPPORTED if
> > > the set of attached images violates "an implementation-dependent set
> > > of restrictions", which seems to leave a lot of leeway.
> > >
> > > If we decide that it's not ok to report GL_FRAMEBUFFER_UNSUPPORTED for
> > > MSAA buffers using these formats, then we'll have to figure out some
> > > other way to work around the hardware's lack of support for MSAA on
> > > these formats, and I haven't thought of a good way to do that.  The
> > > alternatives I've considered (substitute another buffer format, or
> > > substitute a non-multisampled renderbuffer) are definitely
> > > non-spec-compliant, and also fraught with implementation difficulties.
> > >
> > > So for the moment my inclination is to go through with this patch as
> > > is, and if we later discover that it causes trouble for a client
> > > application, we can consider other options.  I'm curious to hear what
> > > others think.
> >
> > After releasing GL3.0, but before implementing real MSAA, we lied to the
> > app.
> > If the app requested an MSAA buffer, we said "ok" and just created a
> > single-sample
> > buffer.
> >
> > Can we do that for these formats? It may be better to do that than report
> > GL_FRAMEBUFFER_UNSUPPORTED. I'm unsure what's best, though.
> >
> 
> Thanks for the suggestion.  At the risk of giving off the impression that I
> already have my mind made up, I *did* consider this approach, and here's
> why I rejected it: all attachments to a framebuffer need to have the same
> sample count.  So if we secretly substitute a single-sampled RGBA32F buffer
> in place of the 4x RGBA32F buffer the client program requests, we'll also
> have to secretly substitute single-sampled depth and stencil buffers, as
> well as single-sampled versions of all the other color buffers the client
> program might have attached to the same framebuffer (because a framebuffer
> can have multiple color attachments).  We can't do this substitution until
> drawing is done (or the client program calls glCheckFramebufferStatus()),
> because between draws, the client program might have incompatible
> renderbuffers attached to the same framebuffer as a transitory condition.
>  Getting the logic right for secretly swapping in single-sampled
> framebuffers, at the time of the draw call, is going to be tricky.

I went through pretty much the same line of thought myself when the
issue was brought up: couldn't we just fall back to 1 sample, but then
we would have an incomplete framebuffer when they mixed it in with
another color/depth/stencil buffer without the workaround.

As a result, I think the framebuffer unsupported is the right way to
work around this.  My understanding of the intent of the required
formats part of the spec is "you have to be able to get these formats to
actually show up in some form or it's not GL3 hardware", but that the
driver-specific behavior for framebuffer unsupported means you don't
have to do software fallbacks for funky combinations where the hardware
is broken.
-------------- 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/20120618/269ad587/attachment.pgp>