[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