Bug 133848 - REQUEST: Skia Raster default for the initial release
Summary: REQUEST: Skia Raster default for the initial release
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Skia
  Show dependency treegraph
 
Reported: 2020-06-10 08:49 UTC by Telesto
Modified: 2020-06-15 14:40 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-06-10 08:49:54 UTC
Description:
Only a request/suggestion.. Please set Skia Raster default for initial release. Vulkan will generate quite a bunch of (driver related) crashes, I assume (based on my own experience).

So this will muddle the crash statistics for 7.0. So move it to 7.0.2 or so. Initial crash bugs squeezed and some reference of the other issues around.

Steps to Reproduce:
-

Actual Results:
-

Expected Results:
-


Reproducible: Always


User Profile Reset: No



Additional Info:
-
Comment 1 Miklos Vajna 2020-06-10 08:57:25 UTC
The tracker has 4 open bugs at the moment, while the total number of bugs in the tracker is 66. This sounds like a great ratio.

Also: similar to GL, the vulkan code is guarded with a watchdog, so if there is a driver bug, we can auto-disable as needed.

I would suggest to wait till you have data showing that unfixed vulkan problems cause a real trouble, and not do anything till then. Thanks.
Comment 2 Telesto 2020-06-10 09:26:48 UTC
(In reply to Miklos Vajna from comment #1)
> The tracker has 4 open bugs at the moment, while the total number of bugs in
> the tracker is 66. This sounds like a great ratio.

I'm not saying Skia is bad shape. It feels pretty decent. However the number of testers is limited of course.. And the lack of multitude of system configurations.

> Also: similar to GL, the vulkan code is guarded with a watchdog, so if there
> is a driver bug, we can auto-disable as needed.

I know.. but there the blacklist updated rather often.. And there where quite a number of driver related issues (Intel Drivers) with OpenGL enabled.. 

> I would suggest to wait till you have data showing that unfixed vulkan
> problems cause a real trouble, and not do anything till then. Thanks.

This is not about unfixed LibreOffice Vulkan issues. It's about the drivers causing the problem.. not LibreOffice itself. 

I'm having experience with a 'broken' driver issue.. It will 'pass' initial launch (so not forced).. It working fine.. until you hoover over a toolbar and you get a sudden exit. Calc/Writer/Draw it doesn't matter.. Even disabling 'Vulkan' after the first launch (clean profile) ends up with a crash the first time.. 

After the initial crash.. it will set back to 'Raster' and the issue is solved by itself (so don't expect to many bug reports in the bug tracker..)

So this is not about bad shape of Skia Vulkan.. but about being conservative.. And preventing an explosive crash stats ratio at the beginning of 7.0.. 

It's only intended as a recommendation.. To introduce Skia as smoothly as possible
Comment 3 Luboš Luňák 2020-06-10 11:17:51 UTC
I disagree. Later patchlevel releases are meant to be more stable than early x.y.0, so if this really would be a problem, later "more stable" releases would regress. IMO 7.0.0 is the right release to enable this, to catch these problems as early as possible with early adopters, before more serious adopters update to 7.0.2 or so.
Comment 4 Telesto 2020-06-10 11:47:25 UTC
(In reply to Luboš Luňák from comment #3)
> I disagree. Later patchlevel releases are meant to be more stable than early
> x.y.0, so if this really would be a problem, later "more stable" releases
> would regress. IMO 7.0.0 is the right release to enable this, to catch these
> problems as early as possible with early adopters, before more serious
> adopters update to 7.0.2 or so.

True, that is the other point of view.. OTOH, the majority of these type of issue appear around 7.0.5 as everybody steps in..

From (my) QA perspective. Splitting is more ideal IMHO. 7.0 will cause already an increase in reports without Skia Vulkan. So a delay would be welcome.. even if it is 7.0.1.. Based on the release principle 7.0 is the way to go.

There are of course a few step ahead B2 RC1/RC2/RC3.. so it's still possibility to evaluate..

However the release principle is only an ideal.. I only wanted to note that there are other considerations also (like QA capacity). 

But not sure what the general QA opinion is; I would prefer some delay. Even at the cost of (know) regress later on. Downside of course is that 'the early adapters' will run Raster all the time, even after an update with Skia Vulkan enabled by default (caused by profile setting)
Comment 5 V Stuart Foote 2020-06-10 12:30:38 UTC
The 'watchdog' and regular aging of the blacklist GPU/driver pairings will obscure the true numbers of folks with Skia Vulkan support issues--just as it did for OpenGL.

Crash/Fallback to Skia software rendering 'raster' would remain indistinguishable from blacklisted combinations, or user selections, on incoming crash reports.

Would say that because of the broader "marginal" support, the black listing for Skia needs to be more precise--each stanza including os build, GPU id, and Skia driver.

Aside from that, there is no compelling reason to release with Vulkan rendering disabled by default.

QA just has to keep an eye on Vulkan status as they parse reporting--just as with OpenGL (which is now fading away).
Comment 6 Xisco Faulí 2020-06-15 14:40:28 UTC
(In reply to Luboš Luňák from comment #3)
> I disagree. Later patchlevel releases are meant to be more stable than early
> x.y.0, so if this really would be a problem, later "more stable" releases
> would regress. IMO 7.0.0 is the right release to enable this, to catch these
> problems as early as possible with early adopters, before more serious
> adopters update to 7.0.2 or so.

Totally agree with Luboš here. The sooner we enable it the sooner we will fix the problems found so we arrive to 7.0.4 in good shape