[Mesa-dev] [RFC PATCH] gallium: add interface for EQAA
Roland Scheidegger
sroland at vmware.com
Tue May 1 15:29:29 UTC 2018
Am 01.05.2018 um 16:51 schrieb Axel Davy:
> 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.
>From what I remember, I don't think there's additional constraints,
albeit I'd suppose something like 16 coverage samples and 1 color/z
sample wouldn't make a whole lot of sense (1 sample is always weird for
multisampling anyway). There's lots of different "nr of samples" values,
and they can be programmed independently:
- rasterization samples
- sample mask in (and out) samples (I think they can be different to
rasterization samples too, albeit I'm not sure that's useful at least
for the in mask - I'd think you'd use overrasterization precisely so you
get all the rasterization samples in the sample mask input)
- exported samples (hw supports 16 IIRC)
- exported "real" samples (the color and z values) - must be smaller or
equal to exported samples, and the hw supports a max of 8
- pixel shader frequency (running at sample frequency or below)
...
Although I suppose the number of samples used for rasterization should
be the highest always, not sure what will happen otherwise...
But I wouldn't know if nvidia hw also has no additional restrictions on
the number of coverage and real samples combinations.
Roland
> If CSAA has more constraints than EQAA, are these constraints respected
> with the proposed system ?
>
>> 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 ?
>
> Yours,
>
> Axel Davy
>
>> };
>> /**
>> * Transfer object. For data transfer to/from a resource.
>> */
>> struct pipe_transfer
>> {
>> struct pipe_resource *resource; /**< resource to transfer
>> to/from */
>> unsigned level; /**< texture mipmap level */
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
More information about the mesa-dev
mailing list