search

msys2 / MINGW-packages

Package scripts for MinGW-w64 targets to build under MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
2.28k stars 1.21k forks source link

File conflict between angleproject with mesa and opencl-headers #14803

Closed mmuetzel closed 1 year ago

mmuetzel commented 1 year ago

Description / Steps to reproduce the issue

Running pacman -Syu fails with the following file conflicts for me:

Fehler: Der Vorgang konnte nicht durchgeführt werden (In Konflikt stehende Dateien)
mingw-w64-x86_64-angleproject: /mingw64/bin/libEGL.dll existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/bin/libGLESv1_CM.dll existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/bin/libGLESv2.dll existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_d3d10.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_d3d11.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_dx9_media_sharing.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_dx9_media_sharing_intel.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_egl.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_ext.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_ext_intel.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_gl.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_gl_ext.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_half.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_icd.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_layer.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_platform.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_va_api_media_sharing_intel.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/cl_version.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/CL/opencl.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-opencl-headers)
mingw-w64-x86_64-angleproject: /mingw64/include/EGL/egl.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/EGL/eglext.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/EGL/eglext_angle.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/EGL/eglplatform.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES/egl.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES/gl.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES/glext.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES/glplatform.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES2/gl2.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES2/gl2ext.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES2/gl2platform.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES3/gl3.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES3/gl31.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES3/gl32.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/include/GLES3/gl3platform.h existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/lib/libEGL.dll.a existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/lib/libGLESv1_CM.dll.a existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
mingw-w64-x86_64-angleproject: /mingw64/lib/libGLESv2.dll.a existiert im Dateisystem (gehört zu mingw-w64-x86_64-mesa)
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Expected behavior

Updating packages should work without conflicts.

Actual behavior

angleproject is pulled in by gtk3 (afaict). That leads to file conflicts with other installed packages.

Verification

Windows Version

MINGW64_NT-10.0-22621

MINGW environments affected

Are you willing to submit a PR?

I don't know anything about angleproject and don't know how those conflicts should be resolved.

raedrizqie commented 1 year ago

angleproject and mesa have the same dll names and headers.. either rename the libs in mesa or maybe make mesa use external angle (if posibble)

mmuetzel commented 1 year ago

angleproject and mesa have the same dll names and headers.. either rename the libs in mesa or maybe make mesa use external angle (if posibble)

Afaict, those library names need to follow the standard. I don't know how angleproject compares to mesa. But maybe, we could disable building the EGL and GLES libraries with mesa. And projects requiring them would need to shift from using mesa to angleproject. Would that be an acceptable solution?

With respect to the OpenCL headers: Mesa is using the ones from the opencl-headers package afaict. Could angleproject do the same?

raedrizqie commented 1 year ago

If I'm not mistaken, mesa uses egl from angleproject and bundle it inside its package..

For opencl headers, I think it can safely be removed from angle package, or try using external opencl library when building angle..

Maybe @pal1000 have some thoughts on this..

mmuetzel commented 1 year ago

If I'm not mistaken, mesa uses egl from angleproject and bundle it inside its package..

Do you have any source to back that up? Since the mesa project pre-dates the angleproject afaict, I kind of doubt that this is the case...

raedrizqie commented 1 year ago

Reading https://docs.mesa3d.org/egl.html .. they both uses khronos egl.. sorry

I'm ok with any fixes regarding this package conflict..

mmuetzel commented 1 year ago

The Khronos group is defining the standard. They don't have any actual implementation afaict.

mmuetzel commented 1 year ago

I'm ok with any fixes regarding this package conflict..

That's why I was asking for how they compare. I meant how strictly they follow the standard, how completely they implement the interfaces defined in the standard, and how they compare with respect to performance.

raedrizqie commented 1 year ago

Maybe @ZachBacon can shed some light regarding completeness of egl implementation on both packages (reffering to qemu)

ZachBacon commented 1 year ago

So mesa has its own implementation of egl, where angle is a layer to egl, basically it translates egl calls to direct3d calls on windows. Mesa on windows though I find while yes compiles on windows, doesn't really play nice on windows in general.

So my personal opinion for egl, stick to angleproject.

mmuetzel commented 1 year ago

