Date: prev next · Thread: first prev next last
2020 Archives by date, by thread · List index


On Monday 08 of June 2020, Stephan Bergmann wrote:
On 23/04/2020 11:46, Miklos Vajna wrote:
In short, I would like to hear what others think about using clang(-cl)
for building skia.

Why? See this video from Lubos, showing skia raster performance on
Windows: <https://youtu.be/iSo4wVtGQ2A>. Above is clang-cl, below is
MSVC. The reason for the difference is that skia developers focus on
good performance with clang, so building their codebase with gcc or msvc
works, but the result is not as great as it could be. This would be the
benefit.

FYI,
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.or
g/message/HWBXFXPFNNPZSB3OYW6DUKZUDSSGZJ7H/> "Re: Fedora 33 System-Wide
Change proposal: CompilerPolicy Change":  "If I understand the LO case, it
...
So at least for GCC the performance degradation when building skia with
anything but Clang might eventually get addressed.

 In the specific case I saw (fmin/fmax), GCC can actually already perform more 
or less the same, if it gets -ffinite-math-only (without it GCC is not smart 
enough to optimize "fmax(0,fmin(1,x))"). I didn't look into the issues in 
that much detail though.

 But as long as Skia is used only by VCL gen backend this really doesn't 
matter in practice. We could probably even default to --disable-skia on Linux 
and it wouldn't make much of a difference for users.

-- 
 Luboš Luňák
 l.lunak@collabora.com

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.