On Thu, Mar 24, 2016 at 8:11 PM, Edward O'Callaghan
<eocallag...@alterapraxis.com> wrote:
> Using PIPE_FORMAT_NONE to indicate what MSAA modes are supported
> with a framebuffer using no attachment.
>
> Signed-off-by: Edward O'Callaghan <eocallag...@alterapraxis.com>
> ---
> src/mesa/state_tracker/st_atom_framebuffer.c | 51
> ++++++++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c
> b/src/mesa/state_tracker/st_atom_framebuffer.c
> index ae883a2..07854ca 100644
> --- a/src/mesa/state_tracker/st_atom_framebuffer.c
> +++ b/src/mesa/state_tracker/st_atom_framebuffer.c
> @@ -64,6 +64,44 @@ update_framebuffer_size(struct pipe_framebuffer_state
> *framebuffer,
> framebuffer->height = MIN2(framebuffer->height, surface->height);
> }
>
> +/**
> + * Round up the requested multisample count to the next supported sample
> size.
> + */
> +static unsigned
> +framebuffer_quantize_num_samples(struct pipe_screen *screen, unsigned
> num_samples)
> +{
> + int quantized_samples = 0;
> + bool msaa_mode_supported;
> +
> + if (!num_samples)
> + return 0;
> +
> + assert(screen);
> +
> + /* Assumes the highest supported MSAA is x32 on any hardware */
> + for (unsigned msaa_mode = 32; msaa_mode >= 1; msaa_mode = msaa_mode/2) {
This should probably start at MaxFramebufferSamples right? Also
msaa_mode >= num_samples? [then you can get rid of the if below]
And lastly I don't know if it's a valid assumption that we can always
just divide by 2. That said, I don't know of any hw that actually
supports non-power-of-two MSAA levels, so perhaps it's OK.
> + assert(!(msaa_mode > 32 || msaa_mode == 0)); /* be safe from int
> overflows */
> + if (msaa_mode >= num_samples) {
> + /**
> + * For ARB_framebuffer_no_attachment, A format of
> + * PIPE_FORMAT_NONE implies what number of samples is
> + * supported for a framebuffer with no attachment. Thus the
> + * drivers callback must be adjusted for this.
> + */
> + msaa_mode_supported = screen->is_format_supported(screen,
> + PIPE_FORMAT_NONE, PIPE_TEXTURE_2D,
> + msaa_mode, PIPE_BIND_RENDER_TARGET);
> + /**
> + * Check if the MSAA mode that is higher than the requested
> + * num_samples is supported, and if so returning it.
> + */
> + if (msaa_mode_supported)
> + quantized_samples = msaa_mode;
> + }
> + }
> +
> + return quantized_samples;
> +}
>
> /**
> * Update framebuffer state (color, depth, stencil, etc. buffers)
> @@ -72,6 +110,8 @@ static void
> update_framebuffer_state( struct st_context *st )
> {
> struct pipe_framebuffer_state *framebuffer = &st->state.framebuffer;
> + struct pipe_context *pipe = st->pipe;
> + struct pipe_screen *screen = pipe->screen;
> struct gl_framebuffer *fb = st->ctx->DrawBuffer;
> struct st_renderbuffer *strb;
> GLuint i;
> @@ -82,6 +122,17 @@ update_framebuffer_state( struct st_context *st )
> framebuffer->width = UINT_MAX;
> framebuffer->height = UINT_MAX;
>
> + /**
> + * Quantize the derived default number of samples:
> + *
> + * A query to the driver of supported MSAA values the
> + * hardware supports is done as to legalize the number
> + * of application requested samples, NumSamples.
> + * See commit eb9cf3c for more information.
> + */
> + fb->DefaultGeometry._NumSamples =
> + framebuffer_quantize_num_samples(screen,
> fb->DefaultGeometry.NumSamples);
> +
> /*printf("------ fb size %d x %d\n", fb->Width, fb->Height);*/
>
> /* Examine Mesa's ctx->DrawBuffer->_ColorDrawBuffers state
> --
> 2.5.5
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
