Created attachment 151692 [details]
WinDbg stack trace of crash with OpenGL enabled, TB39 symbols

WinDbg stack trace attached

And, here is OpenGL log:
DriverVersion: 26.20.100.6861
DriverDate: 4-30-2019
DeviceID: PCI\VEN_8086&DEV_5916&SUBSYS_39FD17AA&REV_02
AdapterVendorID: 0x8086
AdapterDeviceID: 0x5916
AdapterSubsysID: 0x39fd17aa
DeviceKey: System\CurrentControlSet\Control\Video\{E640B70C-11DA-11E9-9437-DABE921972A4}\0000
DeviceString: Intel(R) HD Graphics 620

Crash with OpenGL rendering noted with "simple" transitions: "wipe" and "dissolve" and with GL "iris", "vortex" and "ripple"

Hmm, this is looking like an issue with the Intel OpenGL support for this GPU/driver -- 26.20.100.6861. And not related to the recent epoxy update for bug 124942

Going back to TB dailys on hand using this GPU/driver pair was already crashing.

crahing master Version: 6.3.0.0.alpha0+ (x64)
Build ID: 13a260f59e421f3e67845f8f2eb22b8f0f8fcaf0
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-11_02:46:09
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

as does release build 6.2.3.2, which crashes the same with this GPU/driver pair.

An install of 5.3.7.2 does not crash, but the canvas preview for the GL transitions are blacked out, and GUI loses many of its controls on ending the Impress session.

Setting this back to medium - normal, as this looks to be Windows only? And is driver based and needing a blacklist unless something obvious comes out of the stack trace.

caolanm->julien: Looking at vcl/opengl/opengl_blacklist_windows.xml I see you added blacklist entries for various Intel HD Graphics 630 variants. This is a 620, it is plausible that 620s should be blacklisted too ?

