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

[Marek Olšák]

On Tue, May 1, 2018 at 5:35 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:

> On 01.05.2018 01:43, Marek Olšák wrote:
>
>> From: Marek Olšák <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.
>> ---
>>   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.
>>
>
> The number of supported samples is currently only exposed via
> is_format_supported.
>
> 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?


Yes, this needs more thought.


>
>
>
>   * ``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.
>> +
>> +**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.
>>
>
> Why the last buller?
>

Because we can support N >= 2 coverage samples and 1 color sample.


>
> 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.
>

Yes.

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