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
- Re: Building skia with clang(-cl) (continued)
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.