[Mesa-dev] [RFC PATCH] gallium: add interface for EQAA

Tue May 1 20:49:46 UTC 2018

On Tue, May 1, 2018 at 10:48 AM, Roland Scheidegger <sroland at vmware.com>
wrote:

> Am 01.05.2018 um 01:43 schrieb Marek Olšák:
> > From: Marek Olšák <marek.olsak at amd.com>
> >
> > This is a hypothetical interface for EQAA (a superset of CSAA). CSAA
> could be
> > exposed via GL_NV_framebuffer_multisample_coverage. EQAA additionally
> removes
> > the restriction that the number of samples in all FBO attachments must
> match,
> > which means it allows arbitrary sample counts in each FBO attachment.
>
> The idea sounds ok to me, as long as you don't expose the additional
> modes with more samples as ordinary msaa modes.
> (I'm quite sure at some point nvidia exposed 16x msaa modes through
> ordinary means, which then gave you really 4 color samples and 12
> coverage-only samples, in some not-very-compliant way. Though IIRC the
> extension is actually older than the ability to do per-sample msaa fb
> reads, so it wasn't as problematic back then.)
>
> > ---
> >  src/gallium/docs/source/screen.rst   | 17 +++++++++++++++--
> >  src/gallium/include/pipe/p_defines.h |  1 +
> >  src/gallium/include/pipe/p_state.h   |  3 ++-
> >  3 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/gallium/docs/source/screen.rst
> b/src/gallium/docs/source/screen.rst
> > index 3837360fb40..28934c2f7b9 100644
> > --- a/src/gallium/docs/source/screen.rst
> > +++ b/src/gallium/docs/source/screen.rst
> > @@ -398,20 +398,22 @@ The integer capabilities:
> >  * ``PIPE_CAP_LOAD_CONSTBUF``: True if the driver supports
> TGSI_OPCODE_LOAD use
> >    with constant buffers.
> >  * ``PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS``: Any TGSI register can be used
> as
> >    an address for indirect register indexing.
> >  * ``PIPE_CAP_TILE_RASTER_ORDER``: Whether the driver supports
> >    GL_MESA_tile_raster_order, using the tile_raster_order_* fields in
> >    pipe_rasterizer_state.
> >  * ``PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES``: Limit on combined
> shader
> >    output resources (images + buffers + fragment outputs). If 0 the state
> >    tracker works it out.
> > +* ``PIPE_CAP_EQAA_COLOR_SAMPLE_SUPPORT_MASK``: If the i-th bit is set,
> EQAA
> > +  supports (i+1) color samples.
> I agree with Nicolai here, this looks strange, this should instead query
> for total samples or something.
>
> >  * ``PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET``:
> >    Whether pipe_vertex_buffer::buffer_offset is treated as signed. The
> u_vbuf
> >    module needs this for optimal performance in workstation applications.
> >  * ``PIPE_CAP_CONTEXT_PRIORITY_MASK``: For drivers that support
> per-context
> >    priorities, this returns a bitmask of PIPE_CONTEXT_PRIORITY_x for the
> >    supported priority levels.  A driver that does not support prioritized
> >    contexts can return 0.
> >  * ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling
> semaphores
> >    using fence_server_signal().
> >  * ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that
> must be
> > @@ -743,22 +745,33 @@ Modern APIs allow using buffers as shader
> resources.
> >  (1 for 1D or 1D array textures).
> >
> >  **depth0** the depth of the base mip level of the texture
> >  (1 for everything else).
> >
> >  **array_size** the array size for 1D and 2D array textures.
> >  For cube maps this must be 6, for other textures 1.
> >
> >  **last_level** the last mip map level present.
> >
> > -**nr_samples** the nr of msaa samples. 0 (or 1) specifies a resource
> > -which isn't multisampled.
> > +**nr_samples**: For Z/S, this is the number of samples. For color, if
> EQAA
> > +is unsupported, this is the number of both coverage samples and color
> samples.
> > +If EQAA is supported, this is the number of coverage samples. 0 and 1
> > +specify a resource which isn't multisampled.
> I think you should keep nr_samples alone, and re-change the meaning to
> actually be "real" samples with all associated data (which is what
> everybody expects with msaa).
>
> > +
> > +**nr_color_samples**: This is the number of color samples for EQAA,
> while
> > +``nr_samples`` is the number of coverage samples. If the format is Z/S,
> > +``nr_color_samples`` is ignored. Constraints:
> > +* ``nr_color_samples`` must not be greater than ``nr_samples``.
> > +* If ``nr_color_samples`` is equal to ``nr_samples``, it is called MSAA.
> > +* If ``nr_color_samples`` is less than ``nr_samples``, it is called
> EQAA.
> > +* If ``nr_color_samples`` is equal to 1, the behavior of the resolve
> blit is
> > +driver-dependent.
> >
> Hence instead use something like "total_samples" or "coverage samples"
> here (albeit the latter could be a bit confusing, unclear if it means
> all samples or just the extra ones).
> If you'd use something like "number of additional coverage samples"
> instead, then you could even leave all state trackers alone, since 0
> would automatically mean ordinary msaa without crazy stuff.
> And fwiw I'd stick to the CSAA name - coverage at least has some
> meaning, whereas "enhanced" (which is what the "E" in EQAA is for
> according to some old articles) really is just completely meaningless
> marketing term. There really isn't any difference, ok the ability to use
> different amount of samples per rt might be something, but you can't
> expose this anyway (AMD didn't come up with an extension for this since
> the 7+ years it's supported (since NI), so I have some doubts of its
> usefulness - besides you could have another cap which then would say if
> that's valid or not if you really come up with an extension specifically
> for it.)
> Unless there's some non-technical reasons you can't use the term CSAA.
>

EQAA is a superset of CSAA and is more complicated, so it doesn't make
sense to use "CSAA".

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180501/3da7a34e/attachment-0001.html>