mesa issueshttps://gitlab.freedesktop.org/mesa/mesa/-/issues2021-03-05T20:00:59Zhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1128[NV4C] System crashes reliably with glxinfo2021-03-05T20:00:59ZBugzilla Migration User[NV4C] System crashes reliably with glxinfo## Submitted by Dave Odell
Assigned to **Nouveau Project**
**[Link to original bug (#99968)](https://bugs.freedesktop.org/show_bug.cgi?id=99968)**
## Description
Created attachment 129920
Example display corruption
+++ This bug w...## Submitted by Dave Odell
Assigned to **Nouveau Project**
**[Link to original bug (#99968)](https://bugs.freedesktop.org/show_bug.cgi?id=99968)**
## Description
Created attachment 129920
Example display corruption
+++ This bug was initially created as a clone of Bug #91992 +++
Hardware is NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) on an old Dell Inspiron 531. Integrated graphics.
The system boots OK (with high-resolution console) into X11. I can log in to a Lubuntu desktop (2D, no OpenGL, AFAIK). Then, from a terminal window I run:
$ while true; do nice -n19 glxinfo > /dev/null; done
Then I drag the window around for a few seconds. Then the entire system crashes: total system lockup, followed by display corruption a second or two later. (I've attached a photograph, because I can't take a normal screen shot.) No Ctrl-Alt-F1, no magic SysRq, no ping response.
Other OpenGL apps (i.e. glxgears) can run...sometimes. Other times, they crash the same way. It seems to happen on GL init.
Ubuntu 16.10 (with Lubuntu Desktop)
Linux kernel 4.10.0 (freshly compiled)
libdrm 2.4.70-1 (from distro)
Mesa 12.0.3-1ubuntu2 (from distro)
xf86-video-nouveau 1:1.0.12-2 (from distro)
This seems a lot like [bug 91992](https://bugs.freedesktop.org/show_bug.cgi?id=91992), but I've got my video memory cranked up to 256 MB in the BIOS settings, and it still happens.
**Attachment 129920**, "Example display corruption":
![IMG_20170225_180139765](/uploads/a741d63bf1e10e263dc8be89348a7cb0/IMG_20170225_180139765.jpg)
Version: 12.0
### Depends on
* [Bug 91992](https://bugs.freedesktop.org/show_bug.cgi?id=91992)https://gitlab.freedesktop.org/mesa/mesa/-/issues/933[oland, clover, llvm5] While-If Problem with Booleans2020-07-14T09:09:10ZBugzilla Migration User[oland, clover, llvm5] While-If Problem with Booleans## Submitted by Natalia
Assigned to **mes..@..op.org**
**[Link to original bug (#109617)](https://bugs.freedesktop.org/show_bug.cgi?id=109617)**
## Description
OpenCL kernel containing While loop and If statement does not work cor...## Submitted by Natalia
Assigned to **mes..@..op.org**
**[Link to original bug (#109617)](https://bugs.freedesktop.org/show_bug.cgi?id=109617)**
## Description
OpenCL kernel containing While loop and If statement does not work correctly with boolean variable, while everething is good with integer variable and with For loop.
The kernel is the following: https://textuploader.com/15szh.
The results are the following: https://textuploader.com/15szu.
This is tested at openSUSE 15.0 notebook with AMD Radeon HD 8750M GPU.
### Blocking
* [Bug 99553](https://bugs.freedesktop.org/show_bug.cgi?id=99553)https://gitlab.freedesktop.org/mesa/mesa/-/issues/130[OpenCL] Please add Image support2024-03-11T23:52:02ZBugzilla Migration User[OpenCL] Please add Image support## Submitted by Thomas Paris
Assigned to **mes..@..op.org**
**[Link to original bug (#87738)](https://bugs.freedesktop.org/show_bug.cgi?id=87738)**
## Description
Hi,
Image support is required by darktable (RAW photos processing)...## Submitted by Thomas Paris
Assigned to **mes..@..op.org**
**[Link to original bug (#87738)](https://bugs.freedesktop.org/show_bug.cgi?id=87738)**
## Description
Hi,
Image support is required by darktable (RAW photos processing) as can be seen in the following output, from runnind darktable -d opencl:
[opencl_init] opencl related configuration options:
[opencl_init]
[opencl_init] opencl: 0
[opencl_init] opencl_library: ''
[opencl_init] opencl_memory_requirement: 768
[opencl_init] opencl_memory_headroom: 300
[opencl_init] opencl_device_priority: '*/!0,*/*/*'
[opencl_init] opencl_size_roundup: 16
[opencl_init] opencl_async_pixelpipe: 0
[opencl_init] opencl_synch_cache: 0
[opencl_init] opencl_number_event_handles: 25
[opencl_init] opencl_micro_nap: 1000
[opencl_init] opencl_use_pinned_memory: 0
[opencl_init] opencl_use_cpu_devices: 0
[opencl_init] opencl_avoid_atomics: 0
[opencl_init] opencl_omit_whitebalance: 0
[opencl_init]
[opencl_init] trying to load opencl library: '`<system default>`'
[opencl_init] opencl library 'libOpenCL' found on your system and loaded
[opencl_init] found 1 platform
[opencl_init] found 1 device
[opencl_init] discarding device 0 `AMD OLAND' due to missing image support.
[opencl_init] no suitable devices found.
[opencl_init] FINALLY: opencl is NOT AVAILABLE on this system.
[opencl_init] initial status of opencl enabled flag is OFF.
Not sure if anything else is needed to get OpenCL to work in darktable but it would be very sweet to be able to get that with open source drivers.
Thanks,
Thomas
Version: git
### Blocking
* [Bug 74974](https://bugs.freedesktop.org/show_bug.cgi?id=74974)
* [Bug 82717](https://bugs.freedesktop.org/show_bug.cgi?id=82717)
* [Bug 99553](https://bugs.freedesktop.org/show_bug.cgi?id=99553)
* [Bug 107115](https://bugs.freedesktop.org/show_bug.cgi?id=107115)
* [Bug 109224](https://bugs.freedesktop.org/show_bug.cgi?id=109224)https://gitlab.freedesktop.org/mesa/mesa/-/issues/1626[OpenGL CTS] List of open issues2022-06-02T23:00:12ZBugzilla Migration User[OpenGL CTS] List of open issues## Submitted by Juan Suárez Romero `@jasuarez`
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#102590)](https://bugs.freedesktop.org/show_bug.cgi?id=102590)**
## Description
This is a meta-bug to track all iss...## Submitted by Juan Suárez Romero `@jasuarez`
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#102590)](https://bugs.freedesktop.org/show_bug.cgi?id=102590)**
## Description
This is a meta-bug to track all issues regarding Khronos OpenGL CTS issues
### Depends on
* [Bug 89649](https://bugs.freedesktop.org/show_bug.cgi?id=89649)
* [Bug 102663](https://bugs.freedesktop.org/show_bug.cgi?id=102663)
* [Bug 103837](https://bugs.freedesktop.org/show_bug.cgi?id=103837)
* [Bug 104153](https://bugs.freedesktop.org/show_bug.cgi?id=104153)
* [Bug 107675](https://bugs.freedesktop.org/show_bug.cgi?id=107675)
* [Bug 109655](https://bugs.freedesktop.org/show_bug.cgi?id=109655)
* [Bug 102611](https://bugs.freedesktop.org/show_bug.cgi?id=102611)
* [Bug 102621](https://bugs.freedesktop.org/show_bug.cgi?id=102621)
* [Bug 102623](https://bugs.freedesktop.org/show_bug.cgi?id=102623)
* [Bug 102677](https://bugs.freedesktop.org/show_bug.cgi?id=102677)
* [Bug 102678](https://bugs.freedesktop.org/show_bug.cgi?id=102678)
* [Bug 102679](https://bugs.freedesktop.org/show_bug.cgi?id=102679)
* [Bug 102680](https://bugs.freedesktop.org/show_bug.cgi?id=102680)
* [Bug 102697](https://bugs.freedesktop.org/show_bug.cgi?id=102697)
* [Bug 102855](https://bugs.freedesktop.org/show_bug.cgi?id=102855)
* [Bug 103006](https://bugs.freedesktop.org/show_bug.cgi?id=103006)
* [Bug 103007](https://bugs.freedesktop.org/show_bug.cgi?id=103007)
* [Bug 103008](https://bugs.freedesktop.org/show_bug.cgi?id=103008)
* [Bug 103095](https://bugs.freedesktop.org/show_bug.cgi?id=103095)
* [Bug 103098](https://bugs.freedesktop.org/show_bug.cgi?id=103098)
* [Bug 103140](https://bugs.freedesktop.org/show_bug.cgi?id=103140)
* [Bug 104154](https://bugs.freedesktop.org/show_bug.cgi?id=104154)
* [Bug 104272](https://bugs.freedesktop.org/show_bug.cgi?id=104272)
* [Bug 104335](https://bugs.freedesktop.org/show_bug.cgi?id=104335)
* [Bug 104395](https://bugs.freedesktop.org/show_bug.cgi?id=104395)
* [Bug 110357](https://bugs.freedesktop.org/show_bug.cgi?id=110357)
* [Bug 110796](https://bugs.freedesktop.org/show_bug.cgi?id=110796)https://gitlab.freedesktop.org/mesa/mesa/-/issues/411OpenGL does not work or works very slowly on Radeon HD38502020-10-20T11:48:25ZBugzilla Migration UserOpenGL does not work or works very slowly on Radeon HD3850## Submitted by Maxim Koltsov
Assigned to **Default DRI bug account**
**[Link to original bug (#50450)](https://bugs.freedesktop.org/show_bug.cgi?id=50450)**
## Description
Created attachment 62198
lspci
I have ATI Radeon HD3850 ...## Submitted by Maxim Koltsov
Assigned to **Default DRI bug account**
**[Link to original bug (#50450)](https://bugs.freedesktop.org/show_bug.cgi?id=50450)**
## Description
Created attachment 62198
lspci
I have ATI Radeon HD3850 on AGP bus with Pentium-4 PC. I observe very strange behavior of OpenGL applications:
KWin, qudos, doomsday run slowly even not with high quality settings;
Quake4 demo from ID site crashes right after map loading, just when rendering starts i suppose, and X server crashes with it.
I attach my glxinfo, kernel config and lspci. Versions of used software are: mesa, libdrm and xf86-video-ati from git, linux kernel kernel 3.3.5, X.org server 1.12.1.
I think this is bug in mesa or xf86-video-ati related to my video card. Please help me.
**Attachment 62198**, "lspci":
[lspci.log](/uploads/44ae383f07a1f7881fda33633e54674f/lspci.log)
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1125openmw - Segfault with the nouveau ddx + DRI32022-11-23T21:43:37ZBugzilla Migration Useropenmw - Segfault with the nouveau ddx + DRI3## Submitted by orb..@..lev.dk
Assigned to **Nouveau Project**
**[Link to original bug (#99464)](https://bugs.freedesktop.org/show_bug.cgi?id=99464)**
## Description
Created attachment 129055
Apitrace.
When starting openmw which ...## Submitted by orb..@..lev.dk
Assigned to **Nouveau Project**
**[Link to original bug (#99464)](https://bugs.freedesktop.org/show_bug.cgi?id=99464)**
## Description
Created attachment 129055
Apitrace.
When starting openmw which is the free engine re-implementation of the game morrowind it will segfault. This may be a mesa core bug, but it will only happen with the nouveau DDX + DRI3. It will not crash with modesetting + DRI3, DRI2 or the llvmpipe.
Here is a backtrace.
http://pastebin.com/HMdv4iWb
Apitrace log.
http://pastebin.com/FzZVyGqW
Here is a workaround as reported to the the mesa mailing list by Tobias Klausmann. It successfully hides the crash, but potentially breaking the hardware cursor used by openmw which works correctly with DRI2, modesetting or the llvmpipe. It also was not intended as a real fix.
"OpenMW tries to upload a new surface (mouse pointer) which fails in the now
guarded update_framebuffer_size() as the surface is NULL.
This is not inteded as a real "fix", as it would just hide the immediate crash.
So if somebody could take a look at this...
Reported-by: <ovariegata@yahoo.com>
Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
---
src/mesa/state_tracker/st_atom_framebuffer.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c b/src/mesa/state_tracker/st_atom_framebuffer.c
index ea41d9d..3ee4ea5 100644
--- a/src/mesa/state_tracker/st_atom_framebuffer.c
+++ b/src/mesa/state_tracker/st_atom_framebuffer.c
@@ -177,8 +177,10 @@ update_framebuffer_state( struct st_context *st )
/* rendering to a GL texture, may have to update surface */
st_update_renderbuffer_surface(st, strb);
}
- pipe_surface_reference(&framebuffer->zsbuf, strb->surface);
- update_framebuffer_size(framebuffer, strb->surface);
+ if (strb->surface) {
+ pipe_surface_reference(&framebuffer->zsbuf, strb->surface);
+ update_framebuffer_size(framebuffer, strb->surface);
+ }
}
else {
strb = st_renderbuffer(fb->Attachment[BUFFER_STENCIL].Renderbuffer);
--
2.9.2"
**Attachment 129055**, "Apitrace.":
[openmw_nouveau_dri3.trace.xz](/uploads/66f7c6188bfa51bcccf2889a9e7d25f6/openmw_nouveau_dri3.trace.xz)
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/878osmesa gallium build with scons on linux contains no OSMesa* and GL* symbols2020-12-02T01:15:12ZBugzilla Migration Userosmesa gallium build with scons on linux contains no OSMesa* and GL* symbols## Submitted by Andreas Fänger
Assigned to **mes..@..op.org**
**[Link to original bug (#94489)](https://bugs.freedesktop.org/show_bug.cgi?id=94489)**
## Description
When osmesa is build on linux using scons, then it contains none ...## Submitted by Andreas Fänger
Assigned to **mes..@..op.org**
**[Link to original bug (#94489)](https://bugs.freedesktop.org/show_bug.cgi?id=94489)**
## Description
When osmesa is build on linux using scons, then it contains none of the OSMesa specific symbols nor any of the gl* symbols. So it's basically broken.
mesa-git # scons build=release
mesa-git # nm build/linux-x86_64/gallium/targets/osmesa/libosmesa.so | grep OSMesaCreateContext
(no result)
mesa-git # nm lib/gallium/libOSMesa.so | grep glCreate
(no result)
However, when osmesa is build with make, then it contains all of the symbols:
mesa-git # ./configure --enable-gallium-osmesa --with-gallium-drivers=swrast --disable-llvm-shared-libs --disable-driglx-direct --disable-dri --disable-glx --disable-egl
mesa-git # make
mesa-git # nm lib/gallium/libOSMesa.so | grep OSMesaCreateContext
00000000004a1a40 T OSMesaCreateContext
00000000004a1610 t OSMesaCreateContextAttribs
00000000004a19e0 T OSMesaCreateContextExt
mesa-git # nm lib/gallium/libOSMesa.so | grep glCreate
00000000004ad370 T glCreateProgram
00000000004b2620 T glCreateProgramObjectARB
00000000004ad3a0 T glCreateShader
00000000004b2650 T glCreateShaderObjectARB
Just for reference, the classic osmesa (swrast) version build with scons also contains all symbols (even more (!) than gallium osmesa glCreateShaderProgramEXT/glCreateTextures):
mesa-10.5.9 # scons build=release openmp=true osmesa
mesa-10.5.9 # nm build/linux-x86_64/mesa/drivers/osmesa/libosmesa.so | grep OSMesaCreateContext
000000000005a740 T OSMesaCreateContext
000000000005a320 T OSMesaCreateContextExt
mesa-10.5.9 # nm build/linux-x86_64/mesa/drivers/osmesa/libosmesa.so | grep glCreate
00000000000637e0 T glCreateProgram
0000000000064fc0 T glCreateProgramObjectARB
0000000000063800 T glCreateShader
0000000000064fe0 T glCreateShaderObjectARB
0000000000069150 T glCreateShaderProgramEXT
0000000000066de0 T glCreateTextures
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/879osmesa gallium build with scons on windows is missing a lot of GL* symbols2021-09-03T21:29:41ZBugzilla Migration Userosmesa gallium build with scons on windows is missing a lot of GL* symbols## Submitted by Andreas Fänger
Assigned to **mes..@..op.org**
**[Link to original bug (#94491)](https://bugs.freedesktop.org/show_bug.cgi?id=94491)**
## Description
Created attachment 122219
dumpbin-osmesa-git-gallium
The osmesa....## Submitted by Andreas Fänger
Assigned to **mes..@..op.org**
**[Link to original bug (#94491)](https://bugs.freedesktop.org/show_bug.cgi?id=94491)**
## Description
Created attachment 122219
dumpbin-osmesa-git-gallium
The osmesa.dll (gallium) build with scons on windows is missing a lot of symbols. It seems that only the OpenGL<2.0 symbols are contained in the dll.
dumpbin /EXPORTS mesa-git\build\windows-x86\gallium\targets\osmesa\osmesa.dll
in total there are 336 gl* symbols. E.g. glClear or glVertex3d. However,
glCreateProgram or glCreateShader is missing.
The classic osmesa.dll (swrast) contain many more symbols:
dumpbin /EXPORTS mesa-10.5.9\build\windows-x86\mesa\drivers\osmesa\osmesa.dll
in total there are 1436 gl* symbols. For example, it contains glCreateProgram, glCreateProgramObjectARB, glCreateShader, glCreateShaderObjectARB, glCreateShaderProgramEXT and glCreateTextures.
I'v attached the dumpbin output of both dll's
**Attachment 122219**, "dumpbin-osmesa-git-gallium":
[osmesa-git-gallium.txt](/uploads/f04c7793be36c7abf227e886cbfd0e08/osmesa-git-gallium.txt)
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/876OSMesa Gallium Segfault in VTK Test2021-09-03T21:28:06ZBugzilla Migration UserOSMesa Gallium Segfault in VTK Test## Submitted by Kevin Hobbs
Assigned to **mes..@..op.org**
**[Link to original bug (#63472)](https://bugs.freedesktop.org/show_bug.cgi?id=63472)**
## Description
Created attachment 77885
gdb backtrace of segfaulting test
Since OS...## Submitted by Kevin Hobbs
Assigned to **mes..@..op.org**
**[Link to original bug (#63472)](https://bugs.freedesktop.org/show_bug.cgi?id=63472)**
## Description
Created attachment 77885
gdb backtrace of segfaulting test
Since OSMesa Switched to Gallium The VTK test :
vtkRenderingVolumePython-cursor3D
has been segfaulting on one of the two machines which run the test with OSMesa from git.
I ran the test in gdb and got the backtrace in the attached vtk_osmesa_backtrace.txt
On a hunch I tried setting breakpoints at cso_release_all and vtkOSOpenGLRenderWindow::DestroyOffScreenWindow but they are entered only once.
**Attachment 77885**, "gdb backtrace of segfaulting test":
[vtk_osmesa_backtrace.txt](/uploads/7d9f2fbc696b5eb1517101e4f1014e7a/vtk_osmesa_backtrace.txt)
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/883osmesa gallium state tracker: Leak of screens and buffers on exit/shared libr...2020-12-05T00:20:40ZBugzilla Migration Userosmesa gallium state tracker: Leak of screens and buffers on exit/shared library unload## Submitted by Ricardo Barreira
Assigned to **Ricardo Barreira**
**[Link to original bug (#106542)](https://bugs.freedesktop.org/show_bug.cgi?id=106542)**
## Description
state_trackers/osmesa/osmesa.c does not destroy screens and...## Submitted by Ricardo Barreira
Assigned to **Ricardo Barreira**
**[Link to original bug (#106542)](https://bugs.freedesktop.org/show_bug.cgi?id=106542)**
## Description
state_trackers/osmesa/osmesa.c does not destroy screens and buffers on exit. This is a problem when using mesa in dynamically-loaded libraries.
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/885OSMesaGetDepthBuffer flipped vertically2020-12-05T00:20:40ZBugzilla Migration UserOSMesaGetDepthBuffer flipped vertically## Submitted by pop..@..isk.fr
Assigned to **mes..@..op.org**
**[Link to original bug (#108853)](https://bugs.freedesktop.org/show_bug.cgi?id=108853)**
## Description
When installing OSMesa using
./configure --prefix=$install_dir...## Submitted by pop..@..isk.fr
Assigned to **mes..@..op.org**
**[Link to original bug (#108853)](https://bugs.freedesktop.org/show_bug.cgi?id=108853)**
## Description
When installing OSMesa using
./configure --prefix=$install_dir \
--enable-opengl --disable-gles1 --disable-gles2 \
--disable-va --disable-xvmc --disable-vdpau \
--enable-shared-glapi \
--disable-texture-float \
--with-gallium-drivers=swrast \
--disable-dri --with-dri-drivers= \
--disable-egl --with-platforms= --disable-gbm \
--enable-glx --with-platforms=x11 \
--disable-osmesa --enable-gallium-osmesa
i.e. using the gallium osmesa implementation, the depth buffer returned by OSMesaGetDepthBuffer is flipped vertically relative to the OSMesa framebuffer.
Using the non-gallium osmesa implementation returns a depth buffer correctly aligned with the framebuffer.
The gallium-returned depth buffer can be fixed using something like:
fbdepth_t * framebuffer_depth (framebuffer * p)
{
unsigned int * depth;
GLint width, height, bytesPerValue;
OSMesaGetDepthBuffer (p->ctx, &width, &height, &bytesPerValue,
(void **)&depth);
assert (p->width == width && p->height == height && bytesPerValue == 4);
assert (sizeof(fbdepth_t) == bytesPerValue);
#if GALLIUM
// fix for bug in gallium/libosmesa
// the depth buffer is flipped vertically
for (GLint j = 0; j < height/2; j++)
for (GLint i = 0; i < width; i++) {
unsigned int tmp = depth[j*width + i];
depth[j*width + i] = depth[(height - 1 - j)*width + i];
depth[(height - 1 - j)*width + i] = tmp;
}
#endif // GALLIUM
return depth;
}
Version: 18.2https://gitlab.freedesktop.org/mesa/mesa/-/issues/874OSMesaMakeCurrent not properly changing contexts2020-12-03T01:14:18ZBugzilla Migration UserOSMesaMakeCurrent not properly changing contexts## Submitted by James Burns
Assigned to **mes..@..op.org**
**[Link to original bug (#11161)](https://bugs.freedesktop.org/show_bug.cgi?id=11161)**
## Description
Tracked this down to the check_compatible method in context.c. The ...## Submitted by James Burns
Assigned to **mes..@..op.org**
**[Link to original bug (#11161)](https://bugs.freedesktop.org/show_bug.cgi?id=11161)**
## Description
Tracked this down to the check_compatible method in context.c. The depth bits comparison is failing as the OSMesa context creation is using a default of 31 bits for depth. The framebuffer/renderbuffer that is being compared against the context is made with 32 bits, and apparently can not be made with 31 bits (reference renderbuffer.c).
I was able to bypass the depth bit comparison in check_compatible and all works. I am not positive what effect removal of this comparison might have in the bigger scheme, so someone may want to look at this bypass or changing of the OSMESA default depth buffer size.
Version: 6.5https://gitlab.freedesktop.org/mesa/mesa/-/issues/1213Packet0 not allowed and GPU fault detected errors with Serious Engine games2021-01-14T15:08:10ZBugzilla Migration UserPacket0 not allowed and GPU fault detected errors with Serious Engine games## Submitted by Daniel Scharrer
Assigned to **Default DRI bug account**
**[Link to original bug (#87278)](https://bugs.freedesktop.org/show_bug.cgi?id=87278)**
## Description
Created attachment 110808
dmesg output with the GPU fau...## Submitted by Daniel Scharrer
Assigned to **Default DRI bug account**
**[Link to original bug (#87278)](https://bugs.freedesktop.org/show_bug.cgi?id=87278)**
## Description
Created attachment 110808
dmesg output with the GPU fault errors filtered out
Running Serious Sam 3 or The Talos Principle spams dmesg with thousands of these errors:
[ 6001.212237] radeon 0000:01:00.0: GPU fault detected: 147 0x02528801
[ 6001.212243] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0FF02192
[ 6001.212246] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x12088001
[ 6001.212249] VM fault (0x01, vmid 9) at page 267395474, read from TC (136)
There are also a few "Packet0 not allowed" errors (followed by a hex dump):
[15446.473341] radeon 0000:01:00.0: Packet0 not allowed!
So far it's only these errors in dmesg - I haven't observed any actual rendering issues, crashes, GPU lockups because of this.
I have only attached a filtered kernel log with the GPU fault errors removed - the full log is available at http://constexpr.org/tmp/serious-dmesg.log (140 MiB).
Both of these games use the Serious Engine 3.5 (Serious Sam 3) or 4 (The Talos Principle). This is also reproducible with The Talos Principle Public Test which as of now is still available as a free download on Steam.
Kernel: 3.18.0-gentoo
GPU: Radeon HD 7950
Driver: radeonsi, Mesa 10.5.0-devel (git-ff96537)
This might be related to [bug 84500](https://bugs.freedesktop.org/show_bug.cgi?id=84500) - however those spurious Packet0 have been gone for a while now with updated Mesa - now I got them again but only while running Serious Engine games.
**Attachment 110808**, "dmesg output with the GPU fault errors filtered out":
[serious-dmesg-filtered.log](/uploads/29efc5655758f86e313b3d4f6329ee10/serious-dmesg-filtered.log)
Version: git
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=84500https://gitlab.freedesktop.org/mesa/mesa/-/issues/255Panfrost: add current status to docs/features.txt2020-07-09T15:00:29ZBugzilla Migration UserPanfrost: add current status to docs/features.txt## Submitted by dllud
Assigned to **mes..@..op.org**
**[Link to original bug (#111130)](https://bugs.freedesktop.org/show_bug.cgi?id=111130)**
## Description
It would be much handy if the Panfrost driver developers could keep docs...## Submitted by dllud
Assigned to **mes..@..op.org**
**[Link to original bug (#111130)](https://bugs.freedesktop.org/show_bug.cgi?id=111130)**
## Description
It would be much handy if the Panfrost driver developers could keep docs/features.txt in sync with the current Panfrost status. That way people could easily check the driver status with tools such as mesamatrix.net
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1345Parkitect (Unity Game) dispalys artifacts and black screens with Vega hardware2020-09-25T08:58:17ZBugzilla Migration UserParkitect (Unity Game) dispalys artifacts and black screens with Vega hardware## Submitted by Juyas Yove
Assigned to **Default DRI bug account**
**[Link to original bug (#108919)](https://bugs.freedesktop.org/show_bug.cgi?id=108919)**
## Description
Created attachment 142689
Screenshot of one of the possibl...## Submitted by Juyas Yove
Assigned to **Default DRI bug account**
**[Link to original bug (#108919)](https://bugs.freedesktop.org/show_bug.cgi?id=108919)**
## Description
Created attachment 142689
Screenshot of one of the possible outcomes of starting the game
Issue: Vega hardware not working with Parkitect. The game is based on Unity. Lots of artifacts, particularly with ambient occlusion turned up in game's settings
Steps to reproduce: Start a game in parkitect with Vega hardware. Turn the graphics settings to max and you will experience issues.
Sometimes it's playable, but always with artifacts
Happy to provide logs and feedback.
Some notes:
https://www.reddit.com/r/ThemeParkitect/comments/a0oboe/black_screen_on_linux_with_rx_vega_56/
Tested this with Mesa 18.2.4 and 18.3 in Fedora 29 (also had issues in Fedora 28).
Happy to donate a copy of the game to a known dev.
**Attachment 142689**, "Screenshot of one of the possible outcomes of starting the game":
![parkitect1](/uploads/9511a20035f82125ff0327cf47e476a0/parkitect1.png)
Version: 18.2https://gitlab.freedesktop.org/mesa/mesa/-/issues/155Patch for dangling disp->DriverData pointer in error path2020-09-17T18:20:25ZBugzilla Migration UserPatch for dangling disp->DriverData pointer in error path## Submitted by John Wehle
Assigned to **mes..@..op.org**
**[Link to original bug (#94710)](https://bugs.freedesktop.org/show_bug.cgi?id=94710)**
## Description
Created attachment 122571
Patch for problem.
Noticed while looking a...## Submitted by John Wehle
Assigned to **mes..@..op.org**
**[Link to original bug (#94710)](https://bugs.freedesktop.org/show_bug.cgi?id=94710)**
## Description
Created attachment 122571
Patch for problem.
Noticed while looking at a crash the following code pattern:
dri2_dpy = calloc(1, sizeof *dri2_dpy);
disp->DriverData = (void *) dri2_dpy;
...
if error goto cleanup
return success
cleanup:
free(dri2_dpy)
return failure
The problem being that on failure disp->DriverData is left pointing to
memory which has already been freed. Granted no one should be accessing
it after a failure, however if someone does then random things may occur.
The attached patch sets disp->DriverData to NULL on failure so that more
predictable behavior occurs if someone does happen to accesses it.
**Attachment 122571**, "Patch for problem.":
[egl-dangle.txt](/uploads/fe83046aa05c7be0c50437a946e663ad/egl-dangle.txt)
Version: 11.1https://gitlab.freedesktop.org/mesa/mesa/-/issues/107[PATCH] glx: usability: *must* also log issue context ("failed to open drm de...2022-08-23T20:43:47ZBugzilla Migration User[PATCH] glx: usability: *must* also log issue context ("failed to open drm device").## Submitted by Andreas Mohr
Assigned to **mes..@..op.org**
**[Link to original bug (#98163)](https://bugs.freedesktop.org/show_bug.cgi?id=98163)**
## Description
Created attachment 127139
[PATCH] glx: usability: *must* also log i...## Submitted by Andreas Mohr
Assigned to **mes..@..op.org**
**[Link to original bug (#98163)](https://bugs.freedesktop.org/show_bug.cgi?id=98163)**
## Description
Created attachment 127139
[PATCH] glx: usability: *must* also log issue context (at "failed to open drm device").
Hello,
[closely related complaint: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1539046 ]
On Debian with current libgl1-mesa-glx:i386 12.0.3-1,
when doing [issue reproduction...]
- install mpv
- make sure that user does not show "video" group in "groups" command
- mpv MOVIE.mpeg
I am getting
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: r200
which has a problematic lack of useful context info
(most importantly, the device name is missing).
LANG=C ls -l /dev/dri
total 0
crw-rw----+ 1 root video 226, 0 Sep 8 21:29 card0
crw-rw---- 1 root video 226, 64 Sep 8 21:29 controlD64
crw-rw----+ 1 root video 226, 128 Sep 8 21:29 renderD128
IMHO the libGL error message has rather poor usability,
leading to the issues of
having a
not sufficiently easily correctable configuration problem
as observed by the other public report and mine.
thus I decided to create
the attached UNTESTED patch (well, git commit on trunk).
I am submitting this issue as
a bug report (with UNTESTED patch) rather than
a mailing list patch,
since completely unrelated outside developers
really can't be bothered
(there's the "usability" thingy again)
to have e.g. balance of a busy work/life endangered by
doing process/build/install/test of a
completely foreign multi-100-MB component
on a rather slow system to boot *),
for a nine-liner diffstat
(where the implementer would originally have needed
an additional measly 10s to have proper reporting provided),
as opposed to core developers
who are fully familiar and thus
always have that kind of environment fully active/testable.
So, probably simply consider this to be a more helpful
"issue report with suggestion of a patch and reproduction hints" rather than
"issue report".
Thanks, also for a very nice and important infrastructure component!
Andreas Mohr
*)
# LANG=C apt-get source libgl1-mesa-glx:i386
Reading package lists... Done
Picking 'mesa' as source package instead of 'libgl1-mesa-glx'
NOTICE: 'mesa' packaging is maintained in the 'Git' version control system at:
https://anonscm.debian.org/git/pkg-xorg/lib/mesa.git
Please use:
git clone https://anonscm.debian.org/git/pkg-xorg/lib/mesa.git
to retrieve the latest (possibly unreleased) updates to the package.
E: You don't have enough free space in ..
**Patch 127139**, "[PATCH] glx: usability: *must* also log issue context (at "failed to open drm device").":
[0001-glx-usability-must-also-log-issue-context-at-failed-.patch](/uploads/f63d6187a1ee5a8967e3b9d262b41777/0001-glx-usability-must-also-log-issue-context-at-failed-.patch)
Version: git
### See also
* https://launchpad.net/bugs/1539046https://gitlab.freedesktop.org/mesa/mesa/-/issues/1043PBO unpacking is not accelerated2021-07-27T16:20:55ZBugzilla Migration UserPBO unpacking is not accelerated## Submitted by Whatcookie
Assigned to **mes..@..op.org**
**[Link to original bug (#111043)](https://bugs.freedesktop.org/show_bug.cgi?id=111043)**
## Description
While investigating performance bottlenecks with RPCS3 while using ...## Submitted by Whatcookie
Assigned to **mes..@..op.org**
**[Link to original bug (#111043)](https://bugs.freedesktop.org/show_bug.cgi?id=111043)**
## Description
While investigating performance bottlenecks with RPCS3 while using Radeonsi, I came across a scene which was only getting 1FPS, while spending 99% of the CPU time in the driver. Further investigation led to the discovery that using the GL_STREAM_COPY flag instead of GL_STATIC_COPY led to performance increasing to 11fps.
This prompted us to look into Mesa's code for an explanation, since the operation here should be moving data between GPU memory to GPU memory, and shouldn't be faster with GL_STREAM_COPY.
We came across this https://gitlab.freedesktop.org/mesa/mesa/commit/a338dc01866ce50bf7555ee8dc08491c7f63b585 which provided an explanation for why GL_STREAM_COPY was faster.
Anyways, point is we need PBO unpacking acceleration for this to be any faster. Even when using the GL_STREAM_COPY flag about 90% of the time spent in the graphics thread is spent in a single function in the driver.
Thanks.
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1271Peace, Death! crashed on start-up2020-03-24T08:53:21ZBugzilla Migration UserPeace, Death! crashed on start-up## Submitted by Timothy Arceri `@tarceri`
Assigned to **Default DRI bug account**
**[Link to original bug (#101675)](https://bugs.freedesktop.org/show_bug.cgi?id=101675)**
## Description
Crashes on LLVMpipe and radeonsi.
```
#0 ...## Submitted by Timothy Arceri `@tarceri`
Assigned to **Default DRI bug account**
**[Link to original bug (#101675)](https://bugs.freedesktop.org/show_bug.cgi?id=101675)**
## Description
Crashes on LLVMpipe and radeonsi.
```
#0 0xf7fd4c89 in __kernel_vsyscall ()
#1 0xf76bd9a0 in raise () from /lib/libc.so.6
#2 0xf76bf067 in abort () from /lib/libc.so.6
#3 0xf76fc3ff in __libc_message () from /lib/libc.so.6
#4 0xf7705fde in _int_free () from /lib/libc.so.6
#5 0xf77098c3 in free () from /lib/libc.so.6
#6 0xf2441a0c in operator delete(void*) () from /lib/libLLVM-5.0svn.so
#7 0xf244050c in operator delete(void*, unsigned int) () from /lib/libLLVM-5.0svn.so
#8 0xf370ae33 in check_explicit_uniform_locations (ctx=<optimized out>, prog=<optimized out>) at glsl/linker.cpp:3485
#9 link_shaders (ctx=<optimized out>, prog=<optimized out>) at glsl/linker.cpp:4870
#10 0xf3648ecd in _mesa_glsl_link_shader (ctx=0x891b9f8, prog=0x895c798) at program/ir_to_mesa.cpp:3101
#11 0xf344e042 in create_new_program (key=0xffffacec, ctx=<optimized out>) at main/ff_fragment_shader.cpp:1126
#12 _mesa_get_fixed_func_fragment_program (ctx=<optimized out>) at main/ff_fragment_shader.cpp:1156
#13 0xf354b05d in update_program (ctx=ctx@entry=0x891b9f8) at main/state.c:134
#14 0xf354b355 in _mesa_update_state_locked (ctx=0x891b9f8) at main/state.c:348
#15 0xf354b452 in _mesa_update_state (ctx=0x891b9f8) at main/state.c:386
#16 0xf3563701 in teximage (no_error=false, pixels=0x0, imageSize=0, type=5121, format=6408, border=0, depth=<optimized out>,
height=<optimized out>, width=<optimized out>, internalFormat=32856, level=0, target=3553, dims=2, compressed=0 '\000',
ctx=0x891b9f8) at main/teximage.c:3035
#17 teximage_err (ctx=0x891b9f8, compressed=compressed@entry=0 '\000', dims=dims@entry=2, target=3553, level=0,
internalFormat=<optimized out>, width=2000, height=2000, depth=1, border=<optimized out>, format=6408, type=5121,
imageSize=0, pixels=0x0) at main/teximage.c:3084
#18 0xf3565c5a in _mesa_TexImage2D (target=3553, level=0, internalFormat=32856, width=2000, height=2000, border=0,
format=6408, type=5121, pixels=0x0) at main/teximage.c:3122
```
Version: git
### Depends on
* [Bug 105797](https://bugs.freedesktop.org/show_bug.cgi?id=105797)
### Blocking
* [Bug 77449](https://bugs.freedesktop.org/show_bug.cgi?id=77449)https://gitlab.freedesktop.org/mesa/mesa/-/issues/138[performance] clover: implement non-blocking clEnqueueWriteBuffer and clEnque...2020-07-14T09:57:05ZBugzilla Migration User[performance] clover: implement non-blocking clEnqueueWriteBuffer and clEnqueueReadBuffer## Submitted by Vedran Miletić
Assigned to **Vedran Miletić**
**[Link to original bug (#100199)](https://bugs.freedesktop.org/show_bug.cgi?id=100199)**
## Description
Right now most of the transfer functions do something roughly i...## Submitted by Vedran Miletić
Assigned to **Vedran Miletić**
**[Link to original bug (#100199)](https://bugs.freedesktop.org/show_bug.cgi?id=100199)**
## Description
Right now most of the transfer functions do something roughly in between
blocking and non-blocking transfers, and blocking boolean parameter is ignored. We should implement support for non-blocking transfer and clearly separate the two.
Version: git
### Blocking
* [Bug 99553](https://bugs.freedesktop.org/show_bug.cgi?id=99553)
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=102179