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

Marek Olšák maraeo at gmail.com
Tue May 1 20:54:00 UTC 2018


On Tue, May 1, 2018 at 10:51 AM, Axel Davy <davyaxel0 at gmail.com> wrote:

> Hi,
>
>
> 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.
>>   * ``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.
>>     **usage** one of the :ref:`PIPE_USAGE` flags.
>>     **bind** bitmask of the :ref:`PIPE_BIND` flags.
>>     **flags** bitmask of PIPE_RESOURCE_FLAG flags.
>>
>>
> To remove ambiguity, I'd suggest have both nr_coverage_samples and
> nr_zsc_samples (for Z/S + color)
> which would have to be equal if EQAA is not supported.
>
> I guess there's going to be constraints on the combination of the values
> of these two.
> I'm not sure the proposed cap is sufficient.
> If CSAA has more constraints than EQAA, are these constraints respected
> with the proposed system ?


This is for EQAA, not CSAA, but the interface will support CSAA too.


>
>
>       resource_changed
>> diff --git a/src/gallium/include/pipe/p_defines.h
>> b/src/gallium/include/pipe/p_defines.h
>> index c4ae0532060..97e1a3a3d42 100644
>> --- a/src/gallium/include/pipe/p_defines.h
>> +++ b/src/gallium/include/pipe/p_defines.h
>> @@ -783,20 +783,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_EQAA_COLOR_SAMPLE_SUPPORT_MASK,
>>      PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET,
>>      PIPE_CAP_CONTEXT_PRIORITY_MASK,
>>      PIPE_CAP_FENCE_SIGNAL,
>>      PIPE_CAP_CONSTBUF0_FLAGS,
>>      PIPE_CAP_PACKED_UNIFORMS,
>>   };
>>     /**
>>    * Possible bits for PIPE_CAP_CONTEXT_PRIORITY_MASK param, which should
>>    * return a bitmask of the supported priorities.  If the driver does not
>> diff --git a/src/gallium/include/pipe/p_state.h
>> b/src/gallium/include/pipe/p_state.h
>> index 4dce399f848..4010b92e67b 100644
>> --- a/src/gallium/include/pipe/p_state.h
>> +++ b/src/gallium/include/pipe/p_state.h
>> @@ -503,41 +503,42 @@ 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 nr_color_samples:8; /**< Number of color samples for EQAA. */
>>      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;
>> +   struct pipe_screen *screen; /**< screen that this texture belongs to
>> */
>>
>
> Out of curiosity, why moving this field ?
>

So that the size of the structure doesn't change.

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


More information about the mesa-dev mailing list