(In reply to Caolán McNamara from comment #4)
> caolanm->julien: Looking at vcl/opengl/opengl_blacklist_windows.xml I see
> you added blacklist entries for various Intel HD Graphics 630 variants. This
> is a 620, it is plausible that 620s should be blacklisted too ?

I'm not expert but yes it could be, I can submit a patch after my day time job to blacklist 620s.
Each time I see a similar case, I'm asking to update graphical drivers but V Stuart had already checked this.

The only thing that worries me is the fact the blacklist becomes bigger and bigger and perhaps the drivers of some hardware we blacklisted have been updated meanwhile and may work on LO.

(In reply to Julien Nabet from comment #5)

> The only thing that worries me is the fact the blacklist becomes bigger and
> bigger and perhaps the drivers of some hardware we blacklisted have been
> updated meanwhile and may work on LO.

Not only that, but generally the Intel HD Graphics 620/630 GPU have acutally been quite stable with OpenGL. It is the Microsoft driven introduction of "Windows DCH" drivers [1] that Intel is now deploying to Windows 10 (1809) builds and later.

So, the Blacklist logic for Windows os/DE build (>= 1809) in addition to the GPU hardware ID for the 620 (0x5916) which continue to work with non-DCH drivers.

=-ref-=
[1] https://www.intel.com/content/www/us/en/support/articles/000031275/graphics-drivers.html

V Stuart: if I understand you it could be quickly a big source of future bugtrackers filled by Intel graphic users.

Tomaž/Caolán: I don't measure the impact of DCH drivers but perhaps it could be interesting to quote this point in next ESC.
For example, if LO is not yet compatible with DCH, we should blacklist all Intel/Win10, no need to wait to have a report for each Intel model.

Also, since I suppose we want to keep the possibility to use OpenGL, I think there should be some dev experts references and so a new line in https://wiki.documentfoundation.org/FindTheExpert.

Resolves with a driver roll-back...

(In reply to Julien Nabet from comment #7)
> V Stuart: if I understand you it could be quickly a big source of future
> bugtrackers filled by Intel graphic users.
> 
>...

Maybe. Does the blacklist and its XML configuration need additional logic?

Anyhow played a bit with the Intel DCH graphics driver packaging. Roll-back to prior  build 100.6519 (2019-01-16) package resolves our OpenGL crash proving issue is the "latest" 100.6861 (2019-0514)- DCH driver.

OpenGL_device.log from working build...
DriverVersion: 25.20.100.6519
DriverDate: 1-9-2019
DeviceID: PCI\VEN_8086&DEV_5916&SUBSYS_39FD17AA&REV_02
AdapterVendorID: 0x8086
AdapterDeviceID: 0x5916
AdapterSubsysID: 0x39fd17aa
DeviceKey: System\CurrentControlSet\Control\Video\{E640B70C-11DA-11E9-9437-DABE921972A4}\0000
DeviceString: Intel(R) HD Graphics 620

Do have to say that Intels DCH packaging is much better than prior driver management. It was trivial to roll back using the executable installer which correctly detected the newer drivers and asks if I wanted to overwrite.

There are currently eight driver builds with DCH installer packaging. I just grabbed one from the middle, will test all of them as I get a chance. But it seems a legitimate bug against the Intel drivers (or admittedly our OpenGL implementation).

Q. does anyone have needed karma with Intel to get a ticket opened for our OpenGL support? Maybe get some guidance on how to diagnose what has gone awry. Or better, get them to patch?

(In reply to V Stuart Foote from comment #8)

> Anyhow played a bit with the Intel DCH graphics driver packaging. Roll-back
> to prior  build 100.6519 (2019-01-16) package resolves our OpenGL crash
> proving issue is the "latest" 100.6861 (2019-0514)- DCH driver.

Effective for all tested prior builds of LO master, 6.2.3, and the 5.3.7 seat.

Hello V Stuart Foote,
is this issue still reproducible with a master build ?

(In reply to Xisco Faulí from comment #10)
> Hello V Stuart Foote,
> is this issue still reproducible with a master build ?

Yes, but also with a current 6.3.2.2 release.

crashreport.libreoffice.org/stats/crash_details/fc6aa05b-d424-4a35-8b9e-7bc01bb99382 

=-testing-=
Windows 10 Home 64-bit en-US with Intel HD Graphics 620
Version: 6.3.2.2 (x64)
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

Name	Intel(R) HD Graphics 620
PNP Device ID	PCI\VEN_8086&DEV_5916&SUBSYS_39FD17AA&REV_02\3&11583659&1&10
Adapter Type	Intel(R) HD Graphics Family, Intel Corporation compatible
Adapter Description	Intel(R) HD Graphics 620
Adapter RAM	1.00 GB (1,073,741,824 bytes)
Installed Drivers	C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_bf9afe57cbde0e11\igdumdim64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_bf9afe57cbde0e11\igd10iumd64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_bf9afe57cbde0e11\igd10iumd64.dll,C:\WINDOWS\System32\DriverStore\FileRepository\iigd_dch.inf_amd64_bf9afe57cbde0e11\igd12umd64.dll
Driver Version	26.20.100.6912
INF File	oem63.inf (iKBLD_w10_DS section)
Color Planes	Not Available
Color Table Entries	4294967296
Resolution	1920 x 1080 x 60 hertz
Bits/Pixel	32
Memory Address	0xB0000000-0xB0FFFFFF
Memory Address	0xA0000000-0xAFFFFFFF
I/O Port	0x00004000-0x0000403F
IRQ Channel	IRQ 4294967290
Driver	C:\WINDOWS\SYSTEM32\DRIVERSTORE\FILEREPOSITORY\IIGD_DCH.INF_AMD64_BF9AFE57CBDE0E11\IGDKMD64.SYS (26.20.100.6912, 18.88 MB (19,800,408 bytes), 6/19/2019 3:25 AM)

Created attachment 155199 [details]
WinDbg 64 Stack Trace of crash

WinDbg 64 stacktrace and analyze with symbols of crash of 6.3.2.2 TDF release build with OpenGL rendering with Intel HD Graphics 620

Created attachment 155200 [details]
WinDbg 64 analyze exception analysis

This crash also uploaded via Breakpad as

crashreport.libreoffice.org/stats/crash_details/6f4d09e8-573c-4ffe-ab31-7881b4ec11d0
 
STR for crash

Open Impress
Simple 3 slide presentation using slide 1 from the 'Focus' master
No transitions
Presentation saved
Reopen,position to first slide
Open Slide Transitions deck of the SideBar
Click select of 'Fade' transition

Crash & recovery

Same system OpenGL rendering disabled. Same steps, no crash and transition previews in the Impress editing window.

So back to NEW.

Anyone have ability to query crashreport.libreoffice.org to see how many of the mergedlo.dll back to 6.0, have crash while Impress is open, with Intel GPUs, on Windows 10 with the "DCH era" drivers [1][2]? 

If so, may help to classify the extent of the ongoing issue for Windows 10 users.

In the crashreport data, my HD Graphics 620 shows

OpenGLVendor	0x8086
ProductName	LibreOffice
OpenGLDriver	26.20.100.6912
UseOpenGL	true
OpenGLDevice	0x5916

=-ref-=

[1] https://www.intel.com/content/www/us/en/support/articles/000031275/graphics-drivers.html
[2] https://downloadcenter.intel.com/download/29113/Intel-Graphics-Windows-10-DCH-Drivers?product=80939

No improvement by update to latest Intel DCH driver 26.20.100.7323 (2019-10-07)

another crashreport addition to the mergedlo.dll pool

http://crashreport.libreoffice.org/stats/crash_details/5d77bfec-817a-445a-b772-ddda4870af58

V Stuart: do you think it could be possible you build sources by following https://wiki.documentfoundation.org/Development/BuildingOnWindows (with enable-dbgutil in autogen.input) to add some manual traces in order to debug this?

(In reply to Julien Nabet from comment #16)
> V Stuart: do you think it could be possible you build sources by following
> https://wiki.documentfoundation.org/Development/BuildingOnWindows (with
> enable-dbgutil in autogen.input) to add some manual traces in order to debug
> this?

Maybe, but isn't infra's Jenkins TB77 now spinning out debug builds for 64-bit Windows? 

Nope! Just checked its not:

=-=-=

Running ./configure with ´--enable-64-bit --without-junit --without-helppack-integration --enable-extension-integration --enable-scripting-beanshell --enable-scripting-javascript --enable-ext-wiki-publisher --enable-ext-nlpsolver --enable-online-update --enable-breakpad --with-help=html --with-myspell-dicts --with-package-format=msi --enable-mergelibs --with-lang=ALL --with-vendor=The Document Foundation (Jenkins) --disable-dependency-tracking --with-external-tar=/home/tdf/lode/ext_tar --with-ucrt-dir=/home/tdf/ucrt --with-export-validation --srcdir=/home/tdf/lode/jenkins/workspace/lo_gerrit/tb/src_master --enable-option-checking=fatal´

50            checking whether to build with additional debug utilities... no
51            checking whether to do a debug build... no
52            checking whether to generate debug information... no

=-=-=

Working with WinDbg linked with the 64-bit symbols from:

SRV*http://dev-downloads.libreoffice.org/symstore/symbols
SRV*http://msdl.microsoft.com/download/symbols

I have configured Linux VMs and with git compiled builds over the years, but always reluctant actually build Windows binaries from source. With project symbols, the TB daily seemed enough to not need to get things cobbled together to build on Winodws--I have access to the tools, just not in my skill set to build. 

Always assumed the only thing I can't do is add additional asserts or break-points.  Would my WinDbg backtraces for an issue improve much beyond attachment 155199 [details] or attachment 155200 [details] if I figure out how to clone the git and link to source?

(In reply to V Stuart Foote from comment #17)
> (In reply to Julien Nabet from comment #16)
> > V Stuart: do you think it could be possible you build sources by following
> > https://wiki.documentfoundation.org/Development/BuildingOnWindows (with
> > enable-dbgutil in autogen.input) to add some manual traces in order to debug
> > this?
> ...
> Always assumed the only thing I can't do is add additional asserts or
> break-points.  Would my WinDbg backtraces for an issue improve much beyond
> attachment 155199 [details] or attachment 155200 [details] if I figure out
> how to clone the git and link to source?

I'll be honest, it's far more cumbersome to build on Windows than on Linux.
When installing all prerequisites, you can see building has been thought above all for Linux users (I won't complain, I use Linux at home :-)).
However, it's simpler than some years ago when I had given up.
The things I don't like:
- windbg: you find far less doc to debug than for gdb, putting a break at a specific line isn't intuitive, values of vars are often pointer values not useful values, !analyze -v provide less info than gdb's "bt", etc.
- build fail after some updates so sometimes you must type "make <some module>.clean". You don't need to do this on Linux or very rarely!
and when you don't know which module fail, you must build from scratch with "make clean && make"

Anyway, the advantage is you can add logs by putting std::cerr << "<messages> \n"; (with #include <iostream>) and display values of vars, you can test some patches proposed by devs, you can disable some blocks, etc.
Now if you're not a programmer, perhaps it won't worth it for you. You decide! :-)

Created attachment 155331 [details]
WinDbg 64 backtrace OpenGL crash with project symbols and git clone of source

(In reply to Julien Nabet from comment #18)
OK thanks. For now I've done a git clone (using the https://gitforwindows.org/ port), just making a symbolic link to the source now held locally setting the link name so it will match the build path of the TDF build of 6.3.2.2:

c:\cygwin64\home\buildslave\source\libo-core

Win OpenGL rendering enabled, selecting the "Fade" transition for a slide. Reproduce the crash. Attaching the WinDbg64 crash dump with symbols and now source

After detaching from WinDbg64 the posted Breakpad crashreport is: 
crashreport.libreoffice.org/stats/crash_details/ef6bb683-8cf6-4e47-8735-5f9bf266972f

Of course no symbols or source for the Intel OpenGL device driver (ig9icd64) thread.

Need to point out that on Windows 10, with Intel HD graphics 620 and current DCH packaged drivers, I get similar crash and backtrace with all the OpenGL transitions. 

Not happening with just the 'Fade' transition--so this is not the issue of bug 91456 or bug 124729

Can't help here -> uncc myself

Created attachment 156386 [details]
WinDbg ST of crashing OpenGL rendering of the Fade slide transition

So this continues to be an issue.

With recent Intel DCH driver 26.20.100.7323 on Intel HD Graphics 620 continue to get OpenGL crashes rendering slide transitions.  Another WinDbg Stack Trace attached.

On Windows 10 Home 64-bit en-US (1903) with
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 790b5de8941d8f8d98c73ed1343289d7220211ad
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded


Simple transitions are fine, but consistently crash with these more complex transitions:

Fade,
Iris,
Vortex,
Ripple,

etc.

Launching soffice.exe from Cygwin with an 
'export SAL_LOG="+INFO.vcl.openGL+WARN"' env set
unfortunately a "2> soffice.log" output ends empty after crash.

Is my syntax wrong for that, or is there no DEBUG info to be had from the TB77 builds.


An Interesting Sidenote with these recent builds of master, that the Skia/Vulkan rendering has no crash with these transitions. But is affected by checking/unchecking the Hardware Acceleration control. With HA checked, the Skia/Vulkan rendering drops a text box from the rendering--and flashes it back up at the end.  With out HA checked it renders the entire source master and text annotation smoothly.

(In reply to V Stuart Foote from comment #22)

Could you please try to test the self-built debug (or better dbgutil) master with Visual Studio debug session attached? That could allow the debugger to jump up when the problem occurs, and allow you to see the place in code, and state of all variables at the moment of the violation. The stack you posted unfortunately doesn't sow the actual code failing (OpenGLSalBitmap::ScalingSupported is just "return true;", and that mergedlo!OpenGLSalBitmap::ScalingSupported+0x294 is somewhere in other code...)

Thanks!

Created attachment 156394 [details]
WinDbg stack of OpenGL crash taken from Source panel so with line refs

(In reply to Mike Kaganski from comment #23)
> Could you please try to test the self-built debug (or better dbgutil) master
> with Visual Studio debug session attached? That could allow the debugger to
> jump up when the problem occurs, and allow you to see the place in code, and
> state of all variables at the moment of the violation. The stack you posted
> unfortunately doesn't sow the actual code failing
> (OpenGLSalBitmap::ScalingSupported is just "return true;", and that
> mergedlo!OpenGLSalBitmap::ScalingSupported+0x294 is somewhere in other
> code...)
> 

Thanks Mike, *

Please be gentle, but as I don't clone git and build for Windows locally, I am working against project builds and downloaded symbol cache. 

But attached is a stack of crash with 6.3.3.2 drawn from the WinDbg source mode panel which I'd not used before--not sure if I can get more refined to step through and get vars. Anyhow, crash on this release build matches against the previous stack for master--but at least now includes the source code lines.

Is that more helpful?  Currently beyond me as to how to read out the CHECK_GL_ERROR () asserts if that is the next step. 

Stuart

Created attachment 156396 [details]
WinDbg stack of OpenGL crash taken from Source panel so with line refs

replacing empty upload...

Hmm, and when I closed out of WinDbg allowing the crash report to run get this submission:

http://crashreport.libreoffice.org/stats/crash_details/5034a6a6-dd74-4488-a25f-2acec598016c

So added the WinOpenGLContext::makeCurrent() crash signature.


Removing these earlier links:
https://crashreport.libreoffice.org/stats/crash_details/fc6aa05b-d424-4a35-8b9e-7bc01bb99382 
https://crashreport.libreoffice.org/stats/crash_details/6f4d09e8-573c-4ffe-ab31-7881b4ec11d0

Updated to latest Intel DCH driver, 26.20.100.7463 (2019-11-14) still crashes for OpenGL rendered transistions.

=-Sidebar-=

Found a similar issue reported on Lenovo forums, by a dev in Germany with similar  ig9icd64.dll related crash issues with Windows 10 running OpenGL on Intel HD Graphics 620. Posts up source for a toy program to demonstrate the crash in the OpenGL context makeCurrent() calls.

at this link:

https://forums.lenovo.com/t5/Lenovo-IdeaPad-1xx-3xx-5xx-7xx/Intel-UHD-Graphics-Driver-26-20-100-6860-crash-ig9icd64-dll/m-p/4468755/highlight/false#M70982

So at the day job, I dug out a Dell Lattitude E5470 laptop with i5-6440HQ Skylake cpu w/HD Graphcis 530, updated Windows 10 to 1903 build and updated.

had "legacy" 22.20.16.4799 (9/13/2017) Graphics packaging.

Tested OpenGL slide transitions on it with LibreOffice TB77 daily for 2019-12-10 64-bit build--no issues with the .4799 build rendering gl transitions (Fade, Ripple).

Enabled the 'Ignore OpenGL black list', and sequentially installed and tested Intel DCH drivers. 

Test results for the DCH packaged builds (only checked the Fade & Ripple gl transition):

25.20.100.6519 (1/16/2019) -- no issues

26.20.100.6708 (4/18/2019) -- no issues

26.20.100.6861 (5/15/2019) -- crashes

26.20.100.7463 (11/6.2019) -- crashes

Updated to latest Intel DCH driver, 26.20.100.7584 (2019-12-05) crashes on Intel HD Grahics 620 and Intel Iris 540 for OpenGL rendering on Windows 10 64-bit (1903, 1909) have resolved--no longer crashing.

Will check some of the other GPUs that also had been crashing, but looks like maybe Intel has corrected their drivers.

May change this over to Not Our Bug, but for now WFM.

(In reply to V Stuart Foote from comment #29)
> Updated to latest Intel DCH driver, 26.20.100.7584 (2019-12-05) crashes on
> Intel HD Grahics 620 and Intel Iris 540 for OpenGL rendering on Windows 10
> 64-bit (1903, 1909) have resolved--no longer crashing.
> 
> Will check some of the other GPUs that also had been crashing, but looks
> like maybe Intel has corrected their drivers.
> 
> May change this over to Not Our Bug, but for now WFM.

Signature date for the working 26.20.100.7584 build of ig9icd64.dll is actually 2019-12-10, not 2019-12-05

(In reply to V Stuart Foote from comment #29)
> May change this over to Not Our Bug, but for now WFM.

I do believe notourbug fits better here

Likely a blacklisting entry needed for the known-bad range of driver versions?

https://opengrok.libreoffice.org/xref/core/vcl/opengl/opengl_blacklist_windows.xml

https://gerrit.libreoffice.org/c/core/+/85833

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2a2ea50ca0548dcebf2e69e90c4a747218b1849d

tdf#125516: OpenGL: blacklist Intel drivers 26.20.100.6861 - 26.20.100.7463

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Thanks Mike, and I've tweaked the summary.

Would note the crashreport logs a number of paths resulting in the same LO crash at WinOpenGLContext::makeCurrent() and that it is not limited to the Intel GPUs.

Browsing through meta for the crash reports I see Intel, AMD and nVidia GPUs all in the mix--for both 32bit and 64bit Windows 7, 8 and 10.

(In reply to Mike Kaganski from comment #34)
> https://gerrit.libreoffice.org/c/core/+/85833

@Mike, Julien, *

Looking at the Intel Driver numbering scheme [1] seems like we would need additional stanzas in the XML to set the blacklist.

In Crashreport meta for the WinOpenGLContext::makeCurrent() signature, for the 6.3.0+ builds crashes on IntelGPUs for the gl slide transitions, see a range of Windows builds and GPU hardware signatures.
  
Current patch would only blacklist Windows 10 (1909) build with GPUs with DirectX 12.1 support with the DCH packaged 100.6861 -> 100.7463 drivers.

Alternative to multiple stanzas might be some refactoring in the blocklist_parser.cxx/hxx to pare the driver string back to just the build number?

=-ref-=
[1] https://www.intel.com/content/www/us/en/support/articles/000005654/graphics-drivers.html

I'd be even more radical since Skia integration is going to replace backends, what about disabling OpenGL completely at least on Windows?

(In reply to V Stuart Foote from comment #37)
> ...
> Current patch would only blacklist Windows 10 (1909) build with GPUs with
> DirectX 12.1 support with the DCH packaged 100.6861 -> 100.7463 drivers.
> 

Actually seems the WDDM 2.6 would be both 1903 and 1909 builds of Windows 10, none the less a bunch of folks with earlier Windows 10 builds and hardware that would benefit from expanding the OpenGL black listing.

(In reply to Julien Nabet from comment #38)
> I'd be even more radical since Skia integration is going to replace
> backends, what about disabling OpenGL completely at least on Windows?

Not til 6.5, and in the interim folks on 6.3 and 6.4 are gonna be plagued with the crashing OpenGL without doing a blacklist. Expand and backport the blacklist for now; look at the Skia & Vulkan support going forward.

(In reply to V Stuart Foote from comment #39)
> ...
> (In reply to Julien Nabet from comment #38)
> > I'd be even more radical since Skia integration is going to replace
> > backends, what about disabling OpenGL completely at least on Windows?
> 
> Not til 6.5, and in the interim folks on 6.3 and 6.4 are gonna be plagued
> with the crashing OpenGL without doing a blacklist. Expand and backport the
> blacklist for now; look at the Skia & Vulkan support going forward.
LO can work without OpenGL, what about disabling OpenGL for all branches and close the OpenGL related bugs?
Of course I'd let people force OpenGL use if they really want it but at their own risk (so without official support) until complete Skia integration.
I don't know if it's because we never had enough OpenGL devs or if OpenGL driver support is too buggy on graphic cards brands but I'd really like to know if ratio benefit/bugs worths it.

About Skia, hope we'll got enough devs in TDF to finish its integration and maintain it over the years.

I received today Intel update:
DriverVersion: 26.20.100.7584
DriverDate: 11-26-2019
DeviceID: PCI\VEN_8086&DEV_5916&SUBSYS_380117AA&REV_02
AdapterVendorID: 0x8086
AdapterDeviceID: 0x5916
AdapterSubsysID: 0x380117aa
DeviceKey: System\CurrentControlSet\Control\Video\{C8BE3EFA-1C33-11EA-B137-00E04C680054}\0000
DeviceString: Intel(R) HD Graphics 620

Microsoft Windows 10 Home (Insider)
Versión	10.0.19041 compilación 19041

Before that I was not able to use OpenGL with any version of LibreOffice, but with this update seems works fine OpenGL and OpenCL.

(In reply to Julien Nabet from comment #40)

> LO can work without OpenGL, what about disabling OpenGL for all branches and
> close the OpenGL related bugs?
> Of course I'd let people force OpenGL use if they really want it but at
> their own risk (so without official support) until complete Skia integration.
> I don't know if it's because we never had enough OpenGL devs or if OpenGL
> driver support is too buggy on graphic cards brands but I'd really like to
> know if ratio benefit/bugs worths it.

OK, if there is consensus on the ESC to dump 4+ years of work and just disable it now. ;-)

> 
> About Skia, hope we'll got enough devs in TDF to finish its integration and
> maintain it over the years.

Well maybe, but wouldn't that put a lot of unfair pressure on Luboš near term?

And, it still kind of feels like we will continue to have driver issues for accelerated rendering to contend with (moving from mainstream OpenGL/Direct3D to Vulkan support). Likewise don't the accelerated gl slide transitions in Impress that caused this hiccup need touch-ups for Vulkan?

But put it in a BZ issue by itself and let the ESC have at it. Most will have had a heads up as cc'd here and on the bug 93529 OpenGL Meta.

(In reply to V Stuart Foote from comment #42)
> (In reply to Julien Nabet from comment #40)
> 
> ...
> OK, if there is consensus on the ESC to dump 4+ years of work and just
> disable it now. ;-)
Don't bother ESC, I know that it won't happen, it was just my personal opinion :-)

> >..
> Well maybe, but wouldn't that put a lot of unfair pressure on Luboš near
> term?
> 
> And, it still kind of feels like we will continue to have driver issues for
> accelerated rendering to contend with (moving from mainstream
> OpenGL/Direct3D to Vulkan support). Likewise don't the accelerated gl slide
> transitions in Impress that caused this hiccup need touch-ups for Vulkan?
Perhaps
> 
> ...
I didn't tell Luboš should finish Skia integration maintain it over years himself. Obviously, I can understand that it can't be one people task. I just would like that TDF put all required resources to finish integration and maintain it over the years ; I wouldn't like this good work not be wasted or let rotten because of lack of devs (like already Firebird, reportbuilder, macro recording, etc.).

(In reply to Julien Nabet from comment #38)
> I'd be even more radical since Skia integration is going to replace
> backends, what about disabling OpenGL completely at least on Windows?

I'd love seeing LibreOffice OpenGL code dumped - but no earlier than Skia is fully functional, and *has own OpenGL support enabled*. E.g., my integrated AMD video has no Vulcan drivers (AFAICT); and loosing HW acceleration might not be ideal. Currently OpenGL in Skia in LO is not enabled (and no necessary work in being done) - Lubos has too much other work to do, and this is something TODO/LATER. So IMO dumping own OpenGL code is also TODO/LATER.

*** Bug 133926 has been marked as a duplicate of this bug. ***