[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