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

Tue May 1 22:22:49 UTC 2018

On Tue, May 1, 2018 at 5:53 PM, Roland Scheidegger <sroland at vmware.com>
wrote:

> Am 01.05.2018 um 22:49 schrieb Marek Olšák:
> > On Tue, May 1, 2018 at 10:48 AM, Roland Scheidegger <sroland at vmware.com
> > <mailto: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 <mailto: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".
>
> I disagree. "Coverage sampling" is what you do - if you can do a bit
> more or less than nvidia's csaa specification (and I have no idea if
> that was restricted by hw even or not) doesn't matter. You still
> essentially use "coverage samples" for it, and not "enhanced quality"
> samples.
> But meh, whatever floats your boat. As long as not separate values
> appear for csaa and eqaa in gallium doing the same I don't care that
> much what it's called. But EQAA is a pure marketing term having zero
> actual meaning, whereas CSAA at least makes some technical sense.
>

Both EQAA and CSAA have zero meaning. Radeon uses fragment pointers to
optimize MSAA and implement EQAA and CSAA, so it can be said that Radeon
can only do Fragment Pointer AA (FPAA). If you wanna play with words, I can
do that all day. :)

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