[Mesa-dev] [PATCH v2 2/5] gallium: Add new PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE

Kristian Høgsberg hoegsberg at gmail.com
Tue Nov 6 23:03:16 UTC 2018


On Tue, Nov 6, 2018 at 2:44 PM Axel Davy <davyaxel0 at gmail.com> wrote:
>
> Hi,
>
> Is there anything to be done in the nine state trackers (or other state
> trackers).
>
> Nine uses create_surface. Should it expect the field to be filled
> properly by the driver ?

Nothing is required from any state tracker, but if your API has an
extension like EXT_multisampled_render_to_texture, and the driver has
this new capability, you can set pipe_surface::nr_samples. The driver
will then render with that many samples internally and transparently
resolve the rendering to the (non-MSAA) resource.

> On 06/11/2018 23:09, Kristian H. Kristensen wrote:
> > +   /**
> > +    * If a driver doesn't advertise PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE,
> > +    * pipe_surface::nr_samples will always be 0.
> > +    */
> The above comment should be added to the comment below.
> > +   /** Number of samples for the surface.  This can be different from the
> > +    * resource nr_samples when the resource is bound using
> > +    * FramebufferTexture2DMultisampleEXT.
> > +    */
> > +   unsigned nr_samples:8;

Hm, I probably need to reword that a bit, since it implies the surface
sample count can be same as the resource, when it is only ever either
surface samples = 0 or surface samples > 1 with resource samples = 1.

Kristian

> > +
> >      union pipe_surface_desc u;
> >   };
> >
>
>
> Yours,
>
>
> Axel Davy
>
> _______________________________________________
> 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