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

[Marek Olšák]

I don't plan to expose the GCN functionality. If I wanted to, I would add
the sample count into the rasterizer state, because it only affects
gl_SampleMaskIn.

Marek

On Fri, Nov 30, 2018 at 5:12 PM Rob Clark <robdclark at gmail.com> wrote:

> I guess as long as it is just a single draw, it works out to the same
> thing.  Maybe to expose the GCN functionality we could do something
> like
>
>   PIPE_CAP_SURFACE_SAMPLE_COUNT:
>     0 - unsupported
>     1 - msaa per draw
>     2 - msaa per renderpass
>
> ??
>
> BR,
> -R
>
> On Fri, Nov 30, 2018 at 3:41 PM Marek Olšák <maraeo at gmail.com> wrote:
> >
> > GCN calls it overrasterization multisampling, but it's really only
> useful for polygon smoothing, because there is no temporary buffer.
> >
> > Marek
> >
> > On Fri, Nov 30, 2018 at 3:35 PM Rob Clark <robdclark at gmail.com> wrote:
> >>
> >> On Fri, Nov 30, 2018 at 3:25 PM Marek Olšák <maraeo at gmail.com> wrote:
> >> >
> >> > Suggestions:
> >> > - PIPE_CAP_TILED_BASED_MSAA_OVERSAMPLING
> >> > - pipe_surface::tile_based_oversample_count
> >> >
> >> > I'm assuming this feature isn't possible without tile-based rendering.
> >>
> >> I guess technically an IMR could do it, with an internal temporary
> >> buffer not visible to the state-tracker.  (Not sure I could come up
> >> with a reason *why* you'd want to do that, but...)
> >>
> >> BR,
> >> -R
> >>
> >> >
> >> > Marek
> >> >
> >> > On Fri, Nov 30, 2018 at 1:23 PM Kristian Høgsberg <
> hoegsberg at gmail.com> wrote:
> >> >>
> >> >> On Fri, Nov 30, 2018 at 10:17 AM Marek Olšák <maraeo at gmail.com>
> wrote:
> >> >> >
> >> >> > On Fri, Nov 30, 2018 at 1:13 PM Kristian Høgsberg <
> hoegsberg at gmail.com> wrote:
> >> >> >>
> >> >> >> On Fri, Nov 16, 2018 at 7:48 PM Marek Olšák <maraeo at gmail.com>
> wrote:
> >> >> >> >
> >> >> >> > I think the name PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE is
> slightly misleading, because it doesn't imply anything about the OpenGL ES
> behavior, which is that a texture is multisampled in the cache, but
> single-sampled in memory. This should be mentioned somewhere.
> >> >> >>
> >> >> >> Not sure exactly which change you're recommending, but in
> retrospect,
> >> >> >> I think it would be better to name the cap in term of how it
> changes
> >> >> >> the gallium API instead of the GLES extension it enables. How
> about
> >> >> >> PIPE_CAP_SURFACE_SAMPLE_COUNT, to indicate that it allows
> overriding
> >> >> >> sample counts in pipe_surface?
> >> >> >
> >> >> >
> >> >> > That's an interesting idea, but how does it convey that
> multisampled surfaces are never multisampled in memory?
> >> >>
> >> >> How are you going to convey all that in a cap enum name? In general,
> >> >> the cap names are concise hints and not super descriptive - you have
> >> >> to go read the documentation to understand the semantics.
> >> >>
> >> >> Do you have a specific name you'd like to see or can we go with
> >> >> PIPE_CAP_SURFACE_SAMPLE_COUNT?
> >> >>
> >> >> >
> >> >> > Marek
> >> >
> >> > _______________________________________________
> >> > mesa-dev mailing list
> >> > mesa-dev at lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181130/cae1a912/attachment-0001.html>