On Tue, Nov 6, 2018 at 6:26 PM Roland Scheidegger <srol...@vmware.com> wrote: > > Am 07.11.18 um 00:03 schrieb Kristian Høgsberg: > > On Tue, Nov 6, 2018 at 2:44 PM Axel Davy <davyax...@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. > Wouldn't it be more logical if you rather adjust the code to match the > comment? That is, the surface would inherit the sample count of the > resource by default, but can be set to something different for this > extension.
Yeah, that should work. I wanted to avoid rewriting every gallium driver to look at surf->nr_samples instead of surf->texture->nr_samples, but since they're the same without the new cap, that shouldn't be necessary. > > > Kristian > > > >>> + > >>> union pipe_surface_desc u; > >>> }; > >>> > >> > >> > >> Yours, > >> > >> > >> Axel Davy > >> > >> _______________________________________________ > >> mesa-dev mailing list > >> mesa-dev@lists.freedesktop.org > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7Cbd68e613af17447b3eae08d6443c12d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636771422156943417&sdata=pji9JMcMB0DQyRIzske1nXJyCpneZ4RxITU9ov2A92o%3D&reserved=0 > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7Cbd68e613af17447b3eae08d6443c12d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636771422156943417&sdata=pji9JMcMB0DQyRIzske1nXJyCpneZ4RxITU9ov2A92o%3D&reserved=0 > > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
