mesa issueshttps://gitlab.freedesktop.org/mesa/mesa/-/issues2021-11-26T14:32:24Zhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1319Artifacts in X sessions, GPU fault 1472021-11-26T14:32:24ZBugzilla Migration UserArtifacts in X sessions, GPU fault 147## Submitted by Andrew Dorney
Assigned to **Default DRI bug account**
**[Link to original bug (#107095)](https://bugs.freedesktop.org/show_bug.cgi?id=107095)**
## Description
Created attachment 140442
dmesg
I purchased a new "MSI...## Submitted by Andrew Dorney
Assigned to **Default DRI bug account**
**[Link to original bug (#107095)](https://bugs.freedesktop.org/show_bug.cgi?id=107095)**
## Description
Created attachment 140442
dmesg
I purchased a new "MSI Radeon RX 580 Armor MK2 8G OC" this week. I am getting intermittend visual artifacts on some windows, but not others.
Arch Linux
linux 4.17.3-1
mesa 18.1.3-1
xf86-video-amdgpu 18.0.1-2
xorg-server 1.20.0-9
When I play games, the card performs admirably. No artifacting, no stutter. I've tripled-to-quadrupled my FPS, so accelleration works great. Where I'm having problems is on GUIs.
Text and GUI elements often show squares or lines. The color of the squares or lines are the color of the window or desktop below the active window. When I move or force a redraw on the active window, the squares/lines disappear or reappear in a new place on the active window. It occurs regularly in Firefox, xterm, Konsole, and kdesu4 permission popups.
The problem occurs both when I am running only GUIs, and when I am running games and GUIs simultaneously, so I don't think it's a power state issue.
To narrow down if it was Plasma or not, I rebooted and started Fluxbox. I started only xterms, ran some commands, and got no errors whatsoever. Then I started moving them around the screen. That's when I got this in my dmesg:
[ 200.335982] amdgpu 0000:01:00.0: GPU fault detected: 147 0x0508c402
[ 200.335986] amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x000FFAA1
[ 200.335988] amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A0C4002
[ 200.335991] amdgpu 0000:01:00.0: VM fault (0x02, vmid 5, pasid 32768) at page 1047201, read from 'TC3' (0x54433300) (196)
From then on, artifacts appeared on all windows per usual. Gaming and heavy 3D remained unaffected.
Should I RMA the card, or is this likely a software stack bug and I should wait for more Mesa/Kernel updates?
Please let me know if I can provide more information. Thanks!
~~**Attachment 140442**~~, "dmesg":
[dmesg_2018-07-02.log](/uploads/3a2c3737635c34829c9c54bd38494041/dmesg_2018-07-02.log)https://gitlab.freedesktop.org/mesa/mesa/-/issues/862Vulkan spec break: VkCommandBufferInheritanceInfo.framebuffer is NOT optional2021-11-24T18:45:12ZBugzilla Migration UserVulkan spec break: VkCommandBufferInheritanceInfo.framebuffer is NOT optional## Submitted by Sebastian Sydow
Assigned to **mes..@..op.org**
**[Link to original bug (#110810)](https://bugs.freedesktop.org/show_bug.cgi?id=110810)**
## Description
Created attachment 144406
Renderdoc capture, see How to reprod...## Submitted by Sebastian Sydow
Assigned to **mes..@..op.org**
**[Link to original bug (#110810)](https://bugs.freedesktop.org/show_bug.cgi?id=110810)**
## Description
Created attachment 144406
Renderdoc capture, see How to reproduce 2
In the Vulkan spec about VkCommandBufferInheritanceInfo it is stated that:
(https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkCommandBufferInheritanceInfo.html)
```
framebuffer optionally refers to the VkFramebuffer object that the VkCommandBuffer will be rendering to if it is executed within a render pass instance. It can be VK_NULL_HANDLE if the framebuffer is not known, or if the VkCommandBuffer will not be executed within a render pass instance.
```
VkCommandBufferInheritanceInfo.framebuffer is however NOT optional on Intel and AMD Mesa Vulkan drivers.
Effects on various drivers I could test:
- Intel HD 630 18.2.8: SEGFAULT
- Intel HD 630 19.0.1: works?
- AMD Vega m GL 18.2.8: blank screen
- AMD Vega m GL 19.0.1: blank screen
- AMD Vega 64 18.2.8: blank screen
- AMD Vega 64 19.0.1: blank screen
I could only reproduce this behaviour on Mesa drivers, not with Windows and AMD drivers.
How to reproduce 1:
- Clone Sascha Willems Vulkan Examples and Demos repo:
https://github.com/SaschaWillems/Vulkan.git
- open examples/multithreading/multithreading.cpp
- go to line 411 and comment out:
```
// Secondary command buffer also use the currently active framebuffer
inheritanceInfo.framebuffer = frameBuffer;
```
- this will cause framebuffer to be a nullptr, aka optional
How to reproduce 2:
- get RenderDoc
https://renderdoc.org/
- open the attached file "Mesa Bug.rdc"
- in the middle select the texture viewer
- on the top in the timeline open up the two gray bars
- on the buttom inside the timeline chart you should see two triangles. These are the draws. Selecting them will show you the expected result.
- selecting the block afterwards will make the result disappear.
- I'm expecting that RenderDoc draws the currently selected draw separately on top of all previous draws
**Attachment 144406**, "Renderdoc capture, see How to reproduce 2":
[Mesa_Bug.rdc](/uploads/e54261bb5b2b275725b6635d678b08bf/Mesa_Bug.rdc)
Version: 19.1https://gitlab.freedesktop.org/mesa/mesa/-/issues/126[radeonsi, regression, bisected, d3d trace] NFS Underground - 18.2.8 render f...2021-11-23T22:35:44ZBugzilla Migration User[radeonsi, regression, bisected, d3d trace] NFS Underground - 18.2.8 render fine, flickering present in 18.3.2## Submitted by smoki
Assigned to **mes..@..op.org**
**[Link to original bug (#109396)](https://bugs.freedesktop.org/show_bug.cgi?id=109396)**
## Description
Current Debian Sid, tested with Kabini hardware... issue with black flic...## Submitted by smoki
Assigned to **mes..@..op.org**
**[Link to original bug (#109396)](https://bugs.freedesktop.org/show_bug.cgi?id=109396)**
## Description
Current Debian Sid, tested with Kabini hardware... issue with black flickering artifacts in NFS: Underground game played in Nine, appeared after updating from Mesa 18.2.8 to Mesa to 18.3.2...
https://packages.debian.org/sid/libgl1-mesa-dri
I am using what is in distro there, so LLVM is that LLVM 7.0.1-4 and everything else... Long story short, so i bisected this and made a trace as requested on #d3d9 IRC, so first bad is be0bd95abf69920fc11fb50384ffc2f886a5f9e8
radeonsi: fix GPU hangs with bindless textures and LLVM 7.0
Trace is here:
https://www.dropbox.com/s/b1o6emkm6z7hfyu/NFS%3AUnderground.7z?dl=0
Version: 18.3https://gitlab.freedesktop.org/mesa/mesa/-/issues/581rv730 agp reproducable uvd gpu hangs in fullscreen2021-11-12T19:58:26ZBugzilla Migration Userrv730 agp reproducable uvd gpu hangs in fullscreen## Submitted by Roman Elshin
Assigned to **Default DRI bug account**
**[Link to original bug (#94511)](https://bugs.freedesktop.org/show_bug.cgi?id=94511)**
## Description
Created attachment 122250
dmesg
With some movies gpu hang...## Submitted by Roman Elshin
Assigned to **Default DRI bug account**
**[Link to original bug (#94511)](https://bugs.freedesktop.org/show_bug.cgi?id=94511)**
## Description
Created attachment 122250
dmesg
With some movies gpu hangs are quite reproducable while playing with "mpv hwdec=vdpau vo=vdpau" in fullscreen (1920x1200), in the same time "mpv hwdec=vdpau vo=opengl" work fine there.
For me it is quite easy to reproduce this with such encoded video:
ffmpeg -i big_buck_bunny_1080p_surround.avi -vf scale=1024:576 -c:v libx264 -preset medium -x264-params keyint_min=23 -c:a copy output_1024_576.mkv
Mostly it requires less then one minutes of playing in full screen for GPU hangs.
I suppose that problem is rv730 specific, as I can not reproduce it with rv740 (but it PCIe and work with CPU which is mutch faster).
~~**Attachment 122250**~~, "dmesg":
[dmesg-4.4.4.log](/uploads/5aa287d5d7f6eb7b7387c80de9200eff/dmesg-4.4.4.log)https://gitlab.freedesktop.org/mesa/mesa/-/issues/1529compilation of WebGL demo iamnop.com/particles shader slowed 5x, run-time per...2021-11-11T14:21:21ZBugzilla Migration Usercompilation of WebGL demo iamnop.com/particles shader slowed 5x, run-time perf dropped to 1/10th## Submitted by nat..@..el.com
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#97035)](https://bugs.freedesktop.org/show_bug.cgi?id=97035)**
## Description
Created attachment 125249
ui logs collected from chro...## Submitted by nat..@..el.com
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#97035)](https://bugs.freedesktop.org/show_bug.cgi?id=97035)**
## Description
Created attachment 125249
ui logs collected from chromebook with --disable-gpu-watchdog
Steps to Reproduce
===============
go to http://www.iamnop.com/particles/ in chrome browser
Expected Result
=============
website should load within 10 seconds with good performance (~30FPS)
Actual Result
==============
Website renders with 0-1FPS. On Skylake/Broadwell it takes ~40 seconds to start rendering. On Brasswell it takes over 2 mins to start rendering.
This looks like performance regression in mesa in later versions(12.0 etc).
With mesa 11.30.0 issue is not seen on skylake/broadwell while performance is little better on braswell(cyan) taking ~20 seconds.
With mesa ToT issue is always seen.
Tried on above platforms on chromebooks with chromeos and arch linux.
Chrome trace indicate
BDW with mesa 12.1.0: DoLinkProgram(load stage) wall duration=33.8 seconds
BDW with mesa 11.30: DoLinkProgram(load stage) wall duration=6.8 seconds (Good working)
Backporting to mesa 11.3 version on the same target device issue is not seen on big core.
**Attachment 125249**, "ui logs collected from chromebook with --disable-gpu-watchdog":
[ui_logs](/uploads/bd83b5db5a93373b338a357551b600b8/ui_logs)
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=91857
* https://bugs.freedesktop.org/show_bug.cgi?id=70613https://gitlab.freedesktop.org/mesa/mesa/-/issues/880Gallium OSMesa driver is far from being thread-safe2021-11-09T02:16:32ZBugzilla Migration UserGallium OSMesa driver is far from being thread-safe## Submitted by Frederic Devernay
Assigned to **mes..@..op.org**
**[Link to original bug (#95035)](https://bugs.freedesktop.org/show_bug.cgi?id=95035)**
## Description
see src/gallium/state_trackers/osmesa/osmesa.c
There are at l...## Submitted by Frederic Devernay
Assigned to **mes..@..op.org**
**[Link to original bug (#95035)](https://bugs.freedesktop.org/show_bug.cgi?id=95035)**
## Description
see src/gallium/state_trackers/osmesa/osmesa.c
There are at least three global variables with no protection:
- stapi in get_st_api()
- stmgr in get_st_manager()
- BufferList
Consequently:
- OSMesaCreateContext cannot be called simultaneously from two threads
- OSMesaMakeCurrent called from two threads with the same buffer attribs will share the same element in BufferList, and thus render to the same memory!
My guess is that these two objects should simply be stored in the context itself, but I cannot foresee the consequences.
For example, will shared display lists still work?
I am willing to help on solving this (we use OSMesa in highly multithreaded application).
Version: 11.2https://gitlab.freedesktop.org/mesa/mesa/-/issues/778glDrawBuffer crashes in case of surfaceless context2021-11-06T11:51:39ZBugzilla Migration UserglDrawBuffer crashes in case of surfaceless context## Submitted by Volker Vogelhuber
Assigned to **Default DRI bug account**
**[Link to original bug (#102574)](https://bugs.freedesktop.org/show_bug.cgi?id=102574)**
## Description
I've created a surfaceless OpenGL context using the...## Submitted by Volker Vogelhuber
Assigned to **Default DRI bug account**
**[Link to original bug (#102574)](https://bugs.freedesktop.org/show_bug.cgi?id=102574)**
## Description
I've created a surfaceless OpenGL context using the EGL_KHR_surfaceless_context extension together with eglGetPlatformDisplay/EGL_PLATFORM_GBM_MESA.
In this scenario there seem to be no valid default framebuffer which is Ok, as I'm normally only render to FBOs with textures bound. Due to an error on my side I called glDrawBuffer with GL_FRONT_LEFT while no FBO was bound.
This result in a crash in intel_buffers.c because in intelDrawBuffer()
dri2InvalidateDrawable is called with a null pointer which is
not checked in dri2InvalidateDrawable() or anywhere before.
While the root cause for triggering the error is on my side,
I think it may be better to raise an error instead of crashing.
So I propose to add a check to brw->driContext->driDrawablePriv
within intelDrawBuffer. Probably if the driDrawablePriv is nullptr
one should not call intel_prepare_render either.
Mesa 17.1 with Kernel 4.9.6 on Intel Apollo Lake GPU
Version: 17.1https://gitlab.freedesktop.org/mesa/mesa/-/issues/1833[Bisected]. [Regression]. Wayland. Chromium. Opening on full-screen mode vide...2021-10-29T12:40:14ZBugzilla Migration User[Bisected]. [Regression]. Wayland. Chromium. Opening on full-screen mode videos lead to flickering white/black squads## Submitted by Denis
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#111618)](https://bugs.freedesktop.org/show_bug.cgi?id=111618)**
## Description
Created attachment 145309
video_with_bug
Hello. During usin...## Submitted by Denis
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#111618)](https://bugs.freedesktop.org/show_bug.cgi?id=111618)**
## Description
Created attachment 145309
video_with_bug
Hello. During using Chromium on wayland I faced with an issue - huge white/black squads flickering over the screen, in case if I opened video into full-screen mode.
OS: Manjaro
Linux den-pc 5.2.11-1-MANJARO
Xorg-server 1.20.5-2 (Xwayland and all related packs the same version)
Chromium (chromium) 76.0.3809.132-1 (tested and on downgraded version)
Mesa versions - git-master, 19.1.5 (system) etc...
Steps:
1. Login into wayland session
2. Launch chromium
3. Open chromium into full-screen mode (it is important, because in other way bug can't be reproduced)
4. Launch any youtube video
5. Open video in a full-screen mode
Result: picture starts flickering with white-black squads. Video attached.
I searched for same/similar issues and could find only these, quite old and resolved mostly:
https://bugs.freedesktop.org/show_bug.cgi?id=106841
https://bugs.chromium.org/p/chromium/issues/detail?id=849682
https://bugs.freedesktop.org/show_bug.cgi?id=111140
Second thing - is that running with "--disable-gpu-driver-bug-workarounds" - resolves issue.
Bisection lead me to:
069fdd5f9facbd72fb6a289696c7b74e3237e70f is the first bad commit
commit 069fdd5f9facbd72fb6a289696c7b74e3237e70f
Author: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Date: Fri Jul 7 02:54:26 2017 -0400
egl/x11: Support DRI3 v1.1
Issue doesn't exist on Xorg session. Possibly (as in found tickets) it may be related to regression in Xwayland, but I am not sure in this.
**Attachment 145309**, "video_with_bug":
![Peek_2019-09-09_16-06](/uploads/6b16373a9d07c6f14e37361409d92356/Peek_2019-09-09_16-06.mp4)
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1631[KBL] GPU HANG: ecode 9:0:0x85dffffb, in mythfrontend.re [1179], reason: Hang...2021-10-19T13:44:17ZBugzilla Migration User[KBL] GPU HANG: ecode 9:0:0x85dffffb, in mythfrontend.re [1179], reason: Hang on rcs, action: reset## Submitted by Erik Hjertén
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#102843)](https://bugs.freedesktop.org/show_bug.cgi?id=102843)**
## Description
Created attachment 134319
Crash dump from /sys/class/...## Submitted by Erik Hjertén
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#102843)](https://bugs.freedesktop.org/show_bug.cgi?id=102843)**
## Description
Created attachment 134319
Crash dump from /sys/class/drm/card0/error as requested in dmesg.
Black screen when trying to play Video in Mythfrontend. Happens only occasionally, perhaps 1 in 20 tries.
Intel NUC7i3BNH
4.12.0-13-generic
HDMI connection
Driver installed from Ubuntu 17.10 repos.
**Attachment 134319**, "Crash dump from /sys/class/drm/card0/error as requested in dmesg.":
[intel_graphics_crash.txt](/uploads/49739fd8d07cdfb42b5cf2a006cd61d1/intel_graphics_crash.txt)https://gitlab.freedesktop.org/mesa/mesa/-/issues/1824Feature request: support GL_EXT_memory_object2021-09-30T22:52:42ZBugzilla Migration UserFeature request: support GL_EXT_memory_object## Submitted by Christoph Haag
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#111279)](https://bugs.freedesktop.org/show_bug.cgi?id=111279)**
## Description
... and of course GL_EXT_memory_object_fd.
This ex...## Submitted by Christoph Haag
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#111279)](https://bugs.freedesktop.org/show_bug.cgi?id=111279)**
## Description
... and of course GL_EXT_memory_object_fd.
This extension allows efficiently sharing texture data between OpenGL and Vulkan.
At Collabora we have two projects that make use of this extension.
The Monado OpenXR runtime uses the GL_EXT_memory_object OpenGL extension to enable OpenGL VR applications to submit frames to Monado's VR compositor which uses Vulkan.
xrdesktop uses the OpenGL extension to share OpenGL textures rendered by a window manager like kwin or gnome-shell with Vulkan textures that are either used by xrdesktop's internal scene renderer, or sent to a VR runtime.
From Valve there is also SteamVR relying on this extension to support running OpenGL VR applications efficiently.
When this extension is not available, SteamVR implements a fallback where OpenGL textures are downloaded to system ram and then uploaded to VRAM again with Vulkan, however this fallback is far too slow for practical use.
Monado and xrdesktop do not implement such a fallback and as a consequence do not work on Intel graphics.
While this OpenGL extension is currently used for mostly VR, it can be useful for any use case where IPC with OpenGL and Vulkan is required. For example Firefox may use it to speed up the IPC between tab process that render GL textures with the rendering process.
This feature request also covers iris.
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/998libgles2 exports new symbols2021-09-29T07:24:59ZBugzilla Migration Userlibgles2 exports new symbols## Submitted by Andreas Boll `@ab`
Assigned to **mes..@..op.org**
**[Link to original bug (#93271)](https://bugs.freedesktop.org/show_bug.cgi?id=93271)**
## Description
libgles2 exports the following new symbols in the upcoming 11...## Submitted by Andreas Boll `@ab`
Assigned to **mes..@..op.org**
**[Link to original bug (#93271)](https://bugs.freedesktop.org/show_bug.cgi?id=93271)**
## Description
libgles2 exports the following new symbols in the upcoming 11.1.0 release:
glBindFragDataLocationEXT
glDrawElementsBaseVertex
glDrawElementsInstancedBaseVertex
glDrawRangeElementsBaseVertex
These new symbols were introduced in af7c98a9 and 625414f7:
commit af7c98a9c75b17fc8c8ed0989aa732766e5b06d1
Author: Ryan Houdek <sonicadvance1@gmail.com>
Date: Sun Nov 1 21:25:27 2015 -0600
mesa: expose support for OES/EXT_draw_elements_base_vertex to OpenGL ES
This has been tested with the piglits in the mailing list and
on the Dolphin emulator.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
commit 625414f78c4ece1c5b24a31afad2efa4ea504933
Author: Ryan Houdek <Sonicadvance1@gmail.com>
Date: Thu Nov 5 10:52:35 2015 -0600
glapi: add EXT_blend_func_extended XML definitions
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Are these new symbols intended to be exported or is this a bug?https://gitlab.freedesktop.org/mesa/mesa/-/issues/737bug in EGL_Y_INVERTED_NOK2021-09-29T07:16:37ZBugzilla Migration Userbug in EGL_Y_INVERTED_NOK## Submitted by Vasiliy
Assigned to **Ian Romanick**
**[Link to original bug (#78966)](https://bugs.freedesktop.org/show_bug.cgi?id=78966)**
## Description
Please see this discussion in enlightenment mailing list, i'm affected by ...## Submitted by Vasiliy
Assigned to **Ian Romanick**
**[Link to original bug (#78966)](https://bugs.freedesktop.org/show_bug.cgi?id=78966)**
## Description
Please see this discussion in enlightenment mailing list, i'm affected by this bug and can't use hardware acceleration.
Link http://sourceforge.net/p/enlightenment/mailman/message/31713290/
P.S. Comment contains:
It looks like a bug in mesa. They support EGL_Y_INVERTED_NOK, but always return 0.
Look at mesa/src/egl/main/eglconfig.h:struct _egl_config, YInvertedNOK field is always 0 and
it's returned in eglGetConfigAttrib via eglOffsetOfConfig.
Version: 10.1https://gitlab.freedesktop.org/mesa/mesa/-/issues/162eglWaitClient() doesn't work as documented using DRI2 backend2021-09-29T07:08:23ZBugzilla Migration UsereglWaitClient() doesn't work as documented using DRI2 backend## Submitted by Mike Gorchak
Assigned to **Tapani Pälli**
**[Link to original bug (#106337)](https://bugs.freedesktop.org/show_bug.cgi?id=106337)**
## Description
According to EGL 1.4 specification eglWaitClient() should be equiva...## Submitted by Mike Gorchak
Assigned to **Tapani Pälli**
**[Link to original bug (#106337)](https://bugs.freedesktop.org/show_bug.cgi?id=106337)**
## Description
According to EGL 1.4 specification eglWaitClient() should be equivalent of glFinish() call, but according to the function code of dri2_wait_client() it does just flush() without waiting for any pending operations on drawable surface.
Version: 18.0https://gitlab.freedesktop.org/mesa/mesa/-/issues/913error: The command line is too long when building MESA on Windows with MinGW-W642021-09-28T14:49:36ZBugzilla Migration Usererror: The command line is too long when building MESA on Windows with MinGW-W64## Submitted by sav..@..kr.net
Assigned to **mes..@..op.org**
**[Link to original bug (#94072)](https://bugs.freedesktop.org/show_bug.cgi?id=94072)**
## Description
Hi,
Used stuff:
- Windows 10,
- MinGW-W64 (5.3.0-<i686,x86_64),
...## Submitted by sav..@..kr.net
Assigned to **mes..@..op.org**
**[Link to original bug (#94072)](https://bugs.freedesktop.org/show_bug.cgi?id=94072)**
## Description
Hi,
Used stuff:
- Windows 10,
- MinGW-W64 (5.3.0-<i686,x86_64),
- MSYS2 (4.3.42(4)-release-(x86_64-pc-msys)),
- Python (2.7.11),
- SCons (2.4.1),
- MESA (11.1.*-dev from git-repository).
For <i686,x86_64> builds got error:
===============================================================
scons.py build=release platform=windows toolchain=mingw machine=x86_64 libgl-gdi
[snip]
Archiving build\windows-x86\mesa\libmesa.a ...
Compiling src\gallium\auxiliary\draw\draw_pipe_twoside.c ...
The command line is too long.
scons: *** [build\windows-x86_64\mesa\libmesa.a] Error 1
scons: building terminated because of errors.
===============================================================
I found that it's very similar to which was reported four years ago:
"The command line is too long..."
(details at https://lists.freedesktop.org/archives/mesa-users/2012-October/000496.html ).
Other users also experienced it:
"Compiling Mesa natively on Windows using GCC with SCons results in "the command line is too long" error during linking..."
(details at https://wiki.qt.io/Cross_compiling_Mesa_for_Windows ).
While looking for solution, found in SCons wiki:
"MingW had some problems during the link phase of the build process. It turned out our link lines were in excess of 10000 characters, and this was causing some major grief with python calling spawn()..."
(details at https://bitbucket.org/scons/scons/wiki/LongCmdLinesOnWin32 ).
I assume this error last for such long, because testing of MESA builds using MinGW* was made on Linux with cross-compiling to Windows. Could it be fixed?
Regards,
Alexander
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/428mesa-9.0.2 compile failure with gcc-4.7.22021-09-28T14:48:57ZBugzilla Migration Usermesa-9.0.2 compile failure with gcc-4.7.2## Submitted by tre..@..ge.org
Assigned to **Default DRI bug account**
**[Link to original bug (#59842)](https://bugs.freedesktop.org/show_bug.cgi?id=59842)**
## Description
on AMD x86_64
llvm-3.2
gcc-4.7.2
libdrm-2.4.40
llvm-co...## Submitted by tre..@..ge.org
Assigned to **Default DRI bug account**
**[Link to original bug (#59842)](https://bugs.freedesktop.org/show_bug.cgi?id=59842)**
## Description
on AMD x86_64
llvm-3.2
gcc-4.7.2
libdrm-2.4.40
llvm-config --cxxflags
-I/usr/include -march=native -mtune=native -m64 -pipe -ffast-math -funroll-loops -O3 -fPIC -fvisibility-inlines-hidden -O3 -DNDEBUG -D_GNU_SOURCE -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
CFLAGS+=" -w" &&
OPTS='llvm=yes build=release' &&
scons $OPTS
scons: Reading SConscript files ...
Mkdir("build/linux-x86_64")
scons: Found LLVM version 3.2svn
Checking for X11 (x11 xext xdamage xfixes)... yes
Checking for XCB (x11-xcb xcb-glx >= 1.8.1)... yes
Checking for XF86VIDMODE (xxf86vm)... yes
Checking for DRM (libdrm >= 2.4.24)... yes
Checking for DRM_INTEL (libdrm_intel >= 2.4.30)... no
Checking for DRM_RADEON (libdrm_radeon >= 2.4.31)... yes
Checking for XORG (xorg-server >= 1.6.0)... yes
Checking for KMS (libkms >= 1.0.0)... yes
Checking for UDEV (libudev > 150)... yes
Checking for C header file X11/extensions/dpmsconst.h... yes
scons: done reading SConscript files.
scons: Building targets ...
Compiling src/gallium/drivers/r600/r600_translate.c ...
src/gallium/drivers/r600/r600_shader.c:210:44: error: array size missing in 'r600_shader_tgsi_instruction'
src/gallium/drivers/r600/r600_shader.c:210:76: error: array size missing in 'eg_shader_tgsi_instruction'
src/gallium/drivers/r600/r600_shader.c:210:106: error: array size missing in 'cm_shader_tgsi_instruction'
scons: *** [build/linux-x86_64/gallium/drivers/r600/r600_shader.os] Error 1
scons: building terminated because of errors.
Version: 9.0https://gitlab.freedesktop.org/mesa/mesa/-/issues/423r600_shader.c compile fails to compile with gcc-4.7.22021-09-28T14:48:51ZBugzilla Migration Userr600_shader.c compile fails to compile with gcc-4.7.2## Submitted by tre..@..ge.org
Assigned to **Default DRI bug account**
**[Link to original bug (#55604)](https://bugs.freedesktop.org/show_bug.cgi?id=55604)**
## Description
mesalib git branch 9.0 fails to compile using scons
$ s...## Submitted by tre..@..ge.org
Assigned to **Default DRI bug account**
**[Link to original bug (#55604)](https://bugs.freedesktop.org/show_bug.cgi?id=55604)**
## Description
mesalib git branch 9.0 fails to compile using scons
$ scons 2>ll
scons: Reading SConscript files ...
scons: Found LLVM version 3.1svn
Checking for X11 (x11 xext xdamage xfixes)... yes
Checking for XCB (x11-xcb xcb-glx >= 1.8.1)... yes
Checking for XF86VIDMODE (xxf86vm)... yes
Checking for DRM (libdrm >= 2.4.24)... yes
Checking for DRM_INTEL (libdrm_intel >= 2.4.30)... no
Checking for DRM_RADEON (libdrm_radeon >= 2.4.31)... yes
Checking for XORG (xorg-server >= 1.6.0)... yes
Checking for KMS (libkms >= 2.4.24)... no
Checking for UDEV (libudev > 150)... yes
Checking for C header file X11/extensions/dpmsconst.h... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
Compiling src/gallium/drivers/r600/r600_shader.c ...
Compiling src/gallium/drivers/r600/r700_asm.c ...
Compiling src/gallium/drivers/r600/r600_translate.c ...
scons: building terminated because of errors.
src/gallium/drivers/r600/r600_shader.c: At top level:
src/gallium/drivers/r600/r600_shader.c:210:44: error: array size missing in 'r600_shader_tgsi_instruction'
src/gallium/drivers/r600/r600_shader.c:210:76: error: array size missing in 'eg_shader_tgsi_instruction'
src/gallium/drivers/r600/r600_shader.c:210:106: error: array size missing in 'cm_shader_tgsi_instruction'
src/gallium/drivers/r600/r600_shader.c:741:2: warning: ISO C does not allow extra ';' outside of a function [-pedantic]
src/gallium/drivers/r600/r600_shader.c: In function 'r600_shader_from_tgsi':
src/gallium/drivers/r600/r600_shader.c:1468:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
src/gallium/drivers/r600/r600_shader.c:5221:2: warning: excess elements in array initializer [enabled by default]
src/gallium/drivers/r600/r600_shader.c:5230:2: warning: (near initialization for 'r600_shader_tgsi_instruction') [enabled by default]
scons reports that libkms not found, but libdrm-2.4.39 installs /usr/lib/libkms.la
/usr/lib/libkms.so
/usr/lib/libkms.so.1
/usr/lib/libkms.so.1.0.0
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/936scons-3 breaks libgl-xlib build2021-09-28T14:48:41ZBugzilla Migration Userscons-3 breaks libgl-xlib build## Submitted by Volker Wegert
Assigned to **mes..@..op.org**
**[Link to original bug (#110565)](https://bugs.freedesktop.org/show_bug.cgi?id=110565)**
## Description
Scons has been upgraded from 2.1.5 to 3.0.4 on my Gentoo system....## Submitted by Volker Wegert
Assigned to **mes..@..op.org**
**[Link to original bug (#110565)](https://bugs.freedesktop.org/show_bug.cgi?id=110565)**
## Description
Scons has been upgraded from 2.1.5 to 3.0.4 on my Gentoo system. After that, building libgl-xlib no longer worked; errors were
scons: Reading SConscript files ...
TypeError: a bytes-like object is required, not 'str':
File "/var/tmp/portage/media-libs/mesa-18.3.6/work/mesa-18.3.6/SConstruct", line 47:
ENV = os.environ,
File "/usr/lib64/python3.6/site-packages/SCons/Environment.py", line 982:
apply_tools(self, tools, toolpath)
File "/usr/lib64/python3.6/site-packages/SCons/Environment.py", line 107:
env.Tool(tool)
File "/usr/lib64/python3.6/site-packages/SCons/Environment.py", line 1789:
tool(self)
File "/usr/lib64/python3.6/site-packages/SCons/Tool/__init__.py", line 296:
self.generate(env, *args, **kw)
File "/var/tmp/portage/media-libs/mesa-18.3.6/work/mesa-18.3.6/scons/gallium.py", line 219:
env['gcc_compat'] = check_cc(env, 'GCC', 'defined(__GNUC__)')
File "/var/tmp/portage/media-libs/mesa-18.3.6/work/mesa-18.3.6/scons/gallium.py", line 135:
source.write('#if !(%s)\n#error\n#endif\n' % expr)
File "/usr/lib64/python3.6/tempfile.py", line 483:
return func(*args, **kwargs)
Checking for GCC ...
I've been told to report this upstream since apparently this is an issue with the scons files.
For reference, the Gentoo bug is https://bugs.gentoo.org/684790https://gitlab.freedesktop.org/mesa/mesa/-/issues/164Reading back an EGL Pbuffer using the OpenGL API returns garbled output2021-09-28T14:40:13ZBugzilla Migration UserReading back an EGL Pbuffer using the OpenGL API returns garbled output## Submitted by Matthieu Bouron
Assigned to **Tapani Pälli**
**[Link to original bug (#108977)](https://bugs.freedesktop.org/show_bug.cgi?id=108977)**
## Description
Created attachment 142750
EGL pbuffer test
Hello,
I am current...## Submitted by Matthieu Bouron
Assigned to **Tapani Pälli**
**[Link to original bug (#108977)](https://bugs.freedesktop.org/show_bug.cgi?id=108977)**
## Description
Created attachment 142750
EGL pbuffer test
Hello,
I am currently facing an issue while reading back EGL Pbuffers using glReadPixels() with the OpenGL API as the output is garbled. It properly works with the OpenGL ES API though.
I can reproduce the issue on different machines running Arch Linux with mesa 18.2.5 on X using the following GPU: Intel HD 5500, Intel Iris 580 Pro, AMD RX 580.
I am not able to reproduce the issue on an NVDIA GTX 1070 running the proprietary driver.
I have attached a sample code that reproduces the issue:
On OpenGL:
gcc `pkg-config --libs egl gl` -Wall egl-pbuffer.c -o egl-pbuffer &&./egl-pbuffer
0xff69fc07 0xff69fc07 0xff69fc07 0xff69fc07
0xff69fc07 0xff11a1e4 0xff000000 0xff000000
0xff69fc07 0xff000000 0xff7fc700 0xff000000
0xff69fc07 0xff000000 0xff000000 0xff3a4e3b
On OpenGLES (adding the -es parameter to ./egl-pbuffer):
gcc `pkg-config --libs egl gl` -Wall egl-pbuffer.c -o egl-pbuffer &&./egl-pbuffer -es
0xff0000ff 0xff0000ff 0xff0000ff 0xff0000ff
0xff0000ff 0xff0000ff 0xff0000ff 0xff0000ff
0xff0000ff 0xff0000ff 0xff0000ff 0xff0000ff
0xff0000ff 0xff0000ff 0xff0000ff 0xff0000ff
**Attachment 142750**, "EGL pbuffer test":
[egl-pbuffer.c](/uploads/500de7d075bf407105122ef8a6b5cda6/egl-pbuffer.c)
Version: 18.2https://gitlab.freedesktop.org/mesa/mesa/-/issues/157dEQP EGL: eglCreateSyncKHR negative test failure.2021-09-28T14:35:56ZBugzilla Migration UserdEQP EGL: eglCreateSyncKHR negative test failure.## Submitted by Randy
Assigned to **mes..@..op.org**
**[Link to original bug (#98346)](https://bugs.freedesktop.org/show_bug.cgi?id=98346)**
## Description
Expect EGL_BAD_ATTRIBUTE, but got EGL_BAD_MATCH
dEQP-EGL.functional.reusa...## Submitted by Randy
Assigned to **mes..@..op.org**
**[Link to original bug (#98346)](https://bugs.freedesktop.org/show_bug.cgi?id=98346)**
## Description
Expect EGL_BAD_ATTRIBUTE, but got EGL_BAD_MATCH
dEQP-EGL.functional.reusable_sync.invalid.create_invalid_attribs.qpa: `<Result StatusCode="Fail">`Fail`</Result>`
dEQP-EGL.functional.reusable_sync.invalid.create_invalid_type.qpa: `<Result StatusCode="Fail">`Fail`</Result>`
Mesa git top commit: 389d6dedbe75defe07216ad761569a9b94f44e58
dEQP git top commit: ca988480be945772473f9256b6ae91fa6aa62bd1
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1349[amdgpu] [apitrace] Penumbra Overture crash in radeonsi_dri.so on RX5802021-09-09T14:37:35ZBugzilla Migration User[amdgpu] [apitrace] Penumbra Overture crash in radeonsi_dri.so on RX580## Submitted by Henri Valta
Assigned to **Default DRI bug account**
**[Link to original bug (#109048)](https://bugs.freedesktop.org/show_bug.cgi?id=109048)**
## Description
Created attachment 142799
Coredump info
Penumbra Overtur...## Submitted by Henri Valta
Assigned to **Default DRI bug account**
**[Link to original bug (#109048)](https://bugs.freedesktop.org/show_bug.cgi?id=109048)**
## Description
Created attachment 142799
Coredump info
Penumbra Overture game from Steam crashes reliably when trying to detonate the TNT barrel.
The crash seems to happen in radeonsi_dri.so
Stack trace of thread 16178:
#0 0x00000000f44d5dc1 amdgpu_bo_map (radeonsi_dri.so)
#1 0x00000000f448a874 si_texture_transfer_map (radeonsi_dri.so)
#2 0x00000000f4ae24b1 tc_transfer_map (radeonsi_dri.so)
#3 0x00000000f46ee64b pipe_transfer_map_3d (radeonsi_dri.so)
#4 0x00000000f46dfb48 st_MapTextureImage (radeonsi_dri.so)
#5 0x00000000f46b3c85 store_texsubimage (radeonsi_dri.so)
#6 0x00000000f46e2aca st_TexSubImage (radeonsi_dri.so)
#7 0x00000000f46e4650 st_TexImage (radeonsi_dri.so)
#8 0x00000000f46a7085 teximage (radeonsi_dri.so)
#9 0x00000000f46a8a78 _mesa_TexImage1D (radeonsi_dri.so)
#10 0x00000000f7d44236 glTexImage1D (glxtrace.so)
System specification:
AMD Ryzen 7 2700X
MSI X470 Gaming Pro/latest bios
MSI RX580 Armor 8G (1d:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/57$
Arch linux 64 bit, but the game is 32 bit
Kernel 4.19.8-arch1-1-ARCH
Mesa 18.3.1-1
**Attachment 142799**, "Coredump info":
[coredump_info.txt](/uploads/734f7d59dd658e3f26895b7d6db3bd0f/coredump_info.txt)
Version: 18.3