Maybe, it would be possible to split the mesa package and have the GLES/EGL libraries and headers in a separate package. Only that part of mesa could conflict with ANGLE.

ZachBacon commented 1 year ago

My recommendation would to not use Mesa on windows, but that's a personal opinion

mmuetzel commented 1 year ago

We are using mesa (llvmpipe) as a software OpenGL renderer for Octave for Windows since a few years. It is working pretty well for us and avoids issues for users that have graphics hardware with broken/unstable OpenGL drivers. That is not the same mesa that is distributed by MSYS2 though. I'm also having trouble getting the libraries from the mesa package distributed by MSYS2 to work...

ZachBacon commented 1 year ago

I'm have never had Mesa work for me on windows on a variety of hardware sadly. I prefer to keep Mesa in the Linux world. But again my opinion.

ZachBacon commented 1 year ago

Ideally for the conflicts though, just have Mesa conflict with angle and vice versa. Meaning the two can't be installed together.

mmuetzel commented 1 year ago

Ideally for the conflicts though, just have Mesa conflict with angle and vice versa. Meaning the two can't be installed together.

That would be suboptimal. I'd still like to experiment with mesa. But some packages now also depend on angleproject (e.g., gtk3 via libepoxy). Personally, I don't care about the OpenGL ES and EGL parts of mesa. So, splitting those off into a separate package would be good enough for me...

Biswa96 commented 1 year ago

ArchLinux also splits mesa package, see https://github.com/archlinux/svntogit-packages/blob/packages/mesa/trunk/PKGBUILD. I think it would be a better choice. @pal1000 may provide some information about this topic.

ZachBacon commented 1 year ago

ArchLinux also splits mesa package, see https://github.com/archlinux/svntogit-packages/blob/packages/mesa/trunk/PKGBUILD. I think it would be a better choice. @pal1000 may provide some information about this topic.

In this I agree.

pal1000 commented 1 year ago

Angleproject is far superior to Mesa3D OpenGL ES implementation on Windows. Disabling EGL/GLES and maybe even shared glapi is enough.

alvinhochun commented 1 year ago

I don't know Mesa and how it works on Windows, but I did have a bit of experience with ANGLE from fiddling with Qt and Krita. I feel that you may be oversimplifying things a bit.

IIRC EGL isn't necessarily tied to OpenGL ES, but can also be used to initialize desktop OpenGL contexts. I heard that Mesa's EGL has a WGL driver or is that not actually functional? (I get that if an application supports OpenGL on Windows, it probably uses WGL to initialize and use OpenGL stuff, so there may not be much of a need for EGL...)

Also I heard that some graphics drivers (Intel and NVIDIA) implement OpenGL ES accessible via some WGL extensions, while AMD actually ship an EGL library with their drivers for OpenGL ES. (Not sure if this is outdated though.)

Creating an EGL context from a native window (HWND and HDC) requires platform-specific knowledge, so I expect most applications that know how to do it on Windows would normally include it in its release package, and is able to utilize implementation-specific extensions (e.g. be able to choose between and detect the D3D9 vs D3D11 backend of ANGLE, or knowing that inverting the Y-axis yields better performance), like Chrome, Firefox and some Qt5 applications do. With this in mind, choosing to use ANGLE should be a decision made by individual application packages.

I don't know if any applications actually use Mesa's EGL implementation on Windows, but if they exist I would also expect them to depend on the implementation details of it.

My gut feeling is that these two EGL implementations should not be considered interchangeable.

Having a Mesa package available to be installed to the prefix also seems weird... as it basically forces all applications inside the mingw environment to use the Mesa OpenGL implementation instead of the OpenGL ICD provided by the graphics driver installed on the system (unless they are "smart" enough to load opengl32.dll from System32 with its full path). I guess it is understandable if the use case is to provide llvmpipe for those without a proper hardware OpenGL driver on the system, though if that is the case wouldn't a system-wide install make more sense so it can be used even for applications outside of MSYS2? (By the way Qt has a specific fallback which loads opengl32sw.dll as the "software OpenGL implementation", expecting it to be llvmpipe.)

(Sorry this end up being a bit of rambling...)

MehdiChinoune commented 1 year ago

Fixed by #14804