what is DMSAA all about?

[zhou]

Hi, recently I notice that for path rendering in Skia, when hardware capability supports DMSAA, it would use those low level apis from DrawAtlasPathOp or PathTesselateOp instead of TriangulaingPathRender. 

Here DMSAA just means dynamic msaa? Like, in the past it only draws with a fixed sample count value for a color format when it supports MSAA. Now, a color format may have a table of all supported sample counts, like rgba8 format may support {1,2,4,8,16} sample counts. It would choose a proper sample count from the above table when drawing with different gpus. Is that right?

Thanks

[Greg Daniel]

The general idea is that instead of specifying a sample count for an SkSurface all surfaces just have a sample count of 1. However, internally we may do some draws using MSAA (like the path renderers you found). At the end of an MSAA pass of draws we will resolve the temporary MSAA buffer back into the single sampled surface. We have done work to make sure draws that do not require MSAA produce the same results whether or not MSAA is used internally so that the client doesn't see any popping.

If we are doing internal draws with MSAA we'll always pick the same sample count. We are not changing between {2, 4, 8, 16}. The dynamic in the naming is that we dynamically use/don't use msaa and not the sample count value itself.

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/f069ee6a-2a8e-43df-922f-05d1d0ff6949n%40googlegroups.com.

[zhou]

Thanks Greg!

Compared to the non-DMSAA path, DMSAA seem to be more efficiency for it only works on parts of all draw ops, for those ops really need to do MSAA. So, is it expected that we might see some performance improvements on those use cases where need to draw many paths or arcs?

Thanks

[Greg Daniel]

Compared to not using MSAA you will see a lot of performance improvement because we are able to use the fast MSAA algorithms for path draws. Compared to normal MSAA you should see possible memory improvements because we can use one (or just a few) MSAA buffers that are shared/reused for all draws that need MSAA. For normal MSAA mode each surface gets its own associated MSAA buffer. You may also get some memory/performance wins on platforms/apis that support memoryless textures (gl render to texture, vulkan lazy allocated memory, etc.) since we can simply discard all the memory after render passes and thus the gpu never needs to actually allocate real memory.

One caveat in using DMSAA is that we force all draws to be antialiased. This is because non-aa draws will look different depending on if we internally enabled msaa or not (they'll pop to being aa when the msaa is enabled).

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/3538f953-0bcb-4954-88b0-2a406c50a75dn%40googlegroups.com.

[Youfeng Hao]

Hi, I've found that coverage based anti alias use used if sample buffers are disabled, is it generally faster or slower than MSAA? 
Thanks. :)

[zhou]

According to the paper(link) from Nvidia,  CSAA is also extremely efficient in terms of storage, as the coverage samples require very little memory.

As for the speed, it should not be slower than MSAA since it is just a kind of MSAA.

[Youfeng Hao]

Our scenarios are mostly on mobile devices. I consulted Arm (link) and Qualcomm's documentation (link), both of which mentioned that on their Tile Based GPUs, 2x MSAA (or 4x MSAA on some hi-end devices) have almost no additional overhead. I'm not sure if this conclusion applies to desktop scenarios.

zhou <shuangsh...@intel.com> 于2023年5月31日周三 14:21写道：

You received this message because you are subscribed to a topic in the Google Groups "skia-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/skia-discuss/RcynJQaRryk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/5a84d3eb-2982-4828-9aff-b83b3bd22b4fn%40googlegroups.com.

--

郝有峰