<div dir="ltr"><div>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.</div><div> </div><div>Marek </div></div> <div class="gmail_quote"><div dir="ltr">On Fri, Nov 30, 2018 at 5:12 PM Rob Clark <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> 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 <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote: >> >> On Fri, Nov 30, 2018 at 3:25 PM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> 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 <<a href="mailto:hoegsberg@gmail.com" target="_blank">hoegsberg@gmail.com</a>> wrote: >> >> >> >> On Fri, Nov 30, 2018 at 10:17 AM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote: >> >> > >> >> > On Fri, Nov 30, 2018 at 1:13 PM Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com" target="_blank">hoegsberg@gmail.com</a>> wrote: >> >> >> >> >> >> On Fri, Nov 16, 2018 at 7:48 PM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> 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 >> > <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> >> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote></div>