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

[Marek Olšák]

On Thu, May 24, 2018 at 4:11 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:

> On 18.05.2018 06:05, Marek Olšák wrote:
>
>> From: Marek Olšák <marek.olsak at amd.com>
>>
>> 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
>>
>
> I like it, but you probably want to be explicit about what happens with
> multiple color attachments, both for samples and for storage samples.
>

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:

* ``PIPE_CAP_FRAMEBUFFER_MSAA_CONSTRAINTS``: This determines limitations
  on the number of samples that framebuffer attachments can have.
  Possible values:
    0: color.nr_samples == zs.nr_samples == color.nr_storage_samples
       (standard MSAA quality)
    1: color.nr_samples >= zs.nr_samples == color.nr_storage_samples
       (enhanced MSAA quality)
    2: color.nr_samples >= zs.nr_samples >= color.nr_storage_samples
       (full flexibility in tuning MSAA quality and performance)
  All color attachments must have the same number of samples and the same
  number of storage samples.

Most drivers will report 0. NV can report 1. AMD will report 2.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180524/9ad99e46/attachment.html>