mesa issueshttps://gitlab.freedesktop.org/mesa/mesa/-/issues2019-09-25T18:02:50Zhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/201swr: segfault when running test case GLES2.functional.vertex_arrays.multiple...2019-09-25T18:02:50ZBugzilla Migration Userswr: segfault when running test case GLES2.functional.vertex_arrays.multiple_attributes.stride.3_float2_17_float2_17_float2_0## Submitted by Gert Wollny `@gerddie`
Assigned to **mes..@..op.org**
**[Link to original bug (#108365)](https://bugs.freedesktop.org/show_bug.cgi?id=108365)**
## Description
Created attachment 142026
glxinfo output
valgrind back...## Submitted by Gert Wollny `@gerddie`
Assigned to **mes..@..op.org**
**[Link to original bug (#108365)](https://bugs.freedesktop.org/show_bug.cgi?id=108365)**
## Description
Created attachment 142026
glxinfo output
valgrind backtrace:
Test case 'dEQP-GLES2.functional.vertex_arrays.multiple_attributes.stride.3_float2_17_float2_17_float2_0'..
==27162== Invalid read of size 4
==27162== at 0x916FD14: swr_update_derived(pipe_context*, pipe_draw_info const*) (swr_state.cpp:1291)
==27162== by 0x916A692: swr_draw_vbo(pipe_context*, pipe_draw_info const*) (swr_draw.cpp:61)
==27162== by 0x90C2BD4: u_vbuf_draw_vbo (u_vbuf.c:1449)
==27162== by 0x941683A: st_draw_vbo (st_draw.c:236)
==27162== by 0x957A9B3: vbo_draw_arrays (vbo_exec_array.c:406)
==27162== by 0x957B699: vbo_exec_DrawArrays (vbo_exec_array.c:565)
==27162== by 0x5E60D5: glu::CallLogWrapper::glDrawArrays(unsigned int, int, int) (gluCallLogWrapper.inl:1222)
==27162== by 0x51A2E0: deqp::gls::ContextArrayPack::render(deqp::gls::Array::Primitive, int, int, bool, float, float) (glsVertexArrayTests.cpp:1189)
==27162== by 0x5172BB: deqp::gls::MultiVertexArrayTest::iterate() (glsVertexArrayTests.cpp:2129)
==27162== by 0x1689C9: deqp::gles2::TestCaseWrapper::iterate(tcu::TestCase*) (tes2TestPackage.cpp:91)
==27162== by 0x7413C2: tcu::TestSessionExecutor::iterateTestCase(tcu::TestCase*) (tcuTestSessionExecutor.cpp:299)
==27162== Address 0x4 is not stack'd, malloc'd or (recently) free'd
Host: Intel Kabylake
OS: Ubuntu 18.04
**Attachment 142026**, "glxinfo output":
[glxinfo.txt](/uploads/fb073bed754e9d42bdcf785f10ae5a88/glxinfo.txt)
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/193[swr] piglit ext_transform_feedback-immediate-reuse-uniform-buffer has a ~5% ...2019-09-25T18:02:44ZBugzilla Migration User[swr] piglit ext_transform_feedback-immediate-reuse-uniform-buffer has a ~5% pass rate## Submitted by Andres Gomez `@tanty`
Assigned to **Bruce Cherniak**
**[Link to original bug (#103762)](https://bugs.freedesktop.org/show_bug.cgi?id=103762)**
## Description
When running the complete "all" profile in piglit agains...## Submitted by Andres Gomez `@tanty`
Assigned to **Bruce Cherniak**
**[Link to original bug (#103762)](https://bugs.freedesktop.org/show_bug.cgi?id=103762)**
## Description
When running the complete "all" profile in piglit against mesa's swr driver, ext_transform_feedback-immediate-reuse-uniform-buffer most of the time fails, but not always.
It seems its pass rate is ~5%.
AFAIK, this is not new for 17.2.x not a recent regression.
A typical piglit report is as follows, although varies from failed run to run:
Detail | Value
------------+---------------
Returncode | 1
------------+---------------
Time | 0:00:00.211612
------------+---------------
Stdout | Probe color at (224,0)
| Expected: 223 31 223
| Observed: 0 0 0
| Probe color at (240,0)
| Expected: 239 15 239
| Observed: 0 0 0
------------+---------------
Stderr | WR detected AVX2
| vert shader 0x7f492c287000
| frag shader 0x7f492c285000
| so shader 0x7f492c283000
| fetch shader 0x7f492c281000
| fetch shader 0x7f492c27f000
| SWR destroy screen!
------------+---------------
Environment | PIGLIT_PLATFORM="mixed_glx_egl" PIGLIT_SOURCE_DIR="/home/local/piglit"
------------+---------------
Command | /home/local/piglit/bin/ext_transform_feedback-immediate-reuse-uniform-buffer -auto -fbo
------------+---------------
dmesg |
----------------------------
Environment is an Ubuntu Xenial with custom LLVM packages installed and locally compiled mesa and mesa dependencies. If needed, I can provide a docker image with which to test.
Version: 17.2
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=90081https://gitlab.freedesktop.org/mesa/mesa/-/issues/191Front buffer drawing mode shows black window with gallium software rasterizers2019-09-25T18:02:44ZBugzilla Migration UserFront buffer drawing mode shows black window with gallium software rasterizers## Submitted by Pradeep Yadav
Assigned to **Bruce Cherniak**
**[Link to original bug (#100151)](https://bugs.freedesktop.org/show_bug.cgi?id=100151)**
## Description
Created attachment 130157
Standalone OpenGL program for reproduc...## Submitted by Pradeep Yadav
Assigned to **Bruce Cherniak**
**[Link to original bug (#100151)](https://bugs.freedesktop.org/show_bug.cgi?id=100151)**
## Description
Created attachment 130157
Standalone OpenGL program for reproducing this issue
When front buffer drawing mode is enabled using glDrawBuffer(GL_FRONT); the window becomes black after glFlush() call.
Attached program OpenGLXORApp.cpp demonstrates it.
Follow these steps to reproduce:
1. Compile the program using: g++ -I/usr/include -lglut -lGLU -lGL OpenGLXORApp.cpp -o OpenGLXORApp
2. Run the program: ./OpenGLXORApp
3. Using mouse start drawing a rectangle, i.e., click left mouse button anywhere inside the window and drag the mouse while the left mouse button is depressed.
Expected Result: A blue triangle on the white background is seen while a green rectangle is being drawn over it.
Actual Result: A black window with green rectangle being drawn over it.
Tried with:
1. GALLIUM_DRIVER=softpipe <-- Black window on Mesa 10.x.x BUT not on Mesa 11+ releases. But in our complex application where rotation is involved, after front buffer drawing, when we switch to double buffer drawing, the background remains static. The attached program cannot be used to reproduce this last issue because it doesn't have rotation functionality.
2. GALLIUM_DRIVER=llvmpipe <-- Black window on Mesa 10.x.x, 11.2.2 and Mesa 13.0.5
3. Mesa classic software rasterizer <-- NO ISSUES!
4. LIBGL_DEBUG=verbose and MESA_DEBUG=1 didn't print out any errors or warnings, except this warning: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable.
Note: Specific Mesa versions were mentioned above because those are the versions I have built and tested against.
**Attachment 130157**, "Standalone OpenGL program for reproducing this issue":
[OpenGLXORApp.cpp](/uploads/5f0466bab3052f3762ba9e14923d5cf6/OpenGLXORApp.cpp)
Version: 17.0https://gitlab.freedesktop.org/mesa/mesa/-/issues/190triangle clipping causes wrong interpolation of non-perspective corrected att...2019-09-25T18:02:43ZBugzilla Migration Usertriangle clipping causes wrong interpolation of non-perspective corrected attributes## Submitted by Ilia Mirkin `@imirkin`
Assigned to **mes..@..op.org**
**[Link to original bug (#98851)](https://bugs.freedesktop.org/show_bug.cgi?id=98851)**
## Description
Sorry for the non-descript subject. I'm just not sure wha...## Submitted by Ilia Mirkin `@imirkin`
Assigned to **mes..@..op.org**
**[Link to original bug (#98851)](https://bugs.freedesktop.org/show_bug.cgi?id=98851)**
## Description
Sorry for the non-descript subject. I'm just not sure what's wrong. The following test fails:
generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-noperspective-gl_FrontColor-flat-fixed.shader_test
as do many of its friends. Note that the color is meant to be non-perspective-interpolated. Also note that the flat-none.shader_test variant of this works as expected. As does the flat-vertex.shader_test variant after my perspective-interpolation for clip distances fix is applied. So it's something wrong with the clipper.
Comparing to generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-smooth-gl_FrontColor-flat-fixed.shader_test, it looks different (which smoothly-interpolates the color). And there's no reason to think that color is being perspective-interpolated, as that is decided in the user frag shader. However I'm not sure what's going on - 1/w is getting messed up perhaps? Not sure.
Furthermore, note that generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-smooth-gl_FrontColor-flat-fixed.shader_test does pass with swr, and the only difference is that the color is perspective-interpolated vs no-perspective-interpolated.
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/188alpha back-and-forth between hot tiles picks up corruption2019-09-25T18:02:42ZBugzilla Migration Useralpha back-and-forth between hot tiles picks up corruption## Submitted by Ilia Mirkin `@imirkin`
Assigned to **mes..@..op.org**
**[Link to original bug (#98791)](https://bugs.freedesktop.org/show_bug.cgi?id=98791)**
## Description
dEQP-GLES2.functional.texture.specification.basic_copytex...## Submitted by Ilia Mirkin `@imirkin`
Assigned to **mes..@..op.org**
**[Link to original bug (#98791)](https://bugs.freedesktop.org/show_bug.cgi?id=98791)**
## Description
dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.2d_alpha
The test sticks some data in via glTexImage2D (into each level), then renders a gradient to a FB, and then runs glCopyTexSubImage to overwrite part of each level's data with the new data. It appears that the first 32 pixels of level0 are good, but the next 32, which have the partial copy over them, were improperly initialized. Like a load was missing?
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/187clipping failures exposed by dEQP2019-09-25T18:02:41ZBugzilla Migration Userclipping failures exposed by dEQP## Submitted by Ilia Mirkin `@imirkin`
Assigned to **mes..@..op.org**
**[Link to original bug (#98790)](https://bugs.freedesktop.org/show_bug.cgi?id=98790)**
## Description
dEQP-GLES2.functional.clipping.polygon_edge.quad_at_origi...## Submitted by Ilia Mirkin `@imirkin`
Assigned to **mes..@..op.org**
**[Link to original bug (#98790)](https://bugs.freedesktop.org/show_bug.cgi?id=98790)**
## Description
dEQP-GLES2.functional.clipping.polygon_edge.quad_at_origin_4,Fail
dEQP-GLES2.functional.clipping.polygon_edge.quad_near_edge_2,Fail
dEQP-GLES2.functional.clipping.triangle_vertex.clip_two.clip_pos_y_pos_z_and_neg_x_neg_y_neg_z,Fail
Feel free to split this bug up into more if it's a bunch of separate issues.
You can run these with
./deqp-gles2 --deqp-visibility=hidden --deqp-case=...
In all cases the results are close, just not 100% right. Usually an edge or part of an edge off.
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/181vkd3d test failures related to ordered/unordered comparisons in test_shader_i...2019-09-25T18:02:38ZBugzilla Migration Uservkd3d test failures related to ordered/unordered comparisons in test_shader_instructions()## Submitted by Józef Kucia
Assigned to **mes..@..op.org**
**[Link to original bug (#109249)](https://bugs.freedesktop.org/show_bug.cgi?id=109249)**
## Description
Radv and Anv are affected. Nir optimizations appear to flip ordere...## Submitted by Józef Kucia
Assigned to **mes..@..op.org**
**[Link to original bug (#109249)](https://bugs.freedesktop.org/show_bug.cgi?id=109249)**
## Description
Radv and Anv are affected. Nir optimizations appear to flip ordered/unordered comparisons. Removing ~inot optimization from https://gitlab.freedesktop.org/mesa/mesa/blob/add5a2ec92f4b3f7ac8353e5986dc04186a7b6da/src/compiler/nir/nir_opt_algebraic.py#L160 fixes the vkd3d test failures.
See https://lists.freedesktop.org/archives/mesa-dev/2018-December/210780.html for a related discussion.
The problem produces the following test failures on Anv:
d3d12:8258:31:if_return: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00} at (0, 0).
d3d12:8258:41:if_return: Test failed: Got {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00} at (0, 0).
d3d12:8258:48:if_return: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00} at (0, 0).
and the following test failures on Radv:
d3d12:8258:31:if_return: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00} at (0, 0).
d3d12:8258:34:if_return: Test failed: Got {1.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00} at (0, 0).
d3d12:8258:37:if_return: Test failed: Got {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00} at (0, 0).
d3d12:8258:41:if_return: Test failed: Got {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00} at (0, 0).
d3d12:8258:48:if_return: Test failed: Got {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 1.00000000e+00} at (0, 0).
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/179Implement tiled copies for AMD -> Intel PRIME2019-09-25T18:02:38ZBugzilla Migration UserImplement tiled copies for AMD -> Intel PRIME## Submitted by Jason Ekstrand `@jekstrand`
Assigned to **mes..@..op.org**
**[Link to original bug (#108277)](https://bugs.freedesktop.org/show_bug.cgi?id=108277)**
## Description
When running the display server (X11 or Wayland) o...## Submitted by Jason Ekstrand `@jekstrand`
Assigned to **mes..@..op.org**
**[Link to original bug (#108277)](https://bugs.freedesktop.org/show_bug.cgi?id=108277)**
## Description
When running the display server (X11 or Wayland) on an Intel GPU and using an AMD GPU as the primary, it wouldn't be terribly difficult to exchange X or Y-tiled images instead of linear ones. This would certainly improve performance on the Intel GPU and probably somewhat on the AMD GPU since anything is better than linear. The idea would be to replace the vkCmdCopyImageToBuffer with a compute pipeline that binds the PRIME image as a buffer and does the swizzling in the shader to get X or Y-tiling.
Version: gitBas NieuwenhuizenBas Nieuwenhuizenhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/171eglGetDisplay() is broken for Wayland2019-09-25T18:02:35ZBugzilla Migration UsereglGetDisplay() is broken for Wayland## Submitted by Michael Olbrich `@mol`
Assigned to **Wayland bug list**
**[Link to original bug (#103757)](https://bugs.freedesktop.org/show_bug.cgi?id=103757)**
## Description
_eglNativePlatformDetectNativeDisplay() (called by eg...## Submitted by Michael Olbrich `@mol`
Assigned to **Wayland bug list**
**[Link to original bug (#103757)](https://bugs.freedesktop.org/show_bug.cgi?id=103757)**
## Description
_eglNativePlatformDetectNativeDisplay() (called by eglGetDisplay()) detects Wayland by checking if the native display object starts with a pointer to wl_display_interface.
Unfortunately wl_display_interface is defined in both libwayland-server.so and libwayland-client.so. libEGL links to both and in all my tests it always picks the one from libwayland-server.so.
The wl_display object passed as native display however contains the version from libwayland-client.so so the check fails.
There is an old thread about this[1] on the wayland-devel list, but it seems nothing happened since then.
[1] https://lists.freedesktop.org/archives/wayland-devel/2014-October/017783.html
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/170Mesa opengles Peppa Pig and openggles2 smurfs on Radeon PowerPC and PPC642019-09-25T18:02:33ZBugzilla Migration UserMesa opengles Peppa Pig and openggles2 smurfs on Radeon PowerPC and PPC64## Submitted by intermediadc@hotmail.com
Assigned to **Wayland bug list**
**[Link to original bug (#99638)](https://bugs.freedesktop.org/show_bug.cgi?id=99638)**
## Description
Created attachment 129286
webgl pink textature colors...## Submitted by intermediadc@hotmail.com
Assigned to **Wayland bug list**
**[Link to original bug (#99638)](https://bugs.freedesktop.org/show_bug.cgi?id=99638)**
## Description
Created attachment 129286
webgl pink textature colors
Hi,
all the applications and desktop who use opengles and opengles2 geve pink or blue color as result.
Wayland is effected too
pls fix it because kde desktop and others now are using some components for display parts of system gui and all become more worst day by day.
See the attachments.
att: webgl pink colors
**Attachment 129286**, "webgl pink textature colors":
![gles](/uploads/399043afc00ba9ad83509172550526da/gles.png)https://gitlab.freedesktop.org/mesa/mesa/-/issues/169dri2_wl_swrast crashes on 64 bit, but not on 32 bit2019-09-25T18:02:32ZBugzilla Migration Userdri2_wl_swrast crashes on 64 bit, but not on 32 bit## Submitted by n3rdopolis
Assigned to **Wayland bug list**
**[Link to original bug (#96953)](https://bugs.freedesktop.org/show_bug.cgi?id=96953)**
## Description
I am not sure if this is because of qtwayland or because of mesa, b...## Submitted by n3rdopolis
Assigned to **Wayland bug list**
**[Link to original bug (#96953)](https://bugs.freedesktop.org/show_bug.cgi?id=96953)**
## Description
I am not sure if this is because of qtwayland or because of mesa, but it seems I am getting a crash with git master
I have a stack trace, let me know if running it with any variables exported
I am building mesa with
./autogen.sh --prefix=$INSTALLDIR --enable-driglx-direct --enable-dri --with-dri-drivers=r200,radeon,nouveau,i915,i965,swrast --enable-osmesa --enable-xa --enable-glx-tls --enable-shared-dricore --enable-gles1 --enable-gles2 --with-gallium-drivers=nouveau,svga,r300,r600,swrast,radeonsi,virgl --with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi --enable-gallium-egl --with-llvm-prefix=/usr/lib/llvm-3.6/ --with-llvm-shared-libs --libdir=$INSTALLDIR/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)
0 dri2_wl_swrast_put_image2 (draw=0x300c240, op=`<optimized out>`,
x=`<optimized out>`, y=0, w=`<optimized out>`, h=0, stride=64,
data=0x3012b40 "", loaderPrivate=0x3012240)
at drivers/dri2/platform_wayland.c:1642
dri2_surf = 0x3012240
copy_width = -4
src = 0x36d4000 <error: Cannot access memory at address 0x36d4000>
dst = 0x7fffcd4f4ffc <error: Cannot access memory at address 0x7fffcd4f4ffc>
__PRETTY_FUNCTION__ = "dri2_wl_swrast_put_image2"
```
#1 0x00007fffed28ed26 in dri2_wl_swrast_put_image (
draw=<optimized out>, op=<optimized out>, x=<optimized out>,
y=<optimized out>, w=<optimized out>, h=<optimized out>,
data=0x3012b40 "", loaderPrivate=0x3012240)
at drivers/dri2/platform_wayland.c:1658
dri2_surf = 0x3012240
#2 0x00007fffea1bbd38 in put_image (height=<optimized out>,
width=<optimized out>, data=<optimized out>,
dPriv=<optimized out>) at drisw.c:71
sPriv = <optimized out>
loader = <optimized out>
#3 drisw_put_image (drawable=<optimized out>, data=<optimized out>,
width=<optimized out>, height=<optimized out>) at drisw.c:141
dPriv = <optimized out>
#4 0x00007fffea1bc1dd in drisw_copy_to_front (ptex=0x300c0d0,
dPriv=0x300c240) at drisw.c:181
No locals.
#5 drisw_swap_buffers (dPriv=0x300c240) at drisw.c:208
ctx = 0x2e2ac20
ptex = 0x300c0d0
#6 0x00007fffed28d0b9 in dri2_wl_swrast_swap_buffers (
drv=<optimized out>, disp=<optimized out>, draw=<optimized out>)
at drivers/dri2/platform_wayland.c:1729
No locals.
#7 0x00007fffed2839e2 in eglSwapBuffers (dpy=0x710400,
surface=surface@entry=0x3012240) at main/eglapi.c:1008
ctx = 0x2e7ef00
disp = 0x710400
surf = 0x3012240
drv = <optimized out>
ret = <optimized out>
__func__ = "eglSwapBuffers"
#8 0x00007ffff7e57b7a in QtWaylandClient::QWaylandGLContext::swapBuffers (this=0x2e7eb90, surface=0x2dd1a00)
at ../../../hardwareintegration/client/wayland-egl/qwaylandglcontext.cpp:553
window = 0x2dd19f0
eglSurface = 0x3012240
sub = 0x0
#9 0x00007ffff6854238 in QOpenGLContext::swapBuffers (
this=this@entry=0x2d91790, surface=surface@entry=0x2dd0650)
at /srcbuild/qtbase/src/gui/kernel/qopenglcontext.cpp:1063
__PRETTY_FUNCTION__ = "void QOpenGLContext::swapBuffers(QSurface*)"
surfaceHandle = 0x2dd1a00
#10 0x00007ffff69a4c8a in QPlatformBackingStore::composeAndFlush (
this=this@entry=0x2dd1550, window=window@entry=0x2dd0640,
region=..., offset=..., textures=<optimized out>,
context=<optimized out>, translucentBackground=false)
at /srcbuild/qtbase/src/gui/painting/qplatformbackingstore.cpp:414
funcs = 0x3012080
deviceWindowRect = {x1 = 0, y1 = 0, x2 = 1009, y2 = 575}
textureId = <optimized out>
origin = <optimized out>
#11 0x00007ffff69a4d8b in QPlatformBackingStore::composeAndFlush (
this=this@entry=0x2dd1550, window=0x2dd0640, region=...,
offset=...,
textures=textures@entry=0x7ffff745cf40 <(anonymous namespace)::Q_QGS_qt_dummy_platformTextureList::innerFunction()::holder>,
context=context@entry=0x2d91790, translucentBackground=false)
at /srcbuild/qtbase/src/gui/painting/qplatformbackingstore.cpp:317
No locals.
#12 0x00007ffff7049590 in QWidgetBackingStore::qt_flush (
widget=widget@entry=0x83d880, region=...,
backingStore=<optimized out>, tlw=0x83d880, tlwOffset=...,
widgetTextures=0x7ffff745cf40 <(anonymous namespace)::Q_QGS_qt_dummy_platformTextureList::innerFunction()::holder>,
widgetBackingStore=0x2dd1b30)
at /srcbuild/qtbase/src/widgets/kernel/qwidgetbackingstore.cpp:138
translucentBackground = false
flushUpdate = 0
fpsDebug = false
__PRETTY_FUNCTION__ = "static void QWidgetBackingStore::qt_flush(QWidget*, const QRegion&, QBackingStore*, QWidget*, const QPoint&, QPlatformTextureList*, QWidgetBackingStore*)"
offset = {xp = 0, yp = 0}
compositionWasActive = <optimized out>
#13 0x00007ffff7049ed3 in QWidgetBackingStore::flush (
this=this@entry=0x2dd1b30, widget=widget@entry=0x0)
at /srcbuild/qtbase/src/widgets/kernel/qwidgetbackingstore.cpp:1415
target = 0x83d880
hasDirtyOnScreenWidgets = false
flushed = false
#14 0x00007ffff704a076 in QWidgetBackingStore::endPaint (
this=this@entry=0x2dd1b30, cleaned=...,
backingStore=<optimized out>,
beginPaintInfo=beginPaintInfo@entry=0x7fffffffd514)
at /srcbuild/qtbase/src/widgets/kernel/qwidgetbackingstore.cpp:359
No locals.
#15 0x00007ffff704b329 in QWidgetBackingStore::doSync (
this=this@entry=0x2dd1b30)
at /srcbuild/qtbase/src/widgets/kernel/qwidgetbackingstore.cpp:1399
updatesDisabled = <optimized out>
repaintAllWidgets = <optimized out>
inTopLevelResize = <optimized out>
tlwRect = {x1 = 7, y1 = 96, x2 = 1016, y2 = 671}
surfaceGeometry = {x1 = 7, y1 = 96, x2 = 5, y2 = 94}
toClean = {d = 0x989580, static shared_empty = {ref = {
atomic = {_q_value = {<std::__atomic_base<int>> = {
static _S_alignment = 4,
_M_i = -1}, <No data fields>}}},
qt_rgn = 0x7ffff6b0d0c0 <qrp>}}
opaqueNonOverlappedWidgets = {a = 32, s = 0,
ptr = 0x7fffffffd600, {
array = "\000\000\000\000\000\000\000\000@\206\344\002\000\000\000\000\220\210\344\002", '\000' <repeats 12 times>, "\240\247\344\002\000\000\000\000P\246\344\002", '\000' <repeats 12 times>, "\200\000\000\000\000\000P\225\342\002", '\000' <repeats 12 times>, "`\327\377\377\377\177\000\000_\356\336\367\377\177\000\000\000\000\000\000\000\000\360?", '\000' <repeats 24 times>, "\021\352-\201\231\227q=", '\000' <repeats 16 times>, "@0\222\000\000\000\000\000\000\000\000@\000\000\000\000 \332\377\377\377\177\000\000\070\033\335\002\000\000\000\000q\344\201\366\377\177\000\000\070\033\335\002\000\000\000\000\035"..., q_for_alignment_1 = 0, q_for_alignment_2 = 0}}
beginPaintInfo = {wasFlushed = 0, nothingToPaint = 0,
backingStoreRecreated = 0}
dirtyCopy = {d = 0x989580, static shared_empty = {ref = {
atomic = {_q_value = {<std::__atomic_base<int>> = {
static _S_alignment = 4,
_M_i = -1}, <No data fields>}}},
qt_rgn = 0x7ffff6b0d0c0 <qrp>}}
#16 0x00007ffff704b509 in QWidgetBackingStore::sync (this=0x2dd1b30,
exposedWidget=0x83d880, exposedRegion=...)
at /srcbuild/qtbase/src/widgets/kernel/qwidgetbackingstore.cpp:1148
No locals.
#17 0x00007ffff70846c4 in QWidgetWindow::event (this=0x2dd0640,
event=0x7fffffffda08)
at /srcbuild/qtbase/src/widgets/kernel/qwidgetwindow.cpp:284
No locals.
#18 0x00007ffff703fa4e in QApplicationPrivate::notify_helper (
this=<optimized out>, receiver=0x2dd0640, e=0x7fffffffda08)
at /srcbuild/qtbase/src/widgets/kernel/qapplication.cpp:3799
consumed = <optimized out>
this = <optimized out>
e = 0x7fffffffda08
receiver = 0x2dd0640
#19 0x00007ffff7045c65 in QApplication::notify (this=0x7fffffffdea0,
receiver=0x2dd0640, e=0x7fffffffda08)
at /srcbuild/qtbase/src/widgets/kernel/qapplication.cpp:3641
widget = <optimized out>
__PRETTY_FUNCTION__ = "virtual bool QApplication::notify(QObject*, QEvent*)"
res = false
#20 0x00007ffff6141299 in QCoreApplication::notifyInternal2 (
receiver=0x2dd0640, event=0x7fffffffda08)
at /srcbuild/qtbase/src/corelib/kernel/qcoreapplication.cpp:988
selfRequired = true
result = false
cbdata = {0x2dd0640, 0x7fffffffda08, 0x7fffffffd997}
d = <optimized out>
threadData = 0x6ee5c0
#21 0x00007ffff6834862 in QCoreApplication::sendSpontaneousEvent (
receiver=receiver@entry=0x2dd0640,
event=event@entry=0x7fffffffda08)
at ../../include/QtCore/../../../src/corelib/kernel/qcoreapplication.h:234
No locals.
#22 0x00007ffff6833806 in QGuiApplicationPrivate::processExposeEvent
(e=0x2e2bd30)
at /srcbuild/qtbase/src/gui/kernel/qguiapplication.cpp:2797
p = 0x2dd16e0
exposeEvent = {<QEvent> = {
_vptr.QEvent = 0x7ffff6af6558 <vtable for QExposeEvent+16>, static staticMetaObject = {d = {superdata = 0x0,
stringdata = 0x7ffff62c9320 <qt_meta_stringdata_QEvent>, data = 0x7ffff62c8d60 <qt_meta_data_QEvent>,
static_metacall = 0x0, relatedMetaObjects = 0x0,
extradata = 0x0}}, d = 0x0, t = 206, posted = 0,
spont = 1, m_accept = 1, reserved = 7888}, rgn = {
d = 0x2e2bcd0, static shared_empty = {ref = {atomic = {
_q_value = {<std::__atomic_base<int>> = {
static _S_alignment = 4,
_M_i = -1}, <No data fields>}}},
qt_rgn = 0x7ffff6b0d0c0 <qrp>}}}
#23 0x00007ffff6833fe4 in QGuiApplicationPrivate::processWindowSystemEvent (e=e@entry=0x2e2bd30)
at /srcbuild/qtbase/src/gui/kernel/qguiapplication.cpp:1755
__PRETTY_FUNCTION__ = "static void QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)"
#24 0x00007ffff68210f3 in QWindowSystemInterface::sendWindowSystemEvents (flags=...)
at /srcbuild/qtbase/src/gui/kernel/qwindowsysteminterface.cpp:654
event = 0x2e2bd30
nevents = 2
#25 0x00007fffee01cf91 in userEventSourceDispatch (
source=<optimized out>)
at /srcbuild/qtbase/src/platformsupport/eventdispatchers/qeventdispatcher_glib.cpp:76
userEventSource = <optimized out>
dispatcher = <optimized out>
#26 0x00007ffff13a130e in g_main_dispatch (context=0x7bd9e0)
at gmain.c:3165
dispatch = 0x7fffee01cf84 <userEventSourceDispatch(GSource*, GSourceFunc, gpointer)>
prev_source = 0x0
was_in_call = 0
user_data = 0x0
callback = 0x0
cb_funcs = 0x0
cb_data = 0x0
need_destroy = <optimized out>
source = 0x7a8690
current = 0x705060
i = 1
#27 g_main_context_dispatch (context=context@entry=0x7bd9e0)
at gmain.c:3780
No locals.
#28 0x00007ffff13a1543 in g_main_context_iterate (
context=context@entry=0x7bd9e0, block=block@entry=1,
dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3851
max_priority = 0
timeout = 0
some_ready = 1
nfds = <optimized out>
allocated_nfds = <optimized out>
fds = 0x7f93a0
#29 0x00007ffff13a15dc in g_main_context_iteration (
context=0x7bd9e0, may_block=may_block@entry=1) at gmain.c:3912
retval = <optimized out>
#30 0x00007ffff617208c in QEventDispatcherGlib::processEvents (
this=0x7a3800, flags=...)
at /srcbuild/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:423
d = 0x711000
canWait = true
savedFlags = {i = 0}
result = <optimized out>
#31 0x00007ffff613da04 in QEventLoop::exec (
this=this@entry=0x7fffffffdcc0, flags=..., flags@entry=...)
at /srcbuild/qtbase/src/corelib/kernel/qeventloop.cpp:212
d = 0x7fa860
locker = {val = 7275968}
__PRETTY_FUNCTION__ = "int QEventLoop::exec(QEventLoop::ProcessEventsFlags)"
ref = {d = 0x7fa860, locker = @0x7fffffffdc58,
exceptionCaught = true}
#32 0x00007ffff6141abf in QCoreApplication::exec ()
at /srcbuild/qtbase/src/corelib/kernel/qcoreapplication.cpp:1261
threadData = 0x6ee5c0
__PRETTY_FUNCTION__ = "static int QCoreApplication::exec()"
eventLoop = {<QObject> = {
_vptr.QObject = 0x7ffff6360958 <vtable for QEventLoop+16>, static staticMetaObject = {d = {superdata = 0x0,
stringdata = 0x7ffff62690e0 <qt_meta_stringdata_QObject>, data = 0x7ffff6268fc0 <qt_meta_data_QObject>,
static_metacall = 0x7ffff615cf9e <QObject::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>,
relatedMetaObjects = 0x0, extradata = 0x0}},
d_ptr = {d = 0x7fa860}, static staticQtMetaObject = {
d = {superdata = 0x0,
stringdata = 0x7ffff62b15c0 <qt_meta_stringdata_Qt>,
data = 0x7ffff62aeb00 <qt_meta_data_Qt>,
static_metacall = 0x0, relatedMetaObjects = 0x0,
extradata = 0x0}}}, static staticMetaObject = {d = {
superdata = 0x7ffff6362840 <QObject::staticMetaObject>, stringdata = 0x7ffff62c8960 <qt_meta_stringdata_QEventLoop>,
data = 0x7ffff62c8900 <qt_meta_data_QEventLoop>,
static_metacall = 0x7ffff61a49f6 <QEventLoop::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)>,
relatedMetaObjects = 0x0, extradata = 0x0}}}
returnCode = <optimized out>
#33 0x0000000000412d0e in main ()
No symbol table info available.
```
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/167[BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" co...2019-09-25T18:02:31ZBugzilla Migration User[BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration## Submitted by Andres Gomez `@tanty`
Assigned to **mes..@..op.org**
**[Link to original bug (#110357)](https://bugs.freedesktop.org/show_bug.cgi?id=110357)**
## Description
After:
--
commit dacb11a585face5ca179c34cfc588a71a425c...## Submitted by Andres Gomez `@tanty`
Assigned to **mes..@..op.org**
**[Link to original bug (#110357)](https://bugs.freedesktop.org/show_bug.cgi?id=110357)**
## Description
After:
--
commit dacb11a585face5ca179c34cfc588a71a425c1e0
Author: Eric Anholt <eric@anholt.net>
Date: Sat Aug 25 14:16:59 2018 -0700
egl: Add a 565 pbuffer-only EGL config under X11.
The CTS requires a 565-no-depth-no-stencil (meaning d/s not-required, not
not-present) config for ES 3.0, but at depth 24 of X11 we wouldn't do so.
We can satisfy that bad requirement using a pbuffer-only visual with
whatever other buffers the driver happens to have given us.
I've tried to raise this as an absurd requirement with Khronos and made no
progress.
v2: Make sure it's single sample, no depth, no stencil. Comment typo fix
Reviewed-by: Adam Jackson <ajax@redhat.com>
--
VK-GL-CTS's cts-runner adds a new configuration to the suite (41):
config-gl46-gtf-master-cfg-41-run-22-width-64-height-64-seed-1.qpa
config-gl46-gtf-master-cfg-41-run-23-width-113-height-47-seed-2.qpa
config-gl46-master-cfg-41-run-0-width-64-height-64-seed-1.qpa
config-gl46-master-cfg-41-run-1-width-113-height-47-seed-2.qpa
The cts-runner aborts when attempting to run those and, hence, doesn't complete the conformance run.
For example:
local@37d47ab783e6:~/vk-gl-cts/build/external/openglcts/modules$ MESA_GLSL_VERSION_OVERRIDE=460 MESA_GL_VERSION_OVERRIDE=4.6 ./glcts --deqp-caselist-file=gl_cts/data/mustpass/gl/khronos_mustpass/4.6.0.x/gl46-master.txt --deqp-screen-rotation=unspecified --deqp-surface-width=64 --deqp-surface-height=64 --deqp-watchdog=disable --deqp-base-seed=1 --deqp-surface-type=pbuffer --deqp-gl-config-id=41 --deqp-gl-context-type=egl --deqp-log-filename=config-gl46-master-cfg-41-run-0-width-64-height-64-seed-1.qpa --deqp-log-images=disable --deqp-log-shader-sources=disable
Writing test log into config-gl46-master-cfg-41-run-0-width-64-height-64-seed-1.qpa
dEQP Core git-ed324ca63d3a40e0b82abe4a3d155afa28fefce1 (0xed324ca6) starting..
target implementation = 'X11 EGL'
FATAL ERROR: Got EGL_BAD_MATCH: eglCreatePbufferSurface() at egluGLContextFactory.cpp:293
Killed
Version: git
### Blocking
* [Bug 102590](https://bugs.freedesktop.org/show_bug.cgi?id=102590)https://gitlab.freedesktop.org/mesa/mesa/-/issues/1253d image broken in Dragon age: origins2019-09-25T18:02:10ZBugzilla Migration User3d image broken in Dragon age: origins## Submitted by ilia
Assigned to **mes..@..op.org**
**[Link to original bug (#108848)](https://bugs.freedesktop.org/show_bug.cgi?id=108848)**
## Description
Created attachment 142586
Game main menu
Picture is bad with nine enable...## Submitted by ilia
Assigned to **mes..@..op.org**
**[Link to original bug (#108848)](https://bugs.freedesktop.org/show_bug.cgi?id=108848)**
## Description
Created attachment 142586
Game main menu
Picture is bad with nine enabled and good when nine disabled.
Intro video displays correct, also gallium HUD displays correct to.
**Attachment 142586**, "Game main menu":
![dao](/uploads/6e3a14c2a93d7dca7c32bd94df4c05c9/dao.jpg)
Version: 18.2https://gitlab.freedesktop.org/mesa/mesa/-/issues/123[d3dadapter+radeonsi] Dragon's Dogma: video memory leak with precompiled shaders2019-09-25T18:02:09ZBugzilla Migration User[d3dadapter+radeonsi] Dragon's Dogma: video memory leak with precompiled shaders## Submitted by kud..@..il.com
Assigned to **mes..@..op.org**
**[Link to original bug (#97003)](https://bugs.freedesktop.org/show_bug.cgi?id=97003)**
## Description
Steps to reproduce:
1. Launch the game
2. Find a new location ent...## Submitted by kud..@..il.com
Assigned to **mes..@..op.org**
**[Link to original bug (#97003)](https://bugs.freedesktop.org/show_bug.cgi?id=97003)**
## Description
Steps to reproduce:
1. Launch the game
2. Find a new location entrance (e.g. Cassardis gate)
3. Go back and forth between locations a few times, the game will eventually crash with "ERR08 : Memory overrun." (http://i.imgur.com/oPfFvq9.png)
Workaround: R600_DEBUG=mono fixes this
glxinfo:
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD PITCAIRN (DRM 2.43.0 / 4.4.0-28-lowlatency, LLVM 3.9.0) (0x6818)
Version: 12.1.0
Accelerated: yes
Video memory: 2048MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.2
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/118glXWaitForMscOML and glXWaitVideoSyncSGI may block indefinitely2019-09-25T18:02:05ZBugzilla Migration UserglXWaitForMscOML and glXWaitVideoSyncSGI may block indefinitely## Submitted by acc..@..il.com
Assigned to **mes..@..op.org**
**[Link to original bug (#110697)](https://bugs.freedesktop.org/show_bug.cgi?id=110697)**
## Description
Under certain circumstances, using any of the aforementioned fu...## Submitted by acc..@..il.com
Assigned to **mes..@..op.org**
**[Link to original bug (#110697)](https://bugs.freedesktop.org/show_bug.cgi?id=110697)**
## Description
Under certain circumstances, using any of the aforementioned functions under an Intel card may result in the application being blocked until killed.
The application in question is kwin-lowlatency (https://github.com/tildearrow/kwin-lowlatency) which relies upon either function for achieving its goal.
Related issue: https://github.com/tildearrow/kwin-lowlatency/issues/10
Version: 19.0https://gitlab.freedesktop.org/mesa/mesa/-/issues/112Segmentation Fault when calling glXSetupForCommand2019-09-25T18:02:02ZBugzilla Migration UserSegmentation Fault when calling glXSetupForCommand## Submitted by Danilo Spinella
Assigned to **mes..@..op.org**
**[Link to original bug (#107315)](https://bugs.freedesktop.org/show_bug.cgi?id=107315)**
## Description
Created attachment 140743
glxinfo output
**Attachment 14074...## Submitted by Danilo Spinella
Assigned to **mes..@..op.org**
**[Link to original bug (#107315)](https://bugs.freedesktop.org/show_bug.cgi?id=107315)**
## Description
Created attachment 140743
glxinfo output
**Attachment 140743**, "glxinfo output":
[glxinfo](/uploads/8198542537c977d6a2a43790a381c993/glxinfo)
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/111glXWaitVideoSyncSGI blocks forever2019-09-25T18:02:01ZBugzilla Migration UserglXWaitVideoSyncSGI blocks forever## Submitted by Geoffrey McRae
Assigned to **mes..@..op.org**
**[Link to original bug (#106536)](https://bugs.freedesktop.org/show_bug.cgi?id=106536)**
## Description
Before mesa 18.0 glXWaitVideoSyncSGI worked perfectly, but afte...## Submitted by Geoffrey McRae
Assigned to **mes..@..op.org**
**[Link to original bug (#106536)](https://bugs.freedesktop.org/show_bug.cgi?id=106536)**
## Description
Before mesa 18.0 glXWaitVideoSyncSGI worked perfectly, but after updating to mesa 18 it blocks forever, see the following for the code exhibiting this behavior.
https://github.com/gnif/LookingGlass/blob/da2bcfdf9a3d559928a450cfc4642e8635c8f71f/client/renderers/opengl.c#L433
We have seen this occur on AMD hardware, I personally can reproduce it on a Vega 56. It may affect other platforms but I can not confirm.
Version: 18.0https://gitlab.freedesktop.org/mesa/mesa/-/issues/109Indirect GLX broken with some (older) X servers2019-09-25T18:02:00ZBugzilla Migration UserIndirect GLX broken with some (older) X servers## Submitted by Glynn Clements
Assigned to **mes..@..op.org**
**[Link to original bug (#101626)](https://bugs.freedesktop.org/show_bug.cgi?id=101626)**
## Description
I recently updated Mesa from 12.0.1 to 17.0.6. Now, when connec...## Submitted by Glynn Clements
Assigned to **mes..@..op.org**
**[Link to original bug (#101626)](https://bugs.freedesktop.org/show_bug.cgi?id=101626)**
## Description
I recently updated Mesa from 12.0.1 to 17.0.6. Now, when connecting to a remote X server (specifically, Cygwin's XWin.exe, 1.16.2), clients (e.g. glxinfo from mesa-demos 8.3.0) fail with GLXBadContext for X_GLXMakeCurrent.
This doesn't occur when connecting to a local Xvnc with LIBGL_ALWAYS_INDIRECT=1.
Version: 17.0https://gitlab.freedesktop.org/mesa/mesa/-/issues/104Using glXBindTexImageEXT with a GLXPixmap created out-of-process fails2019-09-25T18:01:57ZBugzilla Migration UserUsing glXBindTexImageEXT with a GLXPixmap created out-of-process fails## Submitted by Andrew Comminos
Assigned to **mes..@..op.org**
**[Link to original bug (#96219)](https://bugs.freedesktop.org/show_bug.cgi?id=96219)**
## Description
When binding a GLXPixmap created in a different process using gl...## Submitted by Andrew Comminos
Assigned to **mes..@..op.org**
**[Link to original bug (#96219)](https://bugs.freedesktop.org/show_bug.cgi?id=96219)**
## Description
When binding a GLXPixmap created in a different process using glXBindTexImageEXT, we only bind a black texture. I believe this occurs because the associated DRI drawable is stored in the underlying display- when dri{2,3}_bind_tex_image is called with a different glx_display than the one that created (or bound) the GLXPixmap, we find that its drawable table does not contain the associated DRI drawable, and we return.
I suggest that driFetchDrawable is used in dri{2,3}_bind_tex_image, as it is in dri{2,3}_bind_context.
Version: githttps://gitlab.freedesktop.org/mesa/mesa/-/issues/98glXSwapIntervalMESA crashes when making use of GLX_MESA_multithread_makecurrent2019-09-25T18:01:54ZBugzilla Migration UserglXSwapIntervalMESA crashes when making use of GLX_MESA_multithread_makecurrent## Submitted by James Legg
Assigned to **mes..@..op.org**
**[Link to original bug (#89562)](https://bugs.freedesktop.org/show_bug.cgi?id=89562)**
## Description
Created attachment 114264
test case
If two threads have the same cur...## Submitted by James Legg
Assigned to **mes..@..op.org**
**[Link to original bug (#89562)](https://bugs.freedesktop.org/show_bug.cgi?id=89562)**
## Description
Created attachment 114264
test case
If two threads have the same current glX context, as permitted by GLX_MESA_multithread_makecurrent, then calling glXSwapIntervalMESA results in invoking dri2SetSwapInterval with the pdraw argument set to NULL. dri2SetSwapInterval then dereferences pdraw, causing a segmentation fault. The attached program reproduces this.
You can also reproduce the same crash by letting a thread exit with a context bound and then making the context current on another thread and calling glXSwapIntervalMESA there (this seems a bit dirty, but if there is no requirement to unbind GL contexts before exiting threads, then this method doesn't require GLX_MESA_multithread_makecurrent). If you add -DTEST2 to the compiler flags when compiling the attached file, this crash will be reproduced instead.
This affects at least Mesa 10.4.3, 10.5, and git master at revision 48b0a3c1c9d829a9b1d401afb2796b35df94a5d7.
**Attachment 114264**, "test case":
[multithreaded_make_current_and_glXSwapIntervalMesa.cc](/uploads/80fddcaedc9e19dcf9d4716471699087/multithreaded_make_current_and_glXSwapIntervalMesa.cc)
Version: git