Description: [META] Skia library bugs Let's collect here all Skia's bugs Lubus, I CCed you to this META Steps to Reproduce: - Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info: -
For the record, here's the announcement: https://lists.freedesktop.org/archives/libreoffice/2019-November/083878.html For now Skia can be enabled by setting the following environment variable: SAL_ENABLESKIA=1 And it's only enabled for X11 'gen' and Windows VCL backends.
Folks, when posting issues against Skia rendering (Vulkan h/w, or software only), please post GPU and driver details for your system On Windows systems, os GPU and driver details can be found in a run of msinfo32.exe OS and system hardware on the system summary. GPU hardware and driver on the components -> display tab Simple select and copy/paste. This will be needed to work out blacklist for Skia rendering. Thanks! Stuart
For maintaining a blacklist of GPU and Vulkan driver pairings, will need the Vulkan reported 'deviceID', 'vendorID' and 'driverVersion' -- these will not be the same as the os reported GPU and Driver details we'd used for OpenGL issues. At the moment, they are not exposed for review from the LO Skia implementation. The realtechVR OpenGL Extensions Viewer [1] now provides a reporting module for Vulkan resources. After a run of rendering testing, clicking the submit button will generate a set of feature reports, including a "vkview" report that has the GPU's internal Vulkan details. Those will be needed when reporting issues for potential Blacklisting. =-ref-= [1] http://www.realtech-vr.com/home/glview
(In reply to V Stuart Foote from comment #3) > For maintaining a blacklist of GPU and Vulkan driver pairings, will need the > Vulkan reported 'deviceID', 'vendorID' and 'driverVersion' -- these will not > be the same as the os reported GPU and Driver details we'd used for OpenGL > issues. > > At the moment, they are not exposed for review from the LO Skia > implementation. > > The realtechVR OpenGL Extensions Viewer [1] now provides a reporting module > for Vulkan resources. After a run of rendering testing, clicking the submit > button will generate a set of feature reports, including a "vkview" report > that has the GPU's internal Vulkan details. Those will be needed when > reporting issues for potential Blacklisting. > > =-ref-= > [1] http://www.realtech-vr.com/home/glview Lubos added (https://gerrit.libreoffice.org/c/core/+/91980) this: "So just dump the info to <cachedir>/skia.log (where on Windows the <cachedir> should be AppData\Roaming\LibreOffice\4\cache)." I think we should say to bugreporters just to give us info from that file if they wrote a skia bug reprot
Both ways are acceptable as long as they provide the necessary Vulkan information and not things like the marketing version numbers.
Since version 7.6 and the fix for bug 155070, the Skia log can be copied from Tools ▸ Options... ▸ LibreOffice ▸ View.
LO is under Windows 11 unusable for me and many others. Works fine under Linux, but not under Windows. Comment of Google AI, quote: "The outcome of the discussions In community forums and Reddit channels (such as recent Windows 10/11 troubleshooting threads), complaints are piling up from users whose menus under Windows either do not open at all or react with massive delays because they can no longer disable Skia through regular settings. The "Expert Configuration" workaround is currently the only unofficial way to save Windows systems from this engine." That was also my experience. I disabled Skia and then it works. Incomprehensible! And Google AI further: "A key reason why developers completely grayed out the option to disable Skia in newer versions is outlined in Bug 166932, among other places. The problem: Once users moved away from the classic menu to use more modern interfaces (such as the tabbed UI similar to MS Office), disabling Skia resulted in immediate, reproducible crashes when opening documents. The (drastic) solution: Instead of painstakingly patching the bugs in the legacy code that ran without Skia, the developers blocked the ability to turn off the engine via the standard menu in newer versions. Essentially, the attitude was: "If it crashes without Skia, we’ll just force everyone to use it." And "At its core, LibreOffice is developed by programmers who themselves work almost exclusively on Linux. On Linux, Skia runs via different interfaces (usually Vulkan or directly via X11/Wayland) and rarely causes issues there. Windows-specific quirks (such as the interaction with DirectX or Direct2D) are often overlooked during testing. 2. Ignoring the reality of the majority The criticism that it is ignorant to force such an error-prone feature on Windows by default—and even gray out the option to disable it—is absolutely justified. Instead of making Skia optional (as was previously the case with OpenGL), the decision was made: "Skia is the future, so everyone has to use it." The fact that millions of Windows users rely on office PCs or laptops with standard graphics chips—rather than high-end graphics cards—was simply ignored. For many users, this has made LibreOffice painfully slow, until they—just like you—manage to find the hidden switch in the expert configuration settings. In any case, you have now found the perfect setting for your system. Since you work extensively with very long documents (180 pages): Are there any other aspects of LibreOffice Writer that currently annoy you or slow you down? I’d be happy to show you, for example, how to increase the memory allocated for images or adjust the automatic spell-checking to ensure the program runs more stably with large files." Is this really true?
(In reply to R. Grafe from comment #7) > LO is under Windows 11 unusable for me and many others. Works fine under > Linux, but not under Windows. > ... > That was also my experience. I disabled Skia and then it works. > Incomprehensible! Absolutely false FUD! That bug 166932 was an issue with specific formatted document when opened with GDI+ rendering that exhausted GDI object handles. To resolve, filtering for the Style objects was changed. It had nothing to do with skia libs (Vulkan or fall back CPU raster rendering) which at that point was an alternative rendering mode. At the 26.2 release, the deprecated GDI+ rendering paths were removed [1]. This was necessary for feature implementation of correct alpha channel color rendering that neither GDI+ on Windows, nor aqua on macOS could process. So it is legacy GDI+ rendering that is no longer present, but few users were actually using legacy GDI+ rendering paths with skia lib based rendering set disabled. Simply at this point skia graphics libs can not be fully "disabled", and activating legacy GDI+ rendering paths, they've been removed from source. Skia Vulkan/Metal accelerated hw rendering has been set enabled by default since implemented in 2020 at the 7.0 release (replacing Cairo lib tooling with skia lib), and *Vulkan is what causes* the LibreOffice issue for folks with marginal hardware and driver configurations. But, as with prior OpenGL hw accelerated rendering, the skia lib based Vulkan hw acceleration can be toggled enabled or disabled. Done by user action (from UI or in config file), or LibreOffice graphics test, or by deny list processing. LibreOffice implements graphics functional testing on startup, and a deny listing registry, to force marginal systems fallback to skia CPU software rendering. The "fallback" skia lib based CPU software rendered raster framing is much less sensitive to poorly supported GPU or outdated graphics drivers, and that keeps those systems functional. Users can force skia CPU software rendering via the expert config stanza 'ForceSkiaRaster' set "true". Alternatively they can add the stanza in their per user LibreOffice profile "registrymodifications.xcu". A simple copy and paste of this stanza to the bottom of the .xcu will suffice: <item oor:path="/org.openoffice.Office.Common/VCL"><prop oor:name="ForceSkiaRaster" oor:op="fuse"><value>true</value></prop></item> The project has discussed setting the skia lib default rendering mode to non-accelerated CPU rendering; but consensus remains that keeping Vulkan hw accelerated rendering as default is more beneficial (it keeps the rendering most performant, and fosters the deny list process). Folks experiencing issues with LO start-up or specific UI rendering issues remain encouraged to submit well described BZ issues. =-ref-= [1] See https://gerrit.libreoffice.org/c/core/+/186250 (macOS) or https://gerrit.libreoffice.org/c/core/+/187176 (win)
What are the requirements for a Windows device to ensure that SKIA-HWRendering works properly? These requirements would certainly be helpful, especially for government organizations and companies that use LibreOffice with windows.
In reply to comment 8 I tested a little bit before I have read your post. Suddenly LO was slow again with disabled Skia, seems not so slow as before disabling Skia, but slow start and very slow starting menus. Then I set UseSkia back to true again and also ForceSkiaRaster to true and now it runs good. No problems. Seems really ForceSkiaRaster is the solution? But in internet most tips are always "disable Skia", sorry for my comment (7). At administration: you can delete my first comment (7) here, if you want. --- CPU Typ Mobile QuadCore AMD Ryzen 5 3500U, 3700 MHz (37 x 100) RAM 16GB Graphics AMD Radeon(TM) Vega 8 Graphics (2 GB)
And my post comment 7 was no FUD! It was the experience of a no-pro and also many (!) others who had problems with LO speed under Windows an get no easy help! It's not my fault!
And I'm really angry for the badge "FUD", really. Think over it and over slow LO in many cases with your project team!
(In reply to R. Grafe from comment #12) > And I'm really angry for the badge "FUD", really. Think over it and over > slow LO in many cases with your project team! Sorry, it was the very definition of a FUD post--incorrect facts, and casting doubt. Fear, Uncertainty, and Doubt... Where in truth, LibreOffice offers functional rendering using industry standard skia lib based interface to os supported GPU drivers, either the fallback (e.g. lower performance but more hw stable) CPU raster framing or the default (and preferred) Vulkan/Metal GPU hw accelerated rendering. The project publishes documentation and operates the Discourse based ASK instance for User Help, while this BZ is here for issue reporting and QA. Posting poorly described and non-factual rant to this META tracker for skia realted issues was not really helpful. I'll mark this off-topic and will obsolete the earlier post if you like.
(In reply to Michael H from comment #9) > What are the requirements for a Windows device to ensure that > SKIA-HWRendering works properly? These requirements would certainly be > helpful, especially for government organizations and companies that use > LibreOffice with windows. That is a moving target isn't it? LibreOffice updates the skia milestone build to remain current with skia projects Chromium release. But each installation of LibreOffice then relies on the combination of graphics processor and driver that os/DE is providing. And in the case of Windows, the WDDM of the Windows release impacts things further. Ending up with WDDM 2.7 Win10 drivers on a 25H2 build of Win11 is a proven recipe for Vulkan hw accelerated rendering to choke. So I would generically say, on Win10 systems be sure you have the latest WDDM 2.7 driver for the GPU. While on Win11 systems (24H2 or 25H2) be sure you have at least a WDDM 3.1 compliant driver installed and active for the GPU. Simple run of dxdiag.exe will display details of what is installed and active on the Win os.
Sorry for my previous posts, would prefer you could delete them all. 1. Now I disabled ForceSkiaRaster again for testing and I can see no difference. It's like a ghost in the machine, but there is no virus or something else, it's only LO making a fool of me. I'm sure, you know such situations. I had no explanation anymore, maybe (my) rather naked Windows doesn't like LO, maybe rare problems within LO with some hardware drivers (see below) or something else? It seems to me, many others have the same or similar problems. I'm a little bit frustrated, but I give it up. LO is on this old computer only for testing purposes, under my new with Linux it runs out of the box fast, but have no long time experience, only in my short tests, will see. It seems, most problems with speed of LO on my old computer with Windows appear by and after using the menu Tools -> Customizing / Options. Maybe a hint for you. Under Windows LO plays only a minor role anyway. Most people have at least an old MS Office version and use this. 2.Now I have read your comment 14. Means this, LO under Windows ist depending always on actual WDDM drivers? Mine ist 2.6, I think, there are no actual graphics drivers, that support newer WDDM. Has this to do with my problems? I will not belief this. Sorry again for my inconvenience.
My solution at the moment: Enabled ForceSkiaRaster Important: After each change in LO start OS new, that was my fault in previous post. No LO process in taskmanager, but maybe something remains in windows cache, I think, and despite that I have disabled such behaviour as far as possible. Maybe it would be helpful when after installation of LO a clearly hint would given for enabling ForceSkiaRaster when LO menus run slow because of lacking hardware acceleration support on older machines? For new users of LO on windows it is surely frustrating, when they install LO based on recommendation and then LO runs slow in comparison to other software. The consequence could be, they go immediately back to MSO or install other Office SW and additionally this damages unnecessarily the reputation. That's why I posted my first comment above, it's frustrating when you always here from open source supporters, "use LO" and you make then right at the beginning a disappointing experience. This should not be. -- LO 26.2 (no hardware acceleration, greyed out ->) Windows 23H2, nearly naked with many portable SW, runs very fast, no problems with other software WDDM 2.6, no graphics driver update possible CPU Typ Mobile QuadCore (8 threads) AMD Ryzen 5 3500U, 3700 MHz RAM 16GB AMD Radeon(TM) Vega 8 Graphics (2 GB of RAM)
Like OpenGL before, skia/ganesh Vulkan tooled rendering is being deprecated. LibreOffice had used the skia/ganesh Vulkan tooling, and the chromium project has deprecated ganesh in favor of more robust and multi-threaded graphite tooling--the hw accelerated rendering that chrome uses on Windows builds. So, for the 26.2.5 [1] release and the 26.8.0 [2] release, Vulkan hw rendering will be placed under user experimental feature (Tools -> Options -> Advanced "Enable experimental features") with defaults now shifted onto skia / CPU raster framing. While on master, toward the 27.2 release [3] , the default will be skia / CPU raster framing with a new UI checkbox toggle (Tools -> Options -> View 'ForceSkiaGPU') to enable skia / ganesh Vulkan tooling. Some dev discussion of pursuing a skia/graphite Vulkan tooling to track with chromium skia offerings, or possibly a move on Windows builds to skia/D3D12 as a bridge. Thanks Xisco for giving this a tweak! It should help stabilize folks on marginal hw with balky drivers while others can continue with Vulkan acceleration. Just hope we can stir up some additional dev interest to move the skia hw accelerated rendering onward to refactor with graphite. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/208146 [2] https://gerrit.libreoffice.org/c/core/+/208133 [3] https://gerrit.libreoffice.org/c/core/+/208148
(In reply to R. Grafe from comment #16) > > LO 26.2 (no hardware acceleration, greyed out ->) > Windows 23H2, nearly naked with many portable SW, runs very fast, no > problems with other software > WDDM 2.6, no graphics driver update possible > CPU Typ Mobile QuadCore (8 threads) AMD Ryzen 5 3500U, 3700 MHz > RAM 16GB > AMD Radeon(TM) Vega 8 Graphics (2 GB of RAM) Interesting, a check on the AMD site suggests that Ryzen 5 3500U APU is supported by the Adrenalin Edition driver suite through WDDM 3.2, so should support WDDM 3.1 on your win11 23H2 system (though I would update the os). Current 26.5.2 WHQL drivers for your hw and os are [1]. And this page from AMD details the Vulkan feature support implemented at each release. [2] =ref-= [1] https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-5-3500u.html [2] https://www.amd.com/en/resources/support-articles/release-notes/RN-RAD-WIN-VULKAN.html
You are right, my fault, shame on me. I forgot, that I deinstalled Adrenalin Drivers a view months ago, because of no need, it's only a office computer, no need for games or video editing. I thought, delivered windows 11 drivers in core would be enough, made a research and could not find any arguments against deleting in this case. I also thought, only additional Adrenalin UI and features would gone, not the driver itself. I wanted to clean up the computer totally for special purposes. Runs very fast for my purposes, faster than my newer under Windows 11 25H2, but now with Linux :-). OK, no hardware acceleration. It's the first time I run into this problem. I will test it again.
(In reply to V Stuart Foote from comment #17) Puuh, after all, anyway not my fault, I'm happy. My research was right. Please set comment 19 to hidden. Radeon(TM) Vega 8 Graphics was still installed, only not to see in windows system settings, but in hardware manager. AMD Driver (old from 2019) https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-5-3500u.html#amd_support_product_spec installed new, but updated (only) WDDM from 2.6 to 3.1 (strange, why so old on mine). Anyway no hardware acceleration. Google AI says, there ist no hw acceleration for this integrated GPU in Ryzen 5 3500U. Update to Windows 25H2 therefore senseless and not desired anyway because this computer get's no more updates from M$. And yes, you can use it safely also in the internet, if you know, what to configure and what points you have to consider ;-)
(In reply to R. Grafe from comment #20) >... >Anyway no hardware acceleration. Google AI says, there ist no hw acceleration >for this integrated GPU in Ryzen 5 3500U. >... OK, well not so sure about that. But the tweaks to rendering defaults noted comment 17 should give relief to users for the 26.2.5 and future builds.
The graphics should support Vulcan, shows GPU-Z, but it isn't. No hints anywhere in the net, no helpful tips by AI. Your announced changes in new version is the right solution. I hope my annoying comments here could help ;-) (Advocatus Diaboli) Best regards.
(In reply to V Stuart Foote from comment #21) I forgot in addition to my comment 22: Thank you and the LO team very much - I believe, in the name of all (new) LO users with older CPU / APU.
(In reply to V Stuart Foote from comment #21) I tested again, disabled ForceSkiaRaster again - and what a surprise - no difference, fast as before after restart. Opening skia.log: RenderMethod: vulkan Vendor: 0x1002 Device: 0x15d8 API: 1.3.260 Driver: 2.0.279 DeviceType: integrated DeviceName: AMD Radeon(TM) Vega 8 Graphics Denylisted: no But Checkbox Hardware Acceleration still greyed out. Anyway, your solution in comment 17 is the best.