On Tue, May 1, 2018 at 10:48 AM, Roland Scheidegger <[email protected]> wrote:
> Am 01.05.2018 um 01:43 schrieb Marek Olšák: > > 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. > > The idea sounds ok to me, as long as you don't expose the additional > modes with more samples as ordinary msaa modes. > (I'm quite sure at some point nvidia exposed 16x msaa modes through > ordinary means, which then gave you really 4 color samples and 12 > coverage-only samples, in some not-very-compliant way. Though IIRC the > extension is actually older than the ability to do per-sample msaa fb > reads, so it wasn't as problematic back then.) > > > --- > > 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. > I agree with Nicolai here, this looks strange, this should instead query > for total samples or something. > > > * ``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. > I think you should keep nr_samples alone, and re-change the meaning to > actually be "real" samples with all associated data (which is what > everybody expects with msaa). > > > + > > +**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. > > > Hence instead use something like "total_samples" or "coverage samples" > here (albeit the latter could be a bit confusing, unclear if it means > all samples or just the extra ones). > If you'd use something like "number of additional coverage samples" > instead, then you could even leave all state trackers alone, since 0 > would automatically mean ordinary msaa without crazy stuff. > And fwiw I'd stick to the CSAA name - coverage at least has some > meaning, whereas "enhanced" (which is what the "E" in EQAA is for > according to some old articles) really is just completely meaningless > marketing term. There really isn't any difference, ok the ability to use > different amount of samples per rt might be something, but you can't > expose this anyway (AMD didn't come up with an extension for this since > the 7+ years it's supported (since NI), so I have some doubts of its > usefulness - besides you could have another cap which then would say if > that's valid or not if you really come up with an extension specifically > for it.) > Unless there's some non-technical reasons you can't use the term CSAA. > EQAA is a superset of CSAA and is more complicated, so it doesn't make sense to use "CSAA". Marek
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
