On Tue, May 1, 2018 at 5:35 AM, Nicolai Hähnle <[email protected]> wrote:
> On 01.05.2018 01:43, Marek Olšák wrote: > >> From: Marek Olšák <[email protected]> >> >> 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
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
