<div dir="ltr"><div>It was marketed that way because D3D didn't have API to do anything else.</div><div> </div><div>In practice, EQAA can do arbitrary color coverage, color storage, and Z/S sample counts, and each color render target can have different values too. So everything is allowed, but the combinations that don't make sense only waste memory and do useless work that is not stored. </div><div> </div><div>The configs with the best quality/performance tradeoff are "8 >= color coverage samples == Z/S samples >= color storage samples" (the upper limit is for AMD). Having maximum Z/S samples doesn't decrease performance in some cases due to internal GPU optimizations, so it's better to keep them for quality. </div><div> </div><div>The full range of configs that don't waste memory and don't do useless work (i.e. they can be useful) is "16 >= color coverage samples >= Z/S samples >= color storage samples". The color coverage is the only one that can have 16 samples. Z/S has to have 8 or less. Z/S can sometimes have higher quality than allocated due to Z/S compression, but front-to-back rendering quality drops to the allocated Z/S sample count when Z/S doesn't compress well. The Z/S hw can run at color coverage sample rate regardless of allocated Z/S samples. </div><div> </div><div>color storage samples == 1 may also be useful if the resolve shader is implemented well, but it starts to compete with MLAA. I still prefer to have the maximum Z/S sample count here as dictated by the first equation above. </div><div> </div><div>Marek </div><div> </div><div><div class="gmail_extra"> <div class="gmail_quote">On Mon, May 21, 2018 at 9:14 PM, Roland Scheidegger <<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was under the (apparently wrong) impression EQAA always worked like that too. Even AMD's marketing said EQAA has the same number of stencil/depth/color samples as regular MSAA (when the feature was new, HD 6900, <a href="https://developer.amd.com/wordpress/media/2012/10/EQAA%2520Modes%2520for%2520AMD%2520HD%25206900%2520Series%2520Cards.pdf" rel="noreferrer" target="_blank">https://developer.amd.com/wordpress/media/2012/10/EQAA%2520Modes%2520for%2520AMD%2520HD%25206900%2520Series%2520Cards.pdf</a>). As well as every article I've seen on that subject... So I believe the EQAA options available with windows never use more depth storage samples than color storage samples. And both CSAA and EQAA were generally met with lukewarm reception - as you noted, for front to back rendering it's useless. I'll agree that in theory having more depth samples sounds quite useful, but maybe in practice the cost is too high (EQAA as well as CSAA were marketed as nearly free compared to the MSAA modes with the same number of depth/stencil/color samples, I could imagine if you use the same number of depth storage samples as coverage samples the cost could approach closer to a MSAA mode which just has the higher number of samples for color too, but I guess it would depend on the number and type of color buffers). Roland Am 22.05.2018 um 02:46 schrieb Marek Olšák: > Your understanding is correct. I misunderstood CSAA. So it looks like > that CSAA is more useless than I thought. You get the coverage-samples > level of quality for back-to-front rendering, but you may get the > depth-samples level of quality for front-to-back rendering, because > "edges" generated by depth test failures have the same quality as the > number of depth samples (if depth values are uncompressed). AMD supports > that mode too, but I don't recommend using it because of the possible > decrease in front-to-back rendering quality. > > The way the CAP is defined doesn't actually allow NV's implementation of > CSAA. A new CAP would be needed. > > We'll add a new GL extension for advanced MSAA. The NV extension is > unusable, because it changes GL behavior in a non-backward-compatible > way by allowing storage_samples = 2 for all renderbuffers (which is > cheating, but not surprising from NV). > > Marek > > On Mon, May 21, 2018 at 12:55 PM, Axel Davy <<a href="mailto:davyaxel0@gmail.com">davyaxel0@gmail.com</a> > <mailto:<a href="mailto:davyaxel0@gmail.com">davyaxel0@gmail.com</a>>> wrote: > > Hi, > > I get the impression when looking at online documentation about EQAA > and CSAA, like > <a href="http://www.nvidia.fr/object/coverage-sampled-aa.html" rel="noreferrer" target="_blank">http://www.nvidia.fr/object/coverage-sampled-aa.html</a> > <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nvidia.fr_object_coverage-2Dsampled-2Daa.html&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0&m=mT5z2nGhAlFu_lLjhtTx-Gb1xMAX_goZ2-tp5FknDXU&s=lTxXM-R2kvTIBzi4Wjjl8uT7R88UhQgdvkIHJLVaQsQ&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nvidia.fr_object_coverage-2Dsampled-2Daa.html&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0&m=mT5z2nGhAlFu_lLjhtTx-Gb1xMAX_goZ2-tp5FknDXU&s=lTxXM-R2kvTIBzi4Wjjl8uT7R88UhQgdvkIHJLVaQsQ&e=</a>> > > that the number of stored samples is the same for the color and > depth buffers. > Only the samples used for coverage is greater. > > With your proposal, isn't the number of samples stored in the depth > buffer always the same than the number of samples used for coverage ? > That reduces the use-cases. In nine, we have to enforce the number > of stored samples to be the same for the color and the depth buffer, > but we could increase the number of samples used for coverage and > enable EQAA/CSAA (in fact there is a similar way to advertise the > feature for Nvidia and Amd). > > But maybe I misunderstood. > > Yours, > > Axel Davy > > > On 18/05/2018 06:05, Marek Olšák wrote: > > From: Marek Olšák <<a href="mailto:marek.olsak@amd.com">marek.olsak@amd.com</a> <mailto:<a href="mailto:marek.olsak@amd.com">marek.olsak@amd.com</a>>> <div><div class="h5">> > The interface only uses general MSAA terms, so it's "advanced > MSAA" and not > something vendor-specific. > > It's a proper subset of EQAA, and a proper superset of CSAA, so > it's neither. > > Changes: > - pipe_resource is changed > - is_format_supported is changed > - a new CAP is added > --- > src/gallium/docs/source/screen.rst | 31 > ++++++++++++++++++++++++++-- > src/gallium/include/pipe/p_defines.h | 1 + > src/gallium/include/pipe/p_screen.h | 1 + > src/gallium/include/pipe/p_state.h | 18 +++++++++++++--- > 4 files changed, 46 insertions(+), 5 deletions(-) > > diff --git a/src/gallium/docs/source/screen.rst > b/src/gallium/docs/source/screen.rst > index 5bc6ee99f08..cf4787a1c49 100644 > --- a/src/gallium/docs/source/screen.rst > +++ b/src/gallium/docs/source/screen.rst > @@ -398,20 +398,25 @@ 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_FRAMEBUFFER_MIXED_SAMPLES``: Framebuffer > attachments can have > + different number of samples each with the following restriction: > + color.nr_samples >= zs.nr_samples >= color.nr_storage_samples > + If 0 is returned, the following restriction applies: > + color.nr_samples == zs.nr_samples >= color.nr_storage_samples > * ``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 > @@ -718,20 +723,23 @@ is_format_supported > Determine if a resource in the given format can be used in a > specific manner. > **format** the resource format > **target** one of the PIPE_TEXTURE_x flags > **sample_count** the number of samples. 0 and 1 mean no > multisampling, > the maximum allowed legal value is 32. > +**storage_sample_count** the number of storage samples. This > must be <= > +sample_count. See the documentation of > ``pipe_resource::nr_storage_samples``. > + > **bindings** is a bitmask of :ref:`PIPE_BIND` flags. > Returns TRUE if all usages can be satisfied. > can_create_resource > ^^^^^^^^^^^^^^^^^^^ > Check if a resource can actually be created (but don't > actually allocate any > memory). This is used to implement OpenGL's proxy textures. > Typically, a > @@ -761,22 +769,41 @@ 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**: Number of samples determining quality, driving > the rasterizer, > +shading, and framebuffer. It is the number of samples seen by > the whole > +graphics pipeline. 0 and 1 specify a resource which isn't > multisampled. > + > +**nr_storage_samples**: Only color buffers can set this lower > than nr_samples. > +Multiple samples within a pixel can have the same color. > ``nr_storage_samples`` > +determines how many slots for different colors there are per pixel. > +If there are not enough slots to store all sample colors, some > samples will > +have an undefined color (called "undefined samples"). > + > +The resolve blit behavior is driver-specific, but can be one of > these two: > +1. Only defined samples will be averaged. Undefined samples > will be ignored. > +2. Undefined samples will be approximated by looking at > surrounding defined > + samples (even in different pixels). > + > +Blits and MSAA texturing: If the sample being fetched is > undefined, one of > +the defined samples is returned instead. > + > +Sample shading (``set_min_samples``) will operate at a sample > frequency that > +is at most ``nr_storage_samples``. Greater ``min_samples`` > values will be > +replaced by ``nr_storage_samples``. > **usage** one of the :ref:`PIPE_USAGE` flags. > **bind** bitmask of the :ref:`PIPE_BIND` flags. > **flags** bitmask of PIPE_RESOURCE_FLAG flags. > resource_changed > diff --git a/src/gallium/include/pipe/p_defines.h > b/src/gallium/include/pipe/p_defines.h > index 6b2f33b9e37..5693396c9e9 100644 > --- a/src/gallium/include/pipe/p_defines.h > +++ b/src/gallium/include/pipe/p_defines.h > @@ -794,20 +794,21 @@ enum pipe_cap > PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION, > PIPE_CAP_POST_DEPTH_COVERAGE, > PIPE_CAP_BINDLESS_TEXTURE, > PIPE_CAP_NIR_SAMPLERS_AS_DEREF, > PIPE_CAP_QUERY_SO_OVERFLOW, > PIPE_CAP_MEMOBJ, > PIPE_CAP_LOAD_CONSTBUF, > PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS, > PIPE_CAP_TILE_RASTER_ORDER, > PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES, > + PIPE_CAP_FRAMEBUFFER_MIXED_SAMPLES, > PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET, > PIPE_CAP_CONTEXT_PRIORITY_MASK, > PIPE_CAP_FENCE_SIGNAL, > PIPE_CAP_CONSTBUF0_FLAGS, > PIPE_CAP_PACKED_UNIFORMS, > PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_TRIANGLES, > PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_POINTS_LINES, > PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_TRIANGLES, > PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_POINTS_LINES, > PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION_BIAS, > diff --git a/src/gallium/include/pipe/p_screen.h > b/src/gallium/include/pipe/p_screen.h > index 101e229088b..94c61dfab2e 100644 > --- a/src/gallium/include/pipe/p_screen.h > +++ b/src/gallium/include/pipe/p_screen.h > @@ -150,20 +150,21 @@ struct pipe_screen { > /** > * Check if the given pipe_format is supported as a texture or > * drawing surface. > * \param bindings bitmask of PIPE_BIND_* > */ > boolean (*is_format_supported)( struct pipe_screen *, > enum pipe_format format, > enum pipe_texture_target > target, > unsigned sample_count, > + unsigned storage_sample_count, > unsigned bindings ); > /** > * Check if the given pipe_format is supported as output > for this codec/profile. > * \param profile profile to check, may also be > PIPE_VIDEO_PROFILE_UNKNOWN > */ > boolean (*is_video_format_supported)( struct pipe_screen *, > enum pipe_format format, > enum > pipe_video_profile profile, > enum > pipe_video_entrypoint entrypoint ); > diff --git a/src/gallium/include/pipe/p_state.h > b/src/gallium/include/pipe/p_state.h > index db9fa1a8e9f..1baa497b227 100644 > --- a/src/gallium/include/pipe/p_state.h > +++ b/src/gallium/include/pipe/p_state.h > @@ -511,41 +511,53 @@ struct pipe_box > int16_t depth; > }; > /** > * A memory object/resource such as a vertex buffer or texture. > */ > struct pipe_resource > { > struct pipe_reference reference; > - struct pipe_screen *screen; /**< screen that this texture > belongs to */ > unsigned width0; /**< Used by both buffers and textures. */ > uint16_t height0; /* Textures: The maximum > height/depth/array_size is 16k. */ > uint16_t depth0; > uint16_t array_size; > enum pipe_format format:16; /**< PIPE_FORMAT_x */ > enum pipe_texture_target target:8; /**< PIPE_TEXTURE_x */ > unsigned last_level:8; /**< Index of last mipmap level > present/defined */ > - unsigned nr_samples:8; /**< for multisampled surfaces, nr > of samples */ > - unsigned usage:8; /**< PIPE_USAGE_x (not a bitmask) */ > + /** Number of samples determining quality, driving > rasterizer, shading, > + * and framebuffer. > + */ > + unsigned nr_samples:8; > + > + /** Multiple samples within a pixel can have the same value. > + * nr_storage_samples determines how many slots for > different values > + * there are per pixel. Only color buffers can set this > lower than > + * nr_samples. > + */ > + unsigned nr_storage_samples:8; > + > + unsigned usage:8; /**< PIPE_USAGE_x (not a bitmask) */ > unsigned bind; /**< bitmask of PIPE_BIND_x */ > unsigned flags; /**< bitmask of > PIPE_RESOURCE_FLAG_x */ > /** > * For planar images, ie. YUV EGLImage external, etc, > pointer to the > * next plane. > */ > struct pipe_resource *next; > + /* The screen pointer should be last for optimal structure > packing. */ > + struct pipe_screen *screen; /**< screen that this texture > belongs to */ > }; > /** > * Transfer object. For data transfer to/from a resource. > */ > struct pipe_transfer > { > struct pipe_resource *resource; /**< resource to transfer > to/from */ > unsigned level; /**< texture mipmap level */ > > > > > > </div></div>> _______________________________________________ > mesa-dev mailing list > <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> > <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0&m=mT5z2nGhAlFu_lLjhtTx-Gb1xMAX_goZ2-tp5FknDXU&s=0NFDqBLa3wIUdtIkZ36Bfu2aZt31YbYQCjMl8BmV2K8&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0&m=mT5z2nGhAlFu_lLjhtTx-Gb1xMAX_goZ2-tp5FknDXU&s=0NFDqBLa3wIUdtIkZ36Bfu2aZt31YbYQCjMl8BmV2K8&e=</a> > </blockquote></div> </div></div></div>