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 <robdcl...@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 <mar...@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 <robdcl...@gmail.com> wrote: > >> > >> On Fri, Nov 30, 2018 at 3:25 PM Marek Olšák <mar...@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 < > hoegsb...@gmail.com> wrote: > >> >> > >> >> On Fri, Nov 30, 2018 at 10:17 AM Marek Olšák <mar...@gmail.com> > wrote: > >> >> > > >> >> > On Fri, Nov 30, 2018 at 1:13 PM Kristian Høgsberg < > hoegsb...@gmail.com> wrote: > >> >> >> > >> >> >> On Fri, Nov 16, 2018 at 7:48 PM Marek Olšák <mar...@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@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
