<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 1, 2018 at 5:35 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01.05.2018 01:43, Marek Olšák wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Marek Olšák <<a href="mailto:marek.olsak@amd.com" target="_blank">marek.olsak@amd.com</a>><br>
<br>
This is a hypothetical interface for EQAA (a superset of CSAA). CSAA could be<br>
exposed via GL_NV_framebuffer_multisample_<wbr>coverage. EQAA additionally removes<br>
the restriction that the number of samples in all FBO attachments must match,<br>
which means it allows arbitrary sample counts in each FBO attachment.<br>
---<br>
src/gallium/docs/source/screen<wbr>.rst | 17 +++++++++++++++--<br>
src/gallium/include/pipe/p_def<wbr>ines.h | 1 +<br>
src/gallium/include/pipe/p_sta<wbr>te.h | 3 ++-<br>
3 files changed, 18 insertions(+), 3 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 3837360fb40..28934c2f7b9 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,22 @@ 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_EQAA_COLOR_SAMPLE_S<wbr>UPPORT_MASK``: If the i-th bit is set, EQAA<br>
+ supports (i+1) color samples.<br>
</blockquote>
<br></div></div>
The number of supported samples is currently only exposed via is_format_supported.<br>
<br>
If there is hardware that supports more coverage samples than color samples, this interface wouldn't allow us to expose this fact, so it seems like perhaps the cap should be for the number of supported coverage samples instead?</blockquote><div><br></div><div>Yes, this needs more thought.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* ``PIPE_CAP_SIGNED_VERTEX_BUFFE<wbr>R_OFFSET``:<br>
Whether pipe_vertex_buffer::buffer_off<wbr>set is treated as signed. The u_vbuf<br>
module needs this for optimal performance in workstation applications.<br>
* ``PIPE_CAP_CONTEXT_PRIORITY_MA<wbr>SK``: For drivers that support per-context<br>
priorities, this returns a bitmask of PIPE_CONTEXT_PRIORITY_x for the<br>
supported priority levels. A driver that does not support prioritized<br>
contexts can return 0.<br>
* ``PIPE_CAP_FENCE_SIGNAL``: True if the driver supports signaling semaphores<br>
using fence_server_signal().<br>
* ``PIPE_CAP_CONSTBUF0_FLAGS``: The bits of pipe_resource::flags that must be<br>
@@ -743,22 +745,33 @@ Modern APIs allow using buffers as shader resources.<br>
(1 for 1D or 1D array textures).<br>
**depth0** the depth of the base mip level of the texture<br>
(1 for everything else).<br>
**array_size** the array size for 1D and 2D array textures.<br>
For cube maps this must be 6, for other textures 1.<br>
**last_level** the last mip map level present.<br>
-**nr_samples** the nr of msaa samples. 0 (or 1) specifies a resource<br>
-which isn't multisampled.<br>
+**nr_samples**: For Z/S, this is the number of samples. For color, if EQAA<br>
+is unsupported, this is the number of both coverage samples and color samples.<br>
+If EQAA is supported, this is the number of coverage samples. 0 and 1<br>
+specify a resource which isn't multisampled.<br>
+<br>
+**nr_color_samples**: This is the number of color samples for EQAA, while<br>
+``nr_samples`` is the number of coverage samples. If the format is Z/S,<br>
+``nr_color_samples`` is ignored. Constraints:<br>
+* ``nr_color_samples`` must not be greater than ``nr_samples``.<br>
+* If ``nr_color_samples`` is equal to ``nr_samples``, it is called MSAA.<br>
+* If ``nr_color_samples`` is less than ``nr_samples``, it is called EQAA.<br>
+* If ``nr_color_samples`` is equal to 1, the behavior of the resolve blit is<br>
+driver-dependent.<br>
</blockquote>
<br></div></div>
Why the last buller?<br></blockquote><div><br></div><div>Because we can support N >= 2 coverage samples and 1 color sample.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, are all state trackers expected to set nr_color_samples correctly? This probably only affects nine, but still, it needs to be kept in mind.<br></blockquote><div><br></div><div>Yes.<br><br></div><div>Marek<br></div></div><br></div></div>