<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 24, 2018 at 4:11 AM, Nicolai Hähnle <span dir="ltr"><<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On 18.05.2018 06:05, Marek Olšák wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
From: Marek Olšák <<a href="mailto:marek.olsak@amd.com" target="_blank">marek.olsak@amd.com</a>><br>
<br>
The interface only uses general MSAA terms, so it's "advanced MSAA" and not<br>
something vendor-specific.<br>
<br>
It's a proper subset of EQAA, and a proper superset of CSAA, so it's neither.<br>
<br>
Changes:<br>
- pipe_resource is changed<br>
- is_format_supported is changed<br>
- a new CAP is added<br>
---<br>
src/gallium/docs/source/screen<wbr>.rst | 31 ++++++++++++++++++++++++++--<br>
src/gallium/include/pipe/p_def<wbr>ines.h | 1 +<br>
src/gallium/include/pipe/p_scr<wbr>een.h | 1 +<br>
src/gallium/include/pipe/p_sta<wbr>te.h | 18 +++++++++++++---<br>
4 files changed, 46 insertions(+), 5 deletions(-)<br>
<br>
diff --git a/src/gallium/docs/source/scre<wbr>en.rst b/src/gallium/docs/source/scre<wbr>en.rst<br>
index 5bc6ee99f08..cf4787a1c49 100644<br>
--- a/src/gallium/docs/source/scre<wbr>en.rst<br>
+++ b/src/gallium/docs/source/scre<wbr>en.rst<br>
@@ -398,20 +398,25 @@ The integer capabilities:<br>
* ``PIPE_CAP_LOAD_CONSTBUF``: True if the driver supports TGSI_OPCODE_LOAD use<br>
with constant buffers.<br>
* ``PIPE_CAP_TGSI_ANY_REG_AS_ADD<wbr>RESS``: Any TGSI register can be used as<br>
an address for indirect register indexing.<br>
* ``PIPE_CAP_TILE_RASTER_ORDER``<wbr>: Whether the driver supports<br>
GL_MESA_tile_raster_order, using the tile_raster_order_* fields in<br>
pipe_rasterizer_state.<br>
* ``PIPE_CAP_MAX_COMBINED_SHADER<wbr>_OUTPUT_RESOURCES``: Limit on combined shader<br>
output resources (images + buffers + fragment outputs). If 0 the state<br>
tracker works it out.<br>
+* ``PIPE_CAP_FRAMEBUFFER_MIXED_S<wbr>AMPLES``: Framebuffer attachments can have<br>
+ different number of samples each with the following restriction:<br>
+ color.nr_samples >= zs.nr_samples >= color.nr_storage_samples<br>
+ If 0 is returned, the following restriction applies:<br>
+ color.nr_samples == zs.nr_samples >= color.nr_storage_samples<br>
</blockquote>
<br></div></div>
I like it, but you probably want to be explicit about what happens with multiple color attachments, both for samples and for storage samples.<br></blockquote><div><br></div><div>Good point. While we could be flexible here, it's not so useful to have different number of samples and storage samples in color attachments. This is the latest version of the CAP:</div><div><br></div>* ``PIPE_CAP_FRAMEBUFFER_MSAA_CONSTRAINTS``: This determines limitations<br> on the number of samples that framebuffer attachments can have.<br> Possible values:<br> 0: color.nr_samples == zs.nr_samples == color.nr_storage_samples<br> (standard MSAA quality)<br> 1: color.nr_samples >= zs.nr_samples == color.nr_storage_samples<br> (enhanced MSAA quality)<br> 2: color.nr_samples >= zs.nr_samples >= color.nr_storage_samples<br> (full flexibility in tuning MSAA quality and performance)<br> All color attachments must have the same number of samples and the same<br> number of storage samples.<br><br><div>Most drivers will report 0. NV can report 1. AMD will report 2.</div><div><br></div><div>Marek<br></div></div></div></div>