mesa issueshttps://gitlab.freedesktop.org/mesa/mesa/-/issues2022-04-04T05:43:02Zhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1616[IVB BYT] piglit.spec.arb_gpu_shader_fp64.varying-packing.simple double* regr...2022-04-04T05:43:02ZBugzilla Migration User[IVB BYT] piglit.spec.arb_gpu_shader_fp64.varying-packing.simple double* regression## Submitted by Mark Janes `@majanes`
Assigned to **Samuel Iglesias Gonsálvez `@samuelig`**
**[Link to original bug (#101985)](https://bugs.freedesktop.org/show_bug.cgi?id=101985)**
## Description
Bisected to:
ad55b1a7701ad51234af...## Submitted by Mark Janes `@majanes`
Assigned to **Samuel Iglesias Gonsálvez `@samuelig`**
**[Link to original bug (#101985)](https://bugs.freedesktop.org/show_bug.cgi?id=101985)**
## Description
Bisected to:
ad55b1a7701ad51234af3b9fc30f4c54d2546b86
Author: Timothy Arceri <timothy.arceri@collabora.com>
i965: remove GLSL IR optimisation loop
IVB is running into some spilling issues in piglit with the
loop removed. However those tests are not really reflective
of a real world use case, also fp64 is brand new to IVB
so we leave the spilling issues to be resolved at a later
time.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
piglit.spec.arb_gpu_shader_fp64.varying-packing.simple double separate
Standard Output
/tmp/build_root/m32/lib/piglit/bin/varying-packing-simple double separate -auto -fbo
piglit: debug: Requested an OpenGL 3.2 Core Context, and received a matching 4.2 context
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 0 0 0 0
Standard Error
Mesa 17.2.0-rc1 implementation error: Failed to compile vertex shader: VS compile failed: no register to spill
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
Failed to link: VS compile failed: no register to spill
Mesa: User error: GL_INVALID_VALUE in glGetUniformLocation
Mesa: User error: GL_INVALID_OPERATION in glUniform(program not linked)
Version: 17.2https://gitlab.freedesktop.org/mesa/mesa/-/issues/390r600: glPolygonStipple broken2022-03-23T23:07:12ZBugzilla Migration Userr600: glPolygonStipple broken## Submitted by Rafael Monica
Assigned to **Default DRI bug account**
**[Link to original bug (#25280)](https://bugs.freedesktop.org/show_bug.cgi?id=25280)**
## Description
Filling a polygon with a stipple pattern with glPolygonSt...## Submitted by Rafael Monica
Assigned to **Default DRI bug account**
**[Link to original bug (#25280)](https://bugs.freedesktop.org/show_bug.cgi?id=25280)**
## Description
Filling a polygon with a stipple pattern with glPolygonStipple is broken on r600.
With the software renderer the program progs/redbook/polys renders three rectangles, two of them with a stipple pattern. The r600 driver renders all the three rectangles with a solid color.
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/219[softpipe] pigilt arb_internalformat_query2-image-texture regression2022-03-13T02:56:17ZBugzilla Migration User[softpipe] pigilt arb_internalformat_query2-image-texture regression## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#103748)](https://bugs.freedesktop.org/show_bug.cgi?id=103748)**
## Description
mesa: 5041ea96a0544283c3cf3885d6e2d2d0ba4857f5 (master 17.4.0-devel...## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#103748)](https://bugs.freedesktop.org/show_bug.cgi?id=103748)**
## Description
mesa: 5041ea96a0544283c3cf3885d6e2d2d0ba4857f5 (master 17.4.0-devel)
$ ./bin/arb_internalformat_query2-image-texture -auto
32 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_R11F_G11F_B10F, expected value = (32), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2UI, expected value = (32), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2, expected value = (32), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA16_SNORM, expected value = (64), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA8_SNORM, expected value = (32), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RG16_SNORM, expected value = (32), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RG8_SNORM, expected value = (16), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_R16_SNORM, expected value = (16), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_R8_SNORM, expected value = (8), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_R11F_G11F_B10F, expected value = (32), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2UI, expected value = (32), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2, expected value = (32), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA16_SNORM, expected value = (64), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA8_SNORM, expected value = (32), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RG16_SNORM, expected value = (32), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_RG8_SNORM, expected value = (16), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_R16_SNORM, expected value = (16), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_TEXEL_SIZE, target = GL_TEXTURE_BUFFER, internalformat = GL_R8_SNORM, expected value = (8), params[0] = (0,GL_POINTS), supported=1
PIGLIT: {"subtest": {"GL_IMAGE_TEXEL_SIZE" : "fail"}}
32 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_R11F_G11F_B10F, expected value = (33474), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2UI, expected value = (33475), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2, expected value = (33475), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA16_SNORM, expected value = (33468), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA8_SNORM, expected value = (33471), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RG16_SNORM, expected value = (33469), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RG8_SNORM, expected value = (33472), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_R16_SNORM, expected value = (33470), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_R8_SNORM, expected value = (33473), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_R11F_G11F_B10F, expected value = (33474), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2UI, expected value = (33475), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2, expected value = (33475), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA16_SNORM, expected value = (33468), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA8_SNORM, expected value = (33471), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RG16_SNORM, expected value = (33469), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_RG8_SNORM, expected value = (33472), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_R16_SNORM, expected value = (33470), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_COMPATIBILITY_CLASS, target = GL_TEXTURE_BUFFER, internalformat = GL_R8_SNORM, expected value = (33473), params[0] = (0,GL_POINTS), supported=1
PIGLIT: {"subtest": {"GL_IMAGE_COMPATIBILITY_CLASS" : "fail"}}
32 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_R11F_G11F_B10F, expected value = (6407), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2UI, expected value = (36249), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2, expected value = (6408), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA16_SNORM, expected value = (6408), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA8_SNORM, expected value = (6408), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RG16_SNORM, expected value = (33319), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RG8_SNORM, expected value = (33319), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_R16_SNORM, expected value = (6403), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_R8_SNORM, expected value = (6403), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_R11F_G11F_B10F, expected value = (6407), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2UI, expected value = (36249), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2, expected value = (6408), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA16_SNORM, expected value = (6408), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA8_SNORM, expected value = (6408), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RG16_SNORM, expected value = (33319), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_RG8_SNORM, expected value = (33319), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_R16_SNORM, expected value = (6403), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_FORMAT, target = GL_TEXTURE_BUFFER, internalformat = GL_R8_SNORM, expected value = (6403), params[0] = (0,GL_POINTS), supported=1
PIGLIT: {"subtest": {"GL_IMAGE_PIXEL_FORMAT" : "fail"}}
32 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_R11F_G11F_B10F, expected value = (35899), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2UI, expected value = (33640), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2, expected value = (33640), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA16_SNORM, expected value = (5122), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA8_SNORM, expected value = (5120), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RG16_SNORM, expected value = (5122), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RG8_SNORM, expected value = (5120), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_R16_SNORM, expected value = (5122), params[0] = (0,GL_POINTS), supported=1
32 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_R8_SNORM, expected value = (5120), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_R11F_G11F_B10F, expected value = (35899), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2UI, expected value = (33640), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGB10_A2, expected value = (33640), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA16_SNORM, expected value = (5122), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RGBA8_SNORM, expected value = (5120), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RG16_SNORM, expected value = (5122), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_RG8_SNORM, expected value = (5120), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_R16_SNORM, expected value = (5122), params[0] = (0,GL_POINTS), supported=1
64 bit failing case: pname = GL_IMAGE_PIXEL_TYPE, target = GL_TEXTURE_BUFFER, internalformat = GL_R8_SNORM, expected value = (5120), params[0] = (0,GL_POINTS), supported=1
PIGLIT: {"subtest": {"GL_IMAGE_PIXEL_TYPE" : "fail"}}
PIGLIT: {"result": "fail" }
272fe9494232baab159d10901aecfe1786595b17 is the first bad commit
commit 272fe9494232baab159d10901aecfe1786595b17
Author: Marek Olšák <marek.olsak@amd.com>
Date: Thu Oct 19 22:22:15 2017 +0200
mesa: enable ARB_texture_buffer_* extensions in the Compatibility profile
We already have piglit tests testing alpha, luminance, and intensity
formats. They were skipped by piglit until now.
Additionally, I'm enabling one ARB_texture_buffer_range piglit test to run
with the compat profile.
i965 behavior is unchanged except that it doesn't expose TBOs in the Compat
profile. Not sure how that affects the GL version override.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
:040000 040000 9ff97a01beb251d630b4f700f9c474de0f692cf6 35e692b0c6307be2ce982767477ed6d789b7a5fd M src
bisect run success
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/400r600g readPixSanity failure on RS880 Radeon HD 42502022-03-10T20:54:38ZBugzilla Migration Userr600g readPixSanity failure on RS880 Radeon HD 4250## Submitted by Nicholas Miell `@nmiell`
Assigned to **Default DRI bug account**
**[Link to original bug (#40790)](https://bugs.freedesktop.org/show_bug.cgi?id=40790)**
## Description
Created attachment 51059
Results for glean/rea...## Submitted by Nicholas Miell `@nmiell`
Assigned to **Default DRI bug account**
**[Link to original bug (#40790)](https://bugs.freedesktop.org/show_bug.cgi?id=40790)**
## Description
Created attachment 51059
Results for glean/readPixSanity
readPixSanity fails with both Mesa 7.11 and current git (2154c672b3f2a0f3de7aaacd9260954b9310262a) on ATI Technologies Inc RS880 [Radeon HD 4250] using the Gallium R600 driver.
Test failure is:
readPixSanity: FAIL rgba8, db, z24, s8, win+pmap, id 33
Depth worst-case error was 8.39711 bits at (31, 31)
expected 0.10967; got 0.10965.
RGBA largest readback error was 0 bits
Depth largest readback error was 8.39711 bits
readPixSanity: FAIL rgba8, db, z24, s8, win+pmap, id 34
Depth worst-case error was 8.39711 bits at (31, 31)
expected 0.10967; got 0.10965.
RGBA largest readback error was 0 bits
Depth largest readback error was 8.39711 bits
readPixSanity: FAIL rgba8, db, z24, s8, win+pmap, id 109
Depth worst-case error was 8.39711 bits at (31, 31)
expected 0.10967; got 0.10965.
RGBA largest readback error was 0 bits
Depth largest readback error was 8.39711 bits
In addition, the following X error is generated:
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 136 (DRI2)
Minor opcode of failed request: 8 (DRI2SwapBuffers )
Resource id in failed request: 0x220000b
Serial number of failed request: 1280
Current serial number in output stream: 1280
Relevant packages:
xorg-x11-server-Xorg-1.10.4-1.fc15.x86_64
xorg-x11-drv-ati-6.14.1-2.20110525gitfe5c42f51.fc15.x86_64
kernel-2.6.40.4-5.fc15.x86_64 (that's 3.0.4 with a mangled version)
~~**Attachment 51059**~~, "Results for glean/readPixSanity":
[test_glean__readPixSanity.html](/uploads/a6a4352126dec702e9820a4116084d5f/test_glean__readPixSanity.html)
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1762glBlitFramebuffer issue with max possible buffer sizes2022-03-09T09:31:11ZBugzilla Migration UserglBlitFramebuffer issue with max possible buffer sizes## Submitted by vadym
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#108088)](https://bugs.freedesktop.org/show_bug.cgi?id=108088)**
## Description
https://patchwork.freedesktop.org/patch/253442/
Version: 18.2## Submitted by vadym
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#108088)](https://bugs.freedesktop.org/show_bug.cgi?id=108088)**
## Description
https://patchwork.freedesktop.org/patch/253442/
Version: 18.2https://gitlab.freedesktop.org/mesa/mesa/-/issues/108Some Unity games fail assertion on startup in glXCreateContextAttribsARB2022-02-04T10:26:31ZBugzilla Migration UserSome Unity games fail assertion on startup in glXCreateContextAttribsARB## Submitted by Nicholas Miell `@nmiell`
Assigned to **Hal Gentz**
**[Link to original bug (#99781)](https://bugs.freedesktop.org/show_bug.cgi?id=99781)**
## Description
Multiple Unity games die during startup due to an assertion ...## Submitted by Nicholas Miell `@nmiell`
Assigned to **Hal Gentz**
**[Link to original bug (#99781)](https://bugs.freedesktop.org/show_bug.cgi?id=99781)**
## Description
Multiple Unity games die during startup due to an assertion failure in glXCreateContextAttribsARB.
The assertion in question is "Unknown sequence number while processing queue" in poll_for_event() in libX11's src/xcb_io.c. I'm blaming Mesa for now because you've got to start somewhere and some of the other potential culprits (Xlib, XCB) also live in this Bugzilla.
Affected games include: Oxenfree, The Fall.
The stack trace looks like:
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1 0x00007ffff61b051a in __GI_abort () at abort.c:89
#2 0x00007ffff61a6da7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7ffff72b0778 "!xcb_xlib_threads_sequence_lost", file=file@entry=0x7ffff72b05eb "xcb_io.c",
line=line@entry=259, function=function@entry=0x7ffff72b0a28 <__PRETTY_FUNCTION__.14787> "poll_for_event") at assert.c:92
#3 0x00007ffff61a6e52 in __GI___assert_fail (assertion=assertion@entry=0x7ffff72b0778 "!xcb_xlib_threads_sequence_lost", file=file@entry=0x7ffff72b05eb "xcb_io.c", line=line@entry=259,
function=function@entry=0x7ffff72b0a28 <__PRETTY_FUNCTION__.14787> "poll_for_event") at assert.c:101
#4 0x00007ffff723e32a in poll_for_event (dpy=dpy@entry=0x21ca160) at xcb_io.c:256
#5 0x00007ffff723e3db in poll_for_response (dpy=dpy@entry=0x21ca160) at xcb_io.c:274
#6 0x00007ffff723e6cd in _XEventsQueued (dpy=0x21ca160, mode=<optimized out>) at xcb_io.c:349
#7 0x00007ffff7241515 in _XGetRequest (dpy=0x21ca160, type=<optimized out>, len=4) at XlibInt.c:1707
#8 0x00007ffff724162f in _XSeqSyncFunction (dpy=0x21ca160) at XlibInt.c:202
#9 0x00007ffff7240df3 in _XError (dpy=dpy@entry=0x21ca160, rep=rep@entry=0x7fffffffd3e0) at XlibInt.c:1436
#10 0x00007ffff75591a2 in __glXSendErrorForXcb (dpy=dpy@entry=0x21ca160, err=err@entry=0x304bd30) at glx_error.c:81
#11 0x00007ffff7555284 in glXCreateContextAttribsARB (dpy=0x21ca160, config=0x22b3a20, share_context=0x220c3c0, direct=<optimized out>, attrib_list=0x7fffffffd4a0) at create_context.c:119
#12 0x0000000000eac13f in ?? ()
#13 0x0000000000eace22 in ?? ()
#14 0x00000000004654a4 in ?? ()
#15 0x00007ffff6199401 in __libc_start_main (main=0x4641e0, argc=1, argv=0x7fffffffdde8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffddd8)
at ../csu/libc-start.c:289
```
This appears to be timing-dependent or a race condition because the games will sometimes successfully start (e.g. the first time run after booting or after dropping the entire VFS cache), and will definitely start if you've set a breakpoint somewhere that triggers at least once per call to glXCreateContextAttribsARB.
As best as I can tell (by setting 4000 breakpoints in gdb using rbreak), Unity does correctly call XInitThreads() before using Xlib or GLX or creating any threads and only ever makes Xlib & GLX calls on thread 1 anyway. Which suggests the race is between the game client and the X server, assuming it is a race. This makes me wonder about the 32/64 sequence number widening in Xlib/XCB which I do not understand at all. When the assertion fails, event_sequence is something like 4294967378 (i.e. 2^32 + 82) while request is 84.
I've written a little LD_PRELOAD shim that calls usleep() in glXCreateContextAttribsARB which makes the games completely playable.
Version: 13.0https://gitlab.freedesktop.org/mesa/mesa/-/issues/591Radeon r600 glamor corruptions on ARM642022-01-17T19:46:04ZBugzilla Migration UserRadeon r600 glamor corruptions on ARM64## Submitted by Clemens Eisserer
Assigned to **Default DRI bug account**
**[Link to original bug (#97069)](https://bugs.freedesktop.org/show_bug.cgi?id=97069)**
## Description
Created attachment 125306
screenshot running the thuna...## Submitted by Clemens Eisserer
Assigned to **Default DRI bug account**
**[Link to original bug (#97069)](https://bugs.freedesktop.org/show_bug.cgi?id=97069)**
## Description
Created attachment 125306
screenshot running the thunar file manager on ARM64 using glamor acceleration
When running debian on ARM64 we experience graphical artifacts when running 2D applications using glamor (EXA doesn't render any meaningful at all). I get the same corrutions running the modesetting-driver + glamor.
The few OpenGL games I've tried worked fine (sauerbraten, chromium-bsu).
Kernel: 4.1.8
Xorg: 1.18.3
Mesa 11.2.2
GPU: AMD Caicos
**Attachment 125306**, "screenshot running the thunar file manager on ARM64 using glamor acceleration":
![thunar_glamor_arm64](/uploads/dbea3c7c0c29a4c722b31a9050ad9e0b/thunar_glamor_arm64.jpg)
Version: 11.2https://gitlab.freedesktop.org/mesa/mesa/-/issues/103[BSW] Regression: glx@glx_arb_sync_control@timing -fullscreen test Fail2022-01-15T08:08:54ZBugzilla Migration User[BSW] Regression: glx@glx_arb_sync_control@timing -fullscreen test Fail## Submitted by Rami
Assigned to **mes..@..op.org**
**[Link to original bug (#92368)](https://bugs.freedesktop.org/show_bug.cgi?id=92368)**
## Description
Test fail after executing all piglit tests. this test passed with last setu...## Submitted by Rami
Assigned to **mes..@..op.org**
**[Link to original bug (#92368)](https://bugs.freedesktop.org/show_bug.cgi?id=92368)**
## Description
Test fail after executing all piglit tests. this test passed with last setup:
Actual setup:
=============
Hardware:
Platform: Braswell M
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping: 4)
SoC : BSW C0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All Feature Reworks: F28, F32, F33, F35, F37
Optional reworks : O-01a; O-02, O-03
Software :
Linux distribution: Ubuntu 14.04 LTS 64 bits
BIOS : BRAS.X64.B084.R00.1508310642
TXE FW : 2.0.0.2073
Ksc : 1.08
kernel drm-intel-nightly 4.3.0-rc3 eb69e51
cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d from
git://git.freedesktop.org/git/cairo
drm: (HEAD, tag: libdrm-2.4.64, tag: 2.4.64)
ab2fadabde3829b1ec56bd4756165dd9bd281488 from
git://git.freedesktop.org/git/mesa/drm
intel-driver: (HEAD, origin/master, origin/HEAD, master)
2a72f99d24714f2a58f400ef63b913d4cf9080b3 from
git://git.freedesktop.org/git/vaapi/intel-driver
libva: (HEAD, tag: libva-1.6.1, origin/v1.6-branch)
613eb962b45fbbd1526d751e88e0d8897af6c0e0 from
git://git.freedesktop.org/git/vaapi/libva
mesa: (HEAD, tag: mesa 11.0.2) 51e0b06d9916e126060c0d218de1aaa4e5a4ce26
from
git://git.freedesktop.org/git/mesa/mesa
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master)
f0fd4d500de03c30c7ce19915f85acadd1ca4e5d from
git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
xserver: (HEAD, tag: xorg-server-1.17.2)
2123f7682d522619f101b05fb75efa75dabbe371 from
git://git.freedesktop.org/git/xorg/xserver
intel-gpu-tools: (HEAD, origin/master, origin/HEAD, master)
1b492e311ce13fe4bc42f1edd5479441662d4855 from
git://git.freedesktop.org/git/xorg/app/intel-gpu-tools
Last setup:
===========
Hardware:
Platform: Braswell M
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping: 4)
SoC : BSW D0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All
Feature Reworks: F28, F32,F33 & F37
Optional reworks : O-01a
Software :
Linux distribution: Ubuntu 14.04 LTS 64 bits
BIOS : BRAS.X64.B084.R00.1508310642
TXE FW : 2.0.0.2073
Ksc : 1.08
kernel 4.3.0-rc2-drm-intel-nightly+
commit 794e1cdfb84be003dbd287c69501c98ec280a89b
Author: Jani Nikula <jani.nikula@intel.com>
Date: Mon Sep 28 17:28:29 2015 +0300
drm-intel-nightly: 2015y-09m-28d-14h-28m-11s UTC integration manifest
cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d from git://git.freedesktop.org/git/cairo
drm: (HEAD, tag: libdrm-2.4.64, tag: 2.4.64) ab2fadabde3829b1ec56bd4756165dd9bd281488 from git://git.freedesktop.org/git/mesa/drm
intel-driver: (HEAD, origin/master, origin/HEAD, master) 2a72f99d24714f2a58f400ef63b913d4cf9080b3 from git://git.freedesktop.org/git/vaapi/intel-driver
libva: (HEAD, tag: libva-1.6.1, origin/v1.6-branch) 613eb962b45fbbd1526d751e88e0d8897af6c0e0 from git://git.freedesktop.org/git/vaapi/libva
mesa: (HEAD, tag: mesa-10.6.7) 32efdc87cbf89cfe08ad9571cd756e27c803caa8 from git://git.freedesktop.org/git/mesa/mesa
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master) f0fd4d500de03c30c7ce19915f85acadd1ca4e5d from git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
xserver: (HEAD, tag: xorg-server-1.17.2) 2123f7682d522619f101b05fb75efa75dabbe371 from git://git.freedesktop.org/git/xorg/xserver
intel-gpu-tools: (HEAD, tag: intel-gpu-tools-1.12) 1f9e0550455be4b219954a026407dd23ec21b299 from git://git.freedesktop.org/git/xorg/app/intel-gpu-tools
Version: 11.0https://gitlab.freedesktop.org/mesa/mesa/-/issues/1612Tearing with i965 + modesetting2022-01-12T09:07:00ZBugzilla Migration UserTearing with i965 + modesetting## Submitted by moo..@..il.com
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#101827)](https://bugs.freedesktop.org/show_bug.cgi?id=101827)**
## Description
More details at:
https://lists.freedesktop.org/arc...## Submitted by moo..@..il.com
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#101827)](https://bugs.freedesktop.org/show_bug.cgi?id=101827)**
## Description
More details at:
https://lists.freedesktop.org/archives/intel-gfx/2017-July/133110.html
https://lists.freedesktop.org/archives/intel-gfx/2017-July/133244.html
On top of that I've updated the tearing demonstration code:
https://boblycat.org/~malc/teartest.c
This new version can take a command line argument - number of swaps per frame
and when invoked like: "~/tmp/gl/teartest 2" will tear even without DRI3(i.e.
with DRI2) (though with some override-redirect magic outlined in the first post)
With DRI3 it more or less always tears (fullscreen, nothing on top).
This leads me to suspsect that this is connected to bugs #97957 and #97173
My, perhaps naive, attempts to validate this hunch by compiling and using
Mesa/DRI from git head weren't entirely successful.
Version: 17.1https://gitlab.freedesktop.org/mesa/mesa/-/issues/1235VCE encoding slow when GPU is not stressed (HD 7970M)2021-12-24T23:27:12ZBugzilla Migration UserVCE encoding slow when GPU is not stressed (HD 7970M)## Submitted by Christoph Haag
Assigned to **Default DRI bug account**
**[Link to original bug (#97075)](https://bugs.freedesktop.org/show_bug.cgi?id=97075)**
## Description
This is on an intel + radeon laptop, so I need to run en...## Submitted by Christoph Haag
Assigned to **Default DRI bug account**
**[Link to original bug (#97075)](https://bugs.freedesktop.org/show_bug.cgi?id=97075)**
## Description
This is on an intel + radeon laptop, so I need to run encoding with gstreamer with DRI_PRIME=1.
Here is an example video: http://www.sample-videos.com/video/mp4/720/big_buck_bunny_720p_1mb.mp4
DRI_PRIME is doing a good job of waking up the GPU from runpm when needed for encoding via VAAPI and OMX, but for comparison I'll run glxgears both times.
I'm encoding the mentioned example video with VAAPI with this exact command:
$ time DRI_PRIME=1 LIBVA_DRIVER_NAME=radeonsi gst-launch-1.0 -e filesrc location=big_buck_bunny_720p_1mb.mp4 ! qtdemux ! h264parse ! avdec_h264 ! queue ! videoconvert ! queue ! video/x-raw,format=NV12 ! vaapih264enc ! h264parse ! matroskamux ! filesink location=output.mkv
For low GPU stress I run the gst pipeline while glxgears with vsync is running:
$ DRI_PRIME=1 glxgears
Result: 0.75s user 0.33s system 2% cpu 52.779 total
For higher GPU stress I run the gst pipeline while glxgears without vsync is running:
$ DRI_PRIME=1 vblank_mode=0 glxgears
Result: 0.99s user 0.28s system 43% cpu 2.928 total
I also tried a very similar pipeline with OMX:
$ time DRI_PRIME=1 gst-launch-1.0 -e filesrc location=big_buck_bunny_720p_1mb.mp4 ! qtdemux ! h264parse ! avdec_h264 ! queue ! videoconvert ! queue ! video/x-raw,format=NV12 ! omxh264enc ! h264parse ! matroskamux ! filesink location=output.mkv
Low GPU stress: 0.96s user 0.24s system 19% cpu 6.298 total
High GPU stress: 1.10s user 0.24s system 141% cpu 0.949 total
Overall OMX encoding does a lot better, but it's still a large difference and still below "real time" for the 5 second video.https://gitlab.freedesktop.org/mesa/mesa/-/issues/1817gbm_bo_map fails on i915 when *map_data is not NULL before call2021-12-18T05:16:38ZBugzilla Migration Usergbm_bo_map fails on i915 when *map_data is not NULL before call## Submitted by M Stoeckl
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#110855)](https://bugs.freedesktop.org/show_bug.cgi?id=110855)**
## Description
Created attachment 144477
Test case, compile with gcc -l...## Submitted by M Stoeckl
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#110855)](https://bugs.freedesktop.org/show_bug.cgi?id=110855)**
## Description
Created attachment 144477
Test case, compile with gcc -lgbm
The documentation for the function gbm_bo_map in src/gbm/main/gbm.c states that the argument void** map_data is a "Returned opaque ptr for the mapped region". Contrary to convention for a return value, if *map_data is not NULL, and the DRI i965 driver is used, then gbm_bo_map fails.
The value of *map_data is checked by intel_map_image in src/mesa/drivers/dri/i965/intel_screen.c (line 823 in today's git master).
Debugging this (see attached test program) was made slightly more complicated by the fact that errno was set to ENODEV, after the syscall DRM_IOCTL_I915_GEM_CONTEXT_CREATE failed on the first call to gbm_bo_map .
Reading kernel sources implies that this probably only happens for <gen6 intel GPUs.
**Attachment 144477**, "Test case, compile with gcc -lgbm":
[mesabug.c](/uploads/866f0fbffcfc5a300530c60fa0967f68/mesabug.c)
Version: 19.0https://gitlab.freedesktop.org/mesa/mesa/-/issues/485rv730 agp unstable while uvd video playback with SB2021-11-12T20:03:20ZBugzilla Migration Userrv730 agp unstable while uvd video playback with SB## Submitted by Roman Elshin
Assigned to **Default DRI bug account**
**[Link to original bug (#73625)](https://bugs.freedesktop.org/show_bug.cgi?id=73625)**
## Description
While uvd video playback (no difference with mplayer, mpv ...## Submitted by Roman Elshin
Assigned to **Default DRI bug account**
**[Link to original bug (#73625)](https://bugs.freedesktop.org/show_bug.cgi?id=73625)**
## Description
While uvd video playback (no difference with mplayer, mpv or xbms) video frequently stops at the loop of several frames, while sound move further. It very similar to video from https://bugs.freedesktop.org/show_bug.cgi?id=73191
but loop is endless (if gpu will not hang there). Sometimes there are visible screen corruptions (color squares) before video looping, sometimes gpu hangs up before visible corruptions.
card - rv730 agp,
kernels - 3.12.7, 3.13-rc7 and before.
mesa, drm, video - from oibaf ppa, i suppose it is current git (own compiled give the same).
It looks like disabling ColorTiling2D in xorg.conf.d solve this problem.https://gitlab.freedesktop.org/mesa/mesa/-/issues/606[Turks PRO/Radeon HD 6570/7570/8550] CPU lockup after ring 0 stalled2021-11-10T10:10:09ZBugzilla Migration User[Turks PRO/Radeon HD 6570/7570/8550] CPU lockup after ring 0 stalled## Submitted by gui..@..il.com
Assigned to **Default DRI bug account**
**[Link to original bug (#101712)](https://bugs.freedesktop.org/show_bug.cgi?id=101712)**
## Description
Created attachment 132487
Error log about the crash
W...## Submitted by gui..@..il.com
Assigned to **Default DRI bug account**
**[Link to original bug (#101712)](https://bugs.freedesktop.org/show_bug.cgi?id=101712)**
## Description
Created attachment 132487
Error log about the crash
When trying to render any "heavy" graphics or anything that uses particle animations (as I supose that is causing it), the computer crashes and can only be recovered by a hard reset.
I've already posted at Manjaro (https://forum.manjaro.org/t/xorg-freezes-when-playing-dota/25938/11) more details about this issue, but it's getting worse everyday.
Please, I've already tried everything that was possible. I don't have any alternatives...
Computer specs:
System: Host: Manjaro-AMD Kernel: 4.9.30-1-MANJARO x86_64 (64 bit gcc: 6.3.1)
Desktop: MATE 1.18.0 (Gtk 3.22.15) Distro: Manjaro Linux
Machine: Device: desktop Mobo: ASUSTeK model: M5A97 LE R2.0 v: Rev 1.xx
UEFI: American Megatrends v: 2701 date: 03/24/2016
CPU: Octa core AMD FX-8300 Eight-Core (-MCP-) cache: 16384 KB
flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm) bmips: 52993
clock speeds: max: 3300 MHz 1: 1400 MHz 2: 1400 MHz 3: 1400 MHz
4: 1400 MHz 5: 3300 MHz 6: 3300 MHz 7: 1400 MHz 8: 1400 MHz
Graphics: Card: Advanced Micro Devices [AMD/ATI] Turks PRO [Radeon HD 6570/7570/8550]
bus-ID: 01:00.0
Display Server: X.Org 1.19.3 driver: radeon
Resolution: 1360x768@60.02hz
GLX Renderer: Gallium 0.4 on AMD TURKS (DRM 2.48.0 / 4.9.30-1-MANJARO, LLVM 4.0.0)
GLX Version: 3.0 Mesa 17.1.1 Direct Rendering: Yes
Audio: Card-1 Advanced Micro Devices [AMD/ATI] Turks HDMI Audio [Radeon HD 6500/6600 / 6700M Series]
driver: snd_hda_intel bus-ID: 01:00.1
Card-2 Advanced Micro Devices [AMD/ATI] SBx00 Azalia (Intel HDA)
driver: snd_hda_intel bus-ID: 00:14.2
Card-3 Microsoft driver: USB Audio usb-ID: 004-002
Sound: Advanced Linux Sound Architecture v: k4.9.30-1-MANJARO
Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
driver: r8168 v: 8.044.02-NAPI port: d000 bus-ID: 02:00.0
IF: enp2s0 state: down mac: `<filter>`
Card-2: Microsoft Xbox 360 Wireless Adapter usb-ID: 006-004
IF: null-if-id state: N/A mac: N/A
Drives: HDD Total Size: 1000.2GB (5.0% used)
ID-1: /dev/sda model: SAMSUNG_HD502HI size: 500.1GB
ID-2: /dev/sdb model: ST500LT012 size: 500.1GB
Partition: ID-1: / size: 449G used: 39G (9%) fs: ext4 dev: /dev/sda2
ID-2: swap-1 size: 9.45GB used: 0.00GB (0%) fs: swap dev: /dev/sda3
Sensors: System Temperatures: cpu: 48.2C mobo: N/A gpu: 42.5
Fan Speeds (in rpm): cpu: 0
Info: Processes: 222 Uptime: 1:09 Memory: 2561.3/7730.2MB
Init: systemd Gcc sys: 7.1.1
Client: Shell (bash 4.4.121) inxi: 2.3.9
**Attachment 132487**, "Error log about the crash":
[error_log.txt](/uploads/903773df3027fec3809233174017d11f/error_log.txt)
Version: 17.1
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=102909
* https://bugs.freedesktop.org/show_bug.cgi?id=107545
* https://bugs.freedesktop.org/show_bug.cgi?id=104307https://gitlab.freedesktop.org/mesa/mesa/-/issues/646rv610: corrupt shader output with SB if_conversion optimization pass2021-11-09T09:27:16ZBugzilla Migration Userrv610: corrupt shader output with SB if_conversion optimization pass## Submitted by Nicholas Bishop
Assigned to **Default DRI bug account**
**[Link to original bug (#108321)](https://bugs.freedesktop.org/show_bug.cgi?id=108321)**
## Description
Created attachment 141984
rv610 sbdump
I'm debugging...## Submitted by Nicholas Bishop
Assigned to **Default DRI bug account**
**[Link to original bug (#108321)](https://bugs.freedesktop.org/show_bug.cgi?id=108321)**
## Description
Created attachment 141984
rv610 sbdump
I'm debugging some graphics corruption in Chromium on an iMac7,1 with rv610 graphics. Basically an area of the application has randomish blocks of color, like it's reading from an uninitialized texture.
I've narrowed the problem down to a fragment shader:
varying mediump vec2 _uv_texCoord;
uniform lowp sampler2D _ulut_texture;
uniform mediump float _ulut_size;
mediump vec4 _uLUT(in lowp sampler2D _usampler, in mediump vec3 _upos, in mediump float _usize){
(_upos *= (_usize - 1.0));
mediump float _ulayer = min(floor(_upos.z), (_usize - 2.0));
(_upos.xy = ((_upos.xy + vec2(0.51234001, 0.51234001)) / _usize));
(_upos.y = ((_upos.y + _ulayer) / _usize));
return mix(texture2D(_usampler, _upos.xy), texture2D(_usampler, (_upos.xy + vec2(0, (1.0 / _usize)))), (_upos.z - _ulayer));
}
void main(){
mediump vec2 _utexCoord = _uv_texCoord;
mediump vec4 _utexColor = texture2D(_us_texture, _utexCoord);
if ((_utexColor.w > 0.0))
{
(_utexColor.xyz /= _utexColor.w);
}
(_utexColor.xyz = _uLUT(_ulut_texture, _utexColor.xyz, _ulut_size).xyz);
(_utexColor.xyz *= _utexColor.w);
(gl_FragColor = vec4(_utexColor.xyz, 1.0));
}
(Note that in the original shader "0.51234001" is just "0.5", I just changed it to make grepping easier.) I played around with changes to the _uLUT function, and I found that any mixing of the two samples seems to trigger the bug, e.g. I can mix with a constant 0.5 and the bug still happens. I also tried replacing "mix" with an explicit a*(x-1)+b*x; no change.
I found that disabling SB fixed the issue, and in particular just commenting out the "if_conversion" SB pass fixes the issue.
I've attached the full sbdump output. Please let me know if there are more details I can provide that would help.
**Attachment 141984**, "rv610 sbdump":
[sbdump](/uploads/cb5ce12462b9b903dbede011d44adfac/sbdump)
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1819Buffer corruption with Chromium on gnome-shell (wayland) after taking a scree...2021-11-03T10:37:11ZBugzilla Migration UserBuffer corruption with Chromium on gnome-shell (wayland) after taking a screenshot## Submitted by Lyude Paul `@lyudess`
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#111140)](https://bugs.freedesktop.org/show_bug.cgi?id=111140)**
## Description
So: while viewing a video in Chromium in ful...## Submitted by Lyude Paul `@lyudess`
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#111140)](https://bugs.freedesktop.org/show_bug.cgi?id=111140)**
## Description
So: while viewing a video in Chromium in full screen mode, taking a screenshot of _only_ the window (using Alt+PrintScr) on gnome-shell on Wayland causes some rather hilarious buffer corruption. From the looks of it, only one of the two buffers Xwayland is using get corrupted, causing a rather jarring flickering effect. See the example video here: https://people.freedesktop.org/~lyudess/archive/07-15-2019/VID_20190712_172307.mp4
So far I've managed to confirm this is indeed a hardware acceleration issue, as disabling hardware acceleration seems to fix the issue. Additionally, this issue seems to be specific to intel - I haven't managed to reproduce it with AMD. Note however, the only environment I've managed to reproduce this in is gnome-shell 3.32.2 on Wayland.
The trigger for this seems to be:
- Start playing a video with chromium
- Put the window into full screen mode
- Grab a screenshot of the window using alt + PrintScr (grabbing the whole desktop or a portion of it won't work)
- Shield your eyes as your screen starts flickering
There's also a downstream bug for this on Fedora 30 now opened:
https://bugzilla.redhat.com/show_bug.cgi?id=1729613
Hopefully this doesn't end up being some random gnome-shell or Xwayland issue…
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1157[Wayland+Nouveau] KDE Desktop crashed after login.2021-11-01T07:57:01ZBugzilla Migration User[Wayland+Nouveau] KDE Desktop crashed after login.## Submitted by Tony
Assigned to **Nouveau Project**
**[Link to original bug (#106530)](https://bugs.freedesktop.org/show_bug.cgi?id=106530)**
## Description
Was sent here from KDE bugzilla, crash seems to happen in nouveau.
http...## Submitted by Tony
Assigned to **Nouveau Project**
**[Link to original bug (#106530)](https://bugs.freedesktop.org/show_bug.cgi?id=106530)**
## Description
Was sent here from KDE bugzilla, crash seems to happen in nouveau.
https://bugs.kde.org/show_bug.cgi?id=394100
It happen with a GTX 760 Kepler(NVE0), i did not touched/changed any parameters for the module, all stock as ship by OpenSuse Tumbleweed.
Here is the trace for the crash:
-- Backtrace:
Application: Plasma (plasmashell), signal: Aborted
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fe0cbe4d880 (LWP 9602))]
```
Thread 11 (Thread 0x7fdffa0eb700 (LWP 9699)):
#0 0x00007fe0c49fd56c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fdff00bca00) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7fdff00bc9b0, cond=0x7fdff00bc9d8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x7fdff00bc9d8, mutex=0x7fdff00bc9b0) at pthread_cond_wait.c:655
#3 0x00007fe0c585e86b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5
#4 0x00007fe0c961b558 in QSGRenderThread::processEventsAndWaitForMore() () from /usr/lib64/libQt5Quick.so.5
#5 0x00007fe0c961b93a in QSGRenderThread::run() () from /usr/lib64/libQt5Quick.so.5
#6 0x00007fe0c585daf8 in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5
#7 0x00007fe0c49f759b in start_thread (arg=0x7fdffa0eb700) at pthread_create.c:463
#8 0x00007fe0c5151a1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 10 (Thread 0x7fdffa8ec700 (LWP 9698)):
#0 0x00007fe0c49fd56c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x564e66f04e34) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x564e66f04de0, cond=0x564e66f04e08) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x564e66f04e08, mutex=0x564e66f04de0) at pthread_cond_wait.c:655
#3 0x00007fe0c585e86b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5
#4 0x00007fe0c961b558 in QSGRenderThread::processEventsAndWaitForMore() () from /usr/lib64/libQt5Quick.so.5
#5 0x00007fe0c961b93a in QSGRenderThread::run() () from /usr/lib64/libQt5Quick.so.5
#6 0x00007fe0c585daf8 in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5
#7 0x00007fe0c49f759b in start_thread (arg=0x7fdffa8ec700) at pthread_create.c:463
#8 0x00007fe0c5151a1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 9 (Thread 0x7fdffb114700 (LWP 9695)):
#0 0x00007fe0c49fd56c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x564e66da02a0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x564e66da0250, cond=0x564e66da0278) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x564e66da0278, mutex=0x564e66da0250) at pthread_cond_wait.c:655
#3 0x00007fe0c585e86b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5
#4 0x00007fe0c961b558 in QSGRenderThread::processEventsAndWaitForMore() () from /usr/lib64/libQt5Quick.so.5
#5 0x00007fe0c961b93a in QSGRenderThread::run() () from /usr/lib64/libQt5Quick.so.5
#6 0x00007fe0c585daf8 in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5
#7 0x00007fe0c49f759b in start_thread (arg=0x7fdffb114700) at pthread_create.c:463
#8 0x00007fe0c5151a1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 8 (Thread 0x7fdffbb66700 (LWP 9694)):
[KCrash Handler]
#6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#7 0x00007fe0c508fda1 in __GI_abort () at abort.c:79
#8 0x00007fe0c508710a in __assert_fail_base (fmt=0x7fe0c51dc460 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7fe0a48a5cb5 "kref", file=file@entry=0x7fe0a48a5caa "pushbuf.c", line=line@entry=727, function=function@entry=0x7fe0a48a5ce0 <__PRETTY_FUNCTION__.6480> "nouveau_pushbuf_data") at assert.c:92
#9 0x00007fe0c5087182 in __GI___assert_fail (assertion=assertion@entry=0x7fe0a48a5cb5 "kref", file=file@entry=0x7fe0a48a5caa "pushbuf.c", line=line@entry=727, function=function@entry=0x7fe0a48a5ce0 <__PRETTY_FUNCTION__.6480> "nouveau_pushbuf_data") at assert.c:101
#10 0x00007fe0a48a4128 in nouveau_pushbuf_data (push=push@entry=0x564e651158c0, bo=0x564e65115a80, offset=19700, length=928) at pushbuf.c:727
#11 0x00007fe0a48a40f0 in nouveau_pushbuf_data (push=push@entry=0x564e651158c0, bo=bo@entry=0x0, offset=offset@entry=0, length=length@entry=0) at pushbuf.c:719
#12 0x00007fe0a48a4b4e in nouveau_pushbuf_space (push=push@entry=0x564e651158c0, dwords=dwords@entry=26, relocs=relocs@entry=0, pushes=<optimized out>, pushes@entry=0) at pushbuf.c:689
#13 0x00007fe0a50d05b6 in PUSH_SPACE (size=26, push=0x564e651158c0) at ./nouveau_winsys.h:31
#14 BEGIN_1IC0 (size=17, mthd=9100, subc=0, push=0x564e651158c0) at ./nvc0/nvc0_winsys.h:134
#15 nve4_update_surface_bindings (nvc0=0x564e66cb5750) at nvc0/nvc0_tex.c:1281
#16 nvc0_validate_surfaces (nvc0=0x564e66cb5750) at nvc0/nvc0_tex.c:1309
#17 0x00007fe0a50c78bc in nvc0_state_validate (nvc0=nvc0@entry=0x564e66cb5750, mask=mask@entry=4294967295, validate_list=validate_list@entry=0x7fe0a57897a0 <validate_list_3d>, size=size@entry=33, dirty=dirty@entry=0x564e66cb5bb8, bufctx=0x564e66cb9080) at nvc0/nvc0_state_validate.c:903
#18 0x00007fe0a50c79e7 in nvc0_state_validate_3d (nvc0=nvc0@entry=0x564e66cb5750, mask=mask@entry=4294967295) at nvc0/nvc0_state_validate.c:921
#19 0x00007fe0a50d3bed in nvc0_draw_vbo (pipe=0x564e66cb5750, info=0x7fdffbb65690) at nvc0/nvc0_vbo.c:985
#20 0x00007fe0a4d059bf in st_draw_vbo (ctx=<optimized out>, prims=0x7fdffbb65770, nr_prims=<optimized out>, ib=0x7fdffbb65750, index_bounds_valid=<optimized out>, min_index=<optimized out>, max_index=<optimized out>, tfb_vertcount=0x0, stream=0, indirect=0x0) at state_tracker/st_draw.c:227
#21 0x00007fe0a4cc88f8 in vbo_validated_drawrangeelements (ctx=ctx@entry=0x564e66cf8840, mode=mode@entry=5, index_bounds_valid=index_bounds_valid@entry=0 '\000', start=start@entry=0, end=end@entry=4294967295, count=count@entry=4, type=5123, indices=0x7fdfec1604c2, basevertex=0, numInstances=1, baseInstance=0) at vbo/vbo_exec_array.c:925
#22 0x00007fe0a4cc906f in vbo_exec_DrawElements (mode=5, count=4, type=5123, indices=0x7fdfec1604c2) at vbo/vbo_exec_array.c:1075
#23 0x00007fe0c95e03c7 in QSGBatchRenderer::Renderer::renderMergedBatch(QSGBatchRenderer::Batch const*) () from /usr/lib64/libQt5Quick.so.5
#24 0x00007fe0c95e15c5 in QSGBatchRenderer::Renderer::renderBatches() () from /usr/lib64/libQt5Quick.so.5
#25 0x00007fe0c95e692e in QSGBatchRenderer::Renderer::render() () from /usr/lib64/libQt5Quick.so.5
#26 0x00007fe0c95d78ed in QSGRenderer::renderScene(QSGBindable const&) () from /usr/lib64/libQt5Quick.so.5
#27 0x00007fe0c95d7d6b in QSGRenderer::renderScene(unsigned int) () from /usr/lib64/libQt5Quick.so.5
#28 0x00007fe0c960fc70 in QSGDefaultRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from /usr/lib64/libQt5Quick.so.5
#29 0x00007fe0c966cf88 in QQuickWindowPrivate::renderSceneGraph(QSize const&) () from /usr/lib64/libQt5Quick.so.5
#30 0x00007fe0c9617eaf in QSGRenderThread::syncAndRender() () from /usr/lib64/libQt5Quick.so.5
#31 0x00007fe0c961b8f8 in QSGRenderThread::run() () from /usr/lib64/libQt5Quick.so.5
#32 0x00007fe0c585daf8 in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5
#33 0x00007fe0c49f759b in start_thread (arg=0x7fdffbb66700) at pthread_create.c:463
#34 0x00007fe0c5151a1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 7 (Thread 0x7fe00eee7700 (LWP 9683)):
#0 0x00007fe0c49fd56c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x564e65612b10) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x564e65612ac0, cond=0x564e65612ae8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x564e65612ae8, mutex=0x564e65612ac0) at pthread_cond_wait.c:655
#3 0x00007fe0c585e86b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5
#4 0x00007fe0c961b558 in QSGRenderThread::processEventsAndWaitForMore() () from /usr/lib64/libQt5Quick.so.5
#5 0x00007fe0c961b93a in QSGRenderThread::run() () from /usr/lib64/libQt5Quick.so.5
#6 0x00007fe0c585daf8 in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5
#7 0x00007fe0c49f759b in start_thread (arg=0x7fe00eee7700) at pthread_create.c:463
#8 0x00007fe0c5151a1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 6 (Thread 0x7fe01c407700 (LWP 9640)):
#0 0x00007fe0c49fd56c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x564e64ce21d4) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x564e64ce2180, cond=0x564e64ce21a8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x564e64ce21a8, mutex=0x564e64ce2180) at pthread_cond_wait.c:655
#3 0x00007fe0a4de8d3b in cnd_wait (mtx=0x564e64ce2180, cond=0x564e64ce21a8) at ../../include/c11/threads_posix.h:155
#4 util_queue_thread_func (input=input@entry=0x564e651e7a40) at u_queue.c:255
#5 0x00007fe0a4de8a67 in impl_thrd_routine (p=<optimized out>) at ../../include/c11/threads_posix.h:87
#6 0x00007fe0c49f759b in start_thread (arg=0x7fe01c407700) at pthread_create.c:463
#7 0x00007fe0c5151a1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 5 (Thread 0x7fe0a7fff700 (LWP 9639)):
#0 0x00007fe0c49fd56c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fe0cb800fb8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7fe0cb800f68, cond=0x7fe0cb800f90) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x7fe0cb800f90, mutex=0x7fe0cb800f68) at pthread_cond_wait.c:655
#3 0x00007fe0cb50c674 in ?? () from /usr/lib64/libQt5Script.so.5
#4 0x00007fe0cb50c6b9 in ?? () from /usr/lib64/libQt5Script.so.5
#5 0x00007fe0c49f759b in start_thread (arg=0x7fe0a7fff700) at pthread_create.c:463
#6 0x00007fe0c5151a1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 4 (Thread 0x7fe0ae35f700 (LWP 9637)):
#0 0x00007fe0bf71ce29 in g_mutex_lock () from /usr/lib64/libglib-2.0.so.0
#1 0x00007fe0bf6d6993 in g_main_context_prepare () from /usr/lib64/libglib-2.0.so.0
#2 0x00007fe0bf6d735b in ?? () from /usr/lib64/libglib-2.0.so.0
#3 0x00007fe0bf6d753c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#4 0x00007fe0c5a7082b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5 0x00007fe0c5a180ea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#6 0x00007fe0c585330a in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#7 0x00007fe0c9119f35 in QQmlThreadPrivate::run() () from /usr/lib64/libQt5Qml.so.5
#8 0x00007fe0c585daf8 in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5
#9 0x00007fe0c49f759b in start_thread (arg=0x7fe0ae35f700) at pthread_create.c:463
#10 0x00007fe0c5151a1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 3 (Thread 0x7fe0afbef700 (LWP 9636)):
#0 0x00007fe0bf6d72bc in ?? () from /usr/lib64/libglib-2.0.so.0
#1 0x00007fe0bf6d753c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#2 0x00007fe0c5a7082b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#3 0x00007fe0c5a180ea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4 0x00007fe0c585330a in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#5 0x00007fe0c9119f35 in QQmlThreadPrivate::run() () from /usr/lib64/libQt5Qml.so.5
#6 0x00007fe0c585daf8 in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5
#7 0x00007fe0c49f759b in start_thread (arg=0x7fe0afbef700) at pthread_create.c:463
#8 0x00007fe0c5151a1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 2 (Thread 0x7fe0b57c7700 (LWP 9621)):
#0 0x00007fe0c5147179 in __GI___poll (fds=0x7fe0b0003ce0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007fe0bf6d7429 in ?? () from /usr/lib64/libglib-2.0.so.0
#2 0x00007fe0bf6d753c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3 0x00007fe0c5a7082b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4 0x00007fe0c5a180ea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5 0x00007fe0c585330a in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#6 0x00007fe0c730fb55 in QDBusConnectionManager::run() () from /usr/lib64/libQt5DBus.so.5
#7 0x00007fe0c585daf8 in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5
#8 0x00007fe0c49f759b in start_thread (arg=0x7fe0b57c7700) at pthread_create.c:463
#9 0x00007fe0c5151a1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 1 (Thread 0x7fe0cbe4d880 (LWP 9602)):
#0 0x00007fe0c49fd56c in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x564e664ca550) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x564e664ca500, cond=0x564e664ca528) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x564e664ca528, mutex=0x564e664ca500) at pthread_cond_wait.c:655
#3 0x00007fe0c585e86b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5
#4 0x00007fe0c9618a41 in QSGThreadedRenderLoop::polishAndSync(QSGThreadedRenderLoop::Window*, bool) () from /usr/lib64/libQt5Quick.so.5
#5 0x00007fe0c961954a in QSGThreadedRenderLoop::handleUpdateRequest(QQuickWindow*) () from /usr/lib64/libQt5Quick.so.5
#6 0x00007fe0c967745e in QQuickWindow::event(QEvent*) () from /usr/lib64/libQt5Quick.so.5
#7 0x0000564e638b2a4b in PanelView::event (this=0x564e656e8280, e=0x7fffab1c69e0) at /usr/src/debug/plasma5-workspace-5.12.4-4.1.x86_64/shell/panelview.cpp:925
#8 0x00007fe0c6c207ac in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#9 0x00007fe0c6c27894 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#10 0x00007fe0c5a197f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5
#11 0x00007fe0c5fcdb81 in QWindowPrivate::deliverUpdateRequest() () from /usr/lib64/libQt5Gui.so.5
#12 0x00007fe0c5fce049 in QWindow::event(QEvent*) () from /usr/lib64/libQt5Gui.so.5
#13 0x00007fe0c9677415 in QQuickWindow::event(QEvent*) () from /usr/lib64/libQt5Quick.so.5
#14 0x0000564e638b2a4b in PanelView::event (this=0x564e656e8280, e=0x7fffab1c6da0) at /usr/src/debug/plasma5-workspace-5.12.4-4.1.x86_64/shell/panelview.cpp:925
#15 0x00007fe0c6c207ac in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#16 0x00007fe0c6c27894 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#17 0x00007fe0c5a197f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5
#18 0x00007fe0c5a6fdae in QTimerInfoList::activateTimers() () from /usr/lib64/libQt5Core.so.5
#19 0x00007fe0c5a704f9 in idleTimerSourceDispatch(_GSource*, int (*)(void*), void*) () from /usr/lib64/libQt5Core.so.5
#20 0x00007fe0bf6d7277 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#21 0x00007fe0bf6d74b0 in ?? () from /usr/lib64/libglib-2.0.so.0
#22 0x00007fe0bf6d753c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#23 0x00007fe0c5a7080f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#24 0x00007fe0b7c8cd61 in ?? () from /usr/lib64/libQt5WaylandClient.so.5
#25 0x00007fe0c5a180ea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#26 0x00007fe0c5a20bd0 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5
#27 0x0000564e638a3e23 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/plasma5-workspace-5.12.4-4.1.x86_64/shell/main.cpp:172
```
Version: 18.0https://gitlab.freedesktop.org/mesa/mesa/-/issues/249llvmpipe crashes using kms_swrast_dri.so2021-10-05T03:55:43ZBugzilla Migration Userllvmpipe crashes using kms_swrast_dri.so## Submitted by Stephan Hilb
Assigned to **mes..@..op.org**
**[Link to original bug (#108581)](https://bugs.freedesktop.org/show_bug.cgi?id=108581)**
## Description
Created attachment 142246
backtrace: crashing thread
Running swa...## Submitted by Stephan Hilb
Assigned to **mes..@..op.org**
**[Link to original bug (#108581)](https://bugs.freedesktop.org/show_bug.cgi?id=108581)**
## Description
Created attachment 142246
backtrace: crashing thread
Running sway on GMA500 crashes llvmpipe. See attached backtrace and log for details.
Doesn't crash with `LP_NUM_THREADS=0` or `LP_NUM_THREADS=1`, so maybe a threading issue?
Might be related to #94522
**Attachment 142246**, "backtrace: crashing thread":
[file_108581.txt](/uploads/0da0a15b18838432c4bf66060bcb7179/file_108581.txt)
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/832[BDW] dEQP-VK.synchronization.*read*_image*fence_fd are flaky2021-09-28T14:44:30ZBugzilla Migration User[BDW] dEQP-VK.synchronization.*read*_image*fence_fd are flaky## Submitted by Samuel Iglesias Gonsálvez `@samuelig`
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#103450)](https://bugs.freedesktop.org/show_bug.cgi?id=103450)**
## Description
Device: Mesa DRI Intel(R) HD...## Submitted by Samuel Iglesias Gonsálvez `@samuelig`
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#103450)](https://bugs.freedesktop.org/show_bug.cgi?id=103450)**
## Description
Device: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) (0x1616)
Mesa HEAD: 767ca5bdf1 (master)
VK-GL-CTS HEAD: ab6b0ac1824ce0b091830042110cf3b3ea17e895 (master)
Command:
$ ./deqp-vk -n dEQP-VK.synchronization.*read*_image*fence_fd
How to reproduce it:
I run these in my updated Fedora GNOME 26 installation on my BDW laptop. The easiest way to reproduce it is to run them in a terminal and lock/unlock my GNOME session. Any time I do that, some tests fail. If I don't, they succeed.
Another easy way is to just run one of them in an infinite loop and repeat the aforementioned steps:
$ while(true); do ./deqp-vk -n dEQP-VK.synchronization.*read*_image* | grep "Passed" | grep -v "1/1" ; done
Also it is possible to reproduce it when executing a full cts run with piglit with concurrency mode enabled using dylan's wip/deqp-group-at-a-time branch. In that case, usually one or two tests fail.
Notes:
* There are no GPU hangs or any other kind of error in dmesg.
* These patches from Jason https://patchwork.freedesktop.org/series/31771/ (already landed in mesa master) improved the situation a lot, however it is still possible to reproduce this bug.
* I was not able to reproduce it either on SKL or KBL.
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/1759[kbl] GPU HANG: ecode 9:0:0x84dfbffc, in Xorg2021-08-31T05:03:03ZBugzilla Migration User[kbl] GPU HANG: ecode 9:0:0x84dfbffc, in Xorg## Submitted by Henry
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#108001)](https://bugs.freedesktop.org/show_bug.cgi?id=108001)**
## Description
Created attachment 141658
GPU Crash Dump
I encountered the ...## Submitted by Henry
Assigned to **Intel 3D Bugs Mailing List**
**[Link to original bug (#108001)](https://bugs.freedesktop.org/show_bug.cgi?id=108001)**
## Description
Created attachment 141658
GPU Crash Dump
I encountered the mentioned error message several times now today. It seems to be occurring just now, probably after a system upgrade which is done automatically in my case (Using Fedora Workstation 27).
I attached the output from the latest GPU crash dump (/sys/class/drm/card0/error) as advised in the journalctl entry:
Sep 20 14:09:39 henry-workstation /usr/libexec/gdm-x-session[1923]: i965: Failed to submit batchbuffer: Input/output error
Sep 20 14:09:39 henry-workstation kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Sep 20 14:09:31 henry-workstation kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Sep 20 14:09:23 henry-workstation kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Sep 20 14:09:15 henry-workstation kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Sep 20 14:09:07 henry-workstation kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Sep 20 14:09:07 henry-workstation kernel: [drm] GPU crash dump saved to /sys/class/drm/card0/error
Sep 20 14:09:07 henry-workstation kernel: [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
Sep 20 14:09:07 henry-workstation kernel: [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
Sep 20 14:09:07 henry-workstation kernel: [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
Sep 20 14:09:07 henry-workstation kernel: [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
Sep 20 14:09:07 henry-workstation kernel: [drm] GPU HANG: ecode 9:0:0x84dfbffc, in Xorg [1925], reason: hang on rcs0, action: reset
**Attachment 141658**, "GPU Crash Dump":
[dump_gpu.txt](/uploads/0be4280f073a67984aa0d161f26eb7b8/dump_gpu.txt)https://gitlab.freedesktop.org/mesa/mesa/-/issues/663[i915g+llvm] commit "gallium: Use C11 thread abstractions." breaks memento by...2021-08-14T03:26:58ZBugzilla Migration User[i915g+llvm] commit "gallium: Use C11 thread abstractions." breaks memento by conspiracy## Submitted by Christopher Egert
Assigned to **Default DRI bug account**
**[Link to original bug (#76044)](https://bugs.freedesktop.org/show_bug.cgi?id=76044)**
## Description
This commit breaks the intro memento by conspiracy (h...## Submitted by Christopher Egert
Assigned to **Default DRI bug account**
**[Link to original bug (#76044)](https://bugs.freedesktop.org/show_bug.cgi?id=76044)**
## Description
This commit breaks the intro memento by conspiracy (http://www.pouet.net/prod.php?which=24472).
Backtrace with git-3330dec:
glretrace: i915_prim_vbuf.c:477: draw_arrays_fallback: Assertion `0' failed.
```
Program received signal SIGABRT, Aborted.
0xb7fde424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fde424 in __kernel_vsyscall ()
#1 0xb7b664d6 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2 0xb7b69853 in __GI_abort () at abort.c:89
#3 0xb7b5f857 in __assert_fail_base (fmt=0xb7c9a554 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0xb7693f8a "0", file=file@entry=0xb775f5b3 "i915_prim_vbuf.c", line=line@entry=477,
function=function@entry=0xb775f6ea <__PRETTY_FUNCTION__.9215> "draw_arrays_fallback") at assert.c:92
#4 0xb7b5f907 in __GI___assert_fail (assertion=assertion@entry=0xb7693f8a "0", file=file@entry=0xb775f5b3 "i915_prim_vbuf.c", line=477, function=0xb775f6ea <__PRETTY_FUNCTION__.9215> "draw_arrays_fallback") at assert.c:101
#5 0xb7638d65 in draw_arrays_fallback (nr=<optimized out>, start=<optimized out>, render=<optimized out>) at i915_prim_vbuf.c:477
#6 i915_vbuf_render_draw_arrays (render=0x83a0ff0, start=<optimized out>, nr=4092) at i915_prim_vbuf.c:503
#7 0xb7417cf1 in draw_pt_emit_linear (emit=0x83a1cc0, vert_info=0xbfffeff0, prim_info=0xbffff020) at draw/draw_pt_emit.c:258
#8 0xb75eee7d in emit (prim_info=0xbffff020, vert_info=0xbfffeff0, emit={void (const struct draw_prim_info *, const struct draw_vertex_info *, struct pt_emit *)} 0xb75eedd3 <llvm_middle_end_linear_run+883>) at draw/draw_pt_fetch_shade_pipeline_llvm.c:336
#9 llvm_pipeline_generic (in_prim_info=0xbffff020, fetch_info=0x0, middle=0x83ec5a0) at draw/draw_pt_fetch_shade_pipeline_llvm.c:468
#10 llvm_middle_end_linear_run (middle=0x83ec5a0, start=0, count=4092, prim_flags=0) at draw/draw_pt_fetch_shade_pipeline_llvm.c:532
#11 0xb74207a0 in vsplit_segment_simple_linear (vsplit=0x83d6f90, icount=4092, istart=0, flags=0) at draw/draw_pt_vsplit_tmp.h:240
#12 vsplit_run_linear (frontend=0x83d6f90, start=0, count=4092) at draw/draw_split_tmp.h:60
#13 0xb7416fb7 in draw_pt_arrays (draw=draw@entry=0x840c650, prim=7, start=0, count=count@entry=4092) at draw/draw_pt.c:149
#14 0xb741744a in draw_vbo (draw=0x840c650, info=0xbffff1d0, info@entry=0xbffff2c0) at draw/draw_pt.c:562
#15 0xb762c98e in i915_draw_vbo (pipe=0x83ebc38, info=0xbffff2c0) at i915_context.c:103
#16 0xb73ff258 in cso_draw_vbo (cso=0x8408db0, info=info@entry=0xbffff2c0) at cso_cache/cso_context.c:1400
#17 0xb72d7690 in st_draw_vbo (ctx=0x84b7390, prims=0x84052b4, nr_prims=2, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=4095, tfb_vertcount=0x0, indirect=0x0) at state_tracker/st_draw.c:286
#18 0xb72a238f in vbo_exec_vtx_flush (exec=exec@entry=0x8404f04, keepUnmapped=keepUnmapped@entry=0 '\000') at vbo/vbo_exec_draw.c:409
#19 0xb728d55c in vbo_exec_wrap_buffers (exec=0x8404f04) at vbo/vbo_exec_api.c:89
#20 vbo_exec_vtx_wrap (exec=0x8404f04) at vbo/vbo_exec_api.c:124
#21 0x080b5396 in _glVertex2f(float, float) ()
#22 0x080f9681 in retrace_glVertex2f(trace::Call&) ()
#23 0x0806ce8e in retrace::Retracer::retrace(trace::Call&) ()
#24 0x08063d37 in retrace::retraceCall(trace::Call*) ()
#25 0x08065994 in retrace::RelayRunner::runLeg(trace::Call*) ()
#26 0x0806587c in retrace::RelayRunner::runRace() ()
#27 0x08064053 in retrace::RelayRace::run() ()
#28 0x0806420f in retrace::mainLoop() ()
#29 0x08064985 in main ()
```
$ git bisect bad
fd33a6bcd7f1271e80332379131e82e00fe10586 is the first bad commit
commit fd33a6bcd7f1271e80332379131e82e00fe10586
Author: José Fonseca <jfonseca@vmware.com>
Date: Fri Apr 26 08:03:33 2013 +0100
gallium: Use C11 thread abstractions.
Note that PIPE_ROUTINE now returns an int.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
:040000 040000 dec5215b27af2e3f703e701e323dd5fdeba072eb a8b06eaa9746db86fa603a657a7b6a5dcd9e3633 M src
Reverting this commit on top of master fixes this crash.
Version: git