mesa issueshttps://gitlab.freedesktop.org/mesa/mesa/-/issues2024-03-27T16:04:46Zhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/10905r300: crash when compiling some GSK shaders2024-03-27T16:04:46ZPavel Ondračkapavel.ondracka@gmail.comr300: crash when compiling some GSK shadersExample affected shader:[138.shader_test](/uploads/dc9456d55ace61584521cbf621c44d84/138.shader_test), crash can be reproduced with radeon drm-shim.
Regression from a782809f81dc32079691b3a280580dbf7b800dba
```
a782809f81dc32079691b3a2805...Example affected shader:[138.shader_test](/uploads/dc9456d55ace61584521cbf621c44d84/138.shader_test), crash can be reproduced with radeon drm-shim.
Regression from a782809f81dc32079691b3a280580dbf7b800dba
```
a782809f81dc32079691b3a280580dbf7b800dba is the first bad commit
commit a782809f81dc32079691b3a280580dbf7b800dba
Author: Faith Ekstrand <faith.ekstrand@collabora.com>
Date: Mon Mar 18 18:12:41 2024 -0500
nir/builder: Correctly handle decl_reg or undef as the first instruction
These are both handled by inserting them directly at the top of the
nir_function_impl. However, if the cursor is already at the top, it
never gets updated so we end up inserting other stuff after the newly
inserted undef or decl_reg. It's an odd edge case to be sure but I hit
it with my new NIR CF pass for NAK.
Fixes: 1be4c61c957d ("nir/builder: Add a helper for creating undefs")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28300>
src/compiler/nir/nir_builder.c | 16 ++++++++++++++++
src/compiler/nir/nir_builder.h | 7 +++----
2 files changed, 19 insertions(+), 4 deletions(-)
```
Crash happens late in the backend during `nir_lower_vec_to_regs`:
```
Thread 1 "run" received signal SIGSEGV, Segmentation fault.
nir_instr_prev (instr=0x1126298) at ../src/compiler/glsl/list.h:203
203 return n->prev == NULL;
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.38-16.fc39.x86_64 libX11-xcb-1.8.7-1.fc39.x86_64 libXau-1.0.11-3.fc39.x86_64 libdrm-2.4.120-1.fc39.x86_64 libedit-3.1-48.20230828cvs.fc39.x86_64 libepoxy-1.5.10-4.fc39.x86_64 libffi-3.4.4-4.fc39.x86_64 libgomp-13.2.1-7.fc39.x86_64 libstdc++-13.2.1-7.fc39.x86_64 libwayland-client-1.22.0-2.fc39.x86_64 libwayland-server-1.22.0-2.fc39.x86_64 libxcb-1.13.1-12.fc39.x86_64 libxshmfence-1.3-13.fc39.x86_64 llvm-libs-17.0.6-3.fc39.x86_64 ncurses-libs-6.4-7.20230520.fc39.1.x86_64
(gdb) bt
#0 nir_instr_prev (instr=0x1126298) at ../src/compiler/glsl/list.h:203
#1 reduce_cursor (cursor=...) at ../src/compiler/nir/nir.c:997
#2 0x00007ffff6d05e45 in nir_cursors_equal (a=..., b=...) at ../src/compiler/nir/nir.c:1027
#3 0x00007ffff6d0ac36 in nir_builder_instr_insert_at_top (build=build@entry=0x7fffffffb190, instr=instr@entry=0xffbec8) at ../src/compiler/nir/nir_builder.c:387
#4 0x00007ffff704084f in nir_decl_reg (num_array_elems=0, bit_size=32, num_components=4, b=0x7fffffffb190) at ../src/compiler/nir/nir_builder.h:1834
#5 lower (b=b@entry=0x7fffffffb190, instr=instr@entry=0x1126dd8, data_=data_@entry=0x7fffffffb180) at ../src/compiler/nir/nir_lower_vec_to_regs.c:216
#6 0x00007ffff7041598 in lower (data_=0x7fffffffb180, instr=0x1126dd8, b=0x7fffffffb190) at ../src/compiler/nir/nir_lower_vec_to_regs.c:198
#7 nir_function_instructions_pass (pass=<optimized out>, preserved=3, cb_data=0x7fffffffb180, impl=0xfe1760) at ../src/compiler/nir/nir_builder.h:103
#8 nir_shader_instructions_pass (shader=0xfe1760, pass=<optimized out>, preserved=3, cb_data=0x7fffffffb180) at ../src/compiler/nir/nir_builder.h:135
#9 nir_lower_vec_to_regs (shader=shader@entry=0x4785c0, cb=cb@entry=0x0, _data=_data@entry=0x0) at ../src/compiler/nir/nir_lower_vec_to_regs.c:259
#10 0x00007ffff6ffb50b in nir_to_rc_options (s=<optimized out>, screen=0x475bb0, options=0x7ffff7501028 <hwtcl_r500_options>) at ../src/gallium/drivers/r300/compiler/nir_to_rc.c:2458
#11 0x00007ffff6fe744e in r300_create_vs_state (pipe=0x728980, shader=0x7fffffffb550) at ../src/gallium/drivers/r300/r300_state.c:1962
#12 0x00007ffff694dec9 in st_create_common_variant (st=st@entry=0x7ef1f0, prog=prog@entry=0xf79e50, key=key@entry=0x7fffffffb830) at ../src/mesa/state_tracker/st_program.c:781
#13 0x00007ffff695109b in st_get_common_variant (st=st@entry=0x7ef1f0, prog=prog@entry=0xf79e50, key=key@entry=0x7fffffffb830) at ../src/mesa/state_tracker/st_program.c:834
#14 0x00007ffff6951601 in st_precompile_shader_variant (prog=0xf79e50, st=0x7ef1f0) at ../src/mesa/state_tracker/st_program.c:1320
#15 st_finalize_program (st=0x7ef1f0, prog=0xf79e50) at ../src/mesa/state_tracker/st_program.c:1421
#16 0x00007ffff6bdc39f in st_link_glsl_to_nir (shader_program=0x4172e0, ctx=0x7ef1f0) at ../src/mesa/state_tracker/st_glsl_to_nir.cpp:753
#17 st_link_shader (ctx=ctx@entry=0x7fffef0a9010, prog=prog@entry=0x4172e0) at ../src/mesa/state_tracker/st_glsl_to_nir.cpp:989
#18 0x00007ffff6b8a29b in link_program (no_error=<optimized out>, shProg=<optimized out>, ctx=<optimized out>) at ../src/mesa/main/shaderapi.c:1336
#19 link_program_error (ctx=0x7fffef0a9010, shProg=0x4172e0) at ../src/mesa/main/shaderapi.c:1445
#20 0x0000000000403e7c in main._omp_fn.0 () at run.c:846
#21 0x00007ffff7e0a286 in GOMP_parallel () from /lib64/libgomp.so.1
#22 0x000000000040298d in main (argc=<optimized out>, argv=<optimized out>) at run.c:672
```
This is how NIR looks just before:
```
nir_convert_from_ssa
shader: MESA_SHADER_VERTEX
source_sha1: {0x29b48658, 0xf5a27373, 0xd6272160, 0x1889e085, 0x00d29486}
name: GLSL1
label: shaders/gnome-shell-42/138.shader_test
internal: false
stage: 0
next_stage: 4
num_ubos: 1
inputs_read: 15-16
outputs_written: 0,32-38
subgroup_size: 1
bit_sizes_float: 0x20
bit_sizes_int: 0x21
first_ubo_is_default_ubo: true
flrp_lowered: true
inputs: 2
outputs: 8
uniforms: 14
decl_var shader_in INTERP_MODE_NONE none vec2 aPosition (VERT_ATTRIB_GENERIC0.xy, 0, 0)
decl_var shader_in INTERP_MODE_NONE none vec4 aColor (VERT_ATTRIB_GENERIC1.xyzw, 1, 0)
decl_var shader_out INTERP_MODE_NONE none vec4 gl_Position (VARYING_SLOT_POS.xyzw, 0, 0)
decl_var shader_out INTERP_MODE_NONE none vec4 final_color (VARYING_SLOT_VAR0.xyzw, 1, 0)
decl_var shader_out INTERP_MODE_NONE none vec4 transformed_outside_outline (VARYING_SLOT_VAR1.xyzw, 2, 0)
decl_var shader_out INTERP_MODE_NONE none vec4 transformed_outside_outline#0 (VARYING_SLOT_VAR2.xyzw, 3, 0)
decl_var shader_out INTERP_MODE_NONE none vec4 transformed_outside_outline#1 (VARYING_SLOT_VAR3.xyzw, 4, 0)
decl_var shader_out INTERP_MODE_NONE none vec4 transformed_inside_outline (VARYING_SLOT_VAR4.xyzw, 5, 0)
decl_var shader_out INTERP_MODE_NONE none vec4 transformed_inside_outline#2 (VARYING_SLOT_VAR5.xyzw, 6, 0)
decl_var shader_out INTERP_MODE_NONE none vec4 transformed_inside_outline#3 (VARYING_SLOT_VAR6.xyzw, 7, 0)
decl_var ubo INTERP_MODE_NONE none vec4[14] uniform_0 (0, 0, 0)
decl_function main (0 params)
impl main {
con block b0: // preds:
32 %0 = load_const (0x00000000)
32x4 %5 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=7, component=0)
32x2 %1 = @load_input (%0 (0x0)) (base=0, range=1, component=0, dest_type=float32, io location=VERT_ATTRIB_GENERIC0 slots=1) // aPosition
32x4 %3 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=4, component=0)
32x4 %6 = ffma %3, %1.xxxx, %5
32x4 %4 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=5, component=0)
32x4 %7 = ffma %4, %1.yyyy, %6
32x4 %9 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=1, component=0)
32x4 %10 = fmul %9, %7.yyyy
32x4 %8 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=0, component=0)
32x4 %11 = ffma %8, %7.xxxx, %10
32x4 %12 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=2, component=0)
32x4 %13 = ffma %12, %7.zzzz, %11
32x4 %14 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=3, component=0)
32x4 %15 = ffma %14, %7.wwww, %13
32x4 %2 = @load_input (%0 (0x0)) (base=1, range=1, component=0, dest_type=float32, io location=VERT_ATTRIB_GENERIC1 slots=1) // aColor
32x3 %16 = fmul %2.xyz, %2.www
32 %18 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=8, component=0)
32x4 %17 = vec4 %16.x, %16.y, %16.z, %2.w
32x4 %19 = fmul %17, %18.xxxx
32x4 %22 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=11, component=0)
32x2 %23 = fadd %22.xy, %22.zw
32x4 %24 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=12, component=0)
32x2 %25 = fadd %22.xy, %24.xy
32x2 %26 = vec2 %23.x, %22.y
32x2 %20 = load_const (0xbf800000, 0x3f800000) = (-1.000000, 1.000000)
32x2 %27 = ffma %24.zw, %20 (-1.000000, 1.000000), %26
32x4 %28 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=13, component=0)
32x2 %29 = fneg %28.xy
32x2 %30 = fabs %28.xy
32x2 %31 = fadd %23, %29
32x2 %32 = vec2 %22.x, %23.y
32x2 %21 = load_const (0x3f800000, 0xbf800000) = (1.000000, -1.000000)
32x2 %33 = ffma %28.zw, %21 (1.000000, -1.000000), %32
32 %34 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=9, component=0)
32x4 %36 = fneg %34.xxxx
32x4 %35 = vec4 %32.x, %26.y, %26.x, %32.y
32x4 %37 = ffma %36, %21 (1.000000, -1.000000).xxyy, %35
32x2 %40 = fabs %24.xy
32 %41 = fneg %40.y
32 %42 = seq %40.x, %41
32x4 %38 = vec4 %25.x, %25.y, %27.x, %27.y
32x4 %107 = fneg %38
32x4 %84 = mov %42.xxxx
32x4 %108 = ffma %107, %84, %38
32x4 %43 = vec4 %37.x, %37.y, %38.z, %38.w
32x4 %109 = ffma %43, %84, %108
32x2 %110 = seq %43.zw, %35.zy
32 %47 = fmul %110.x, %110.y
32x4 %87 = mov %47.xxxx
32x4 %88 = fneg %87
32 %86 = load_const (0x00000000 = 0.000000)
32x4 %89 = slt %88, %86 (0.000000).xxxx
32x4 %104 = fneg %109
32x4 %105 = ffma %104, %89, %109
32x4 %48 = vec4 %109.x, %109.y, %37.z, %43.y
32x4 %106 = ffma %48, %89, %105
32 %50 = fneg %30.y
32 %51 = seq %30.x, %50
32x4 %39 = vec4 %31.x, %31.y, %33.x, %33.y
32x4 %101 = fneg %39
32x4 %91 = mov %51.xxxx
32x4 %102 = ffma %101, %91, %39
32x4 %52 = vec4 %48.z, %37.w, %39.z, %39.w
32x4 %103 = ffma %52, %91, %102
32x2 %111 = seq %52.zw, %35.xw
32 %56 = fmul %111.x, %111.y
32x4 %94 = mov %56.xxxx
32x4 %95 = fneg %94
32 %93 = load_const (0x00000000 = 0.000000)
32x4 %96 = slt %95, %93 (0.000000).xxxx
32x4 %98 = fneg %103
32x4 %99 = ffma %98, %96, %103
32x4 %57 = vec4 %103.x, %103.y, %43.x, %52.y
32x4 %100 = ffma %57, %96, %99
32x2 %59 = @load_ubo_vec4 (%0 (0x0), %0 (0x0)) (access=speculatable, base=10, component=0)
32x4 %60 = fadd %37, %59.xyxy
32x4 %61 = fadd %106, %59.xyxy
32x4 %62 = fadd %100, %59.xyxy
32x4 %63 = ffma %3.xyxy, %60.xxzz, %5.xyxy
32x4 %64 = ffma %4.xyxy, %60.yyww, %63
32x4 %65 = ffma %3.xyxy, %61.xxzz, %5.xyxy
32x4 %66 = ffma %4.xyxy, %61.yyww, %65
32x4 %67 = ffma %3.xyxy, %62.xxzz, %5.xyxy
32x4 %68 = ffma %4.xyxy, %62.yyww, %67
32x4 %112 = ffma %3.xyxy, %35.xxzz, %5.xyxy
32x4 %113 = ffma %4.xyxy, %35.yyww, %112
32x2 %73 = ffma %3.xy, %38.xx, %5.xy
32x2 %74 = ffma %4.xy, %38.yy, %73
32x2 %75 = ffma %3.xy, %43.zz, %5.xy
32x2 %76 = ffma %4.xy, %43.ww, %75
32x2 %77 = ffma %3.xy, %39.xx, %5.xy
32x2 %78 = ffma %4.xy, %39.yy, %77
32x2 %79 = ffma %3.xy, %52.zz, %5.xy
32x2 %80 = ffma %4.xy, %52.ww, %79
@store_output (%15, %0 (0x0)) (base=0, range=1, wrmask=xyzw, component=0, src_type=float32, io location=VARYING_SLOT_POS slots=1, xfb(), xfb2()) // gl_Position
@store_output (%19, %0 (0x0)) (base=1, range=1, wrmask=xyzw, component=0, src_type=float32, io location=VARYING_SLOT_VAR0 slots=1, xfb(), xfb2()) // final_color
@store_output (%64, %0 (0x0)) (base=2, range=1, wrmask=xyzw, component=0, src_type=float32, io location=VARYING_SLOT_VAR1 slots=1, xfb(), xfb2()) // transformed_outside_outline
@store_output (%66, %0 (0x0)) (base=3, range=1, wrmask=xyzw, component=0, src_type=float32, io location=VARYING_SLOT_VAR2 slots=1, xfb(), xfb2()) // transformed_outside_outline
@store_output (%68, %0 (0x0)) (base=4, range=1, wrmask=xyzw, component=0, src_type=float32, io location=VARYING_SLOT_VAR3 slots=1, xfb(), xfb2()) // transformed_outside_outline
32x4 %81 = vec4 %113.x, %113.y, %113.z, %113.w
@store_output (%81, %0 (0x0)) (base=5, range=1, wrmask=xyzw, component=0, src_type=float32, io location=VARYING_SLOT_VAR4 slots=1, xfb(), xfb2()) // transformed_inside_outline
32x4 %82 = vec4 %74.x, %74.y, %76.x, %76.y
@store_output (%82, %0 (0x0)) (base=6, range=1, wrmask=xyzw, component=0, src_type=float32, io location=VARYING_SLOT_VAR5 slots=1, xfb(), xfb2()) // transformed_inside_outline
32x4 %83 = vec4 %78.x, %78.y, %80.x, %80.y
@store_output (%83, %0 (0x0)) (base=7, range=1, wrmask=xyzw, component=0, src_type=float32, io location=VARYING_SLOT_VAR6 slots=1, xfb(), xfb2()) // transformed_inside_outline
// succs: b1
block b1:
}
```
CC @gfxstrand @alyssa I probably need to fix something in the r300 backend, but I thought I would ask first if you have any ideas as this might be obvious to you what goes wrong, before I start digging.https://gitlab.freedesktop.org/mesa/mesa/-/issues/10829[bisected][regression] kitty fails to start due to `glfwWindowHint(GLFW_SRGB_...2024-03-15T20:35:40ZPatrik Plihal[bisected][regression] kitty fails to start due to `glfwWindowHint(GLFW_SRGB_CAPABLE,true)`since mesa 6a084e2b081882ff027e426e8faddbe1f5497614 the terminal app [kitty](https://github.com/kovidgoyal/kitty) 0.32.2 (or newer)
fails with
```
$ kitty
[075 21:17:57.069937] [glfw error 65544]: EGL: Failed to create window surface:...since mesa 6a084e2b081882ff027e426e8faddbe1f5497614 the terminal app [kitty](https://github.com/kovidgoyal/kitty) 0.32.2 (or newer)
fails with
```
$ kitty
[075 21:17:57.069937] [glfw error 65544]: EGL: Failed to create window surface: Arguments are inconsistent
[075 21:17:57.075025] Traceback (most recent call last):
File "/usr/bin/../lib/kitty/kitty/main.py", line 561, in main
_main()
File "/usr/bin/../lib/kitty/kitty/main.py", line 553, in _main
run_app(opts, cli_opts, bad_lines)
File "/usr/bin/../lib/kitty/kitty/main.py", line 296, in __call__
_run_app(opts, args, bad_lines)
File "/usr/bin/../lib/kitty/kitty/main.py", line 268, in _run_app
window_id = create_os_window(
^^^^^^^^^^^^^^^^^
ValueError: Failed to create GLFWwindow
```
as mentioned in [kitty/issues/7174](https://github.com/kovidgoyal/kitty/issues/7174)
workarounds: launching with `KITTY_DISABLE_WAYLAND=1 kitty` or
compiling kitty without line 1080 in [kitty/glfw.c](https://github.com/kovidgoyal/kitty/blob/master/kitty/glfw.c#L1080)
```
if (!global_state.is_wayland || !is_nvidia_gpu_driver()) glfwWindowHint(GLFW_SRGB_CAPABLE, true);
```
---
sysinfo:
```
System:
Host: blackbox Kernel: 6.7.9-arch1-1 arch: x86_64 bits: 64 compiler: gcc
v: 13.2.1
Desktop: Sway v: 1.9 lm: greetd Distro: Arch Linux
CPU:
Info: 8-core model: AMD Ryzen 7 5700X bits: 64 type: MT MCP arch: Zen 3+
rev: 2 cache: L1: 512 KiB L2: 4 MiB L3: 32 MiB
Speed (MHz): avg: 1254 high: 4663 min/max: 550/4663 boost: enabled cores:
1: 4663 2: 550 3: 550 4: 550 5: 550 6: 4663 7: 550 8: 550 9: 550 10: 550
11: 550 12: 550 13: 550 14: 3600 15: 550 16: 550 bogomips: 108836
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3
Graphics:
Device-1: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT]
vendor: Tul / PowerColor AXRX driver: amdgpu v: kernel arch: RDNA-1 pcie:
speed: 16 GT/s lanes: 16 ports: active: DP-1 empty: DP-2,DP-3,HDMI-A-1
bus-ID: 0b:00.0 chip-ID: 1002:731f
Display: wayland server: X.org v: 1.21.1.11 with: Xwayland v: 23.2.4
compositor: Sway v: 1.9 driver: gpu: amdgpu display-ID: 1
Monitor-1: DP-1 model: Dell UP2516D res: 2560x1440 dpi: 118
diag: 634mm (25")
API: EGL v: 1.5 platforms: device: 0 drv: radeonsi device: 1 drv: swrast
surfaceless: drv: radeonsi wayland: drv: radeonsi x11: drv: radeonsi
inactive: gbm
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd v: N/A glx-v: 1.4
direct-render: yes renderer: AMD Radeon RX 5700 XT (radeonsi navi10 LLVM
17.0.6 DRM 3.57 6.7.9-arch1-1) device-ID: 1002:731f
API: Vulkan v: 1.3.279 surfaces: xcb,xlib,wayland device: 0
type: discrete-gpu driver: mesa radv device-ID: 1002:731f
```https://gitlab.freedesktop.org/mesa/mesa/-/issues/10788SDL 2 fails in Wayland mode: Failed to create temporary window: unable to cre...2024-03-15T20:47:25ZShmerlSDL 2 fails in Wayland mode: Failed to create temporary window: unable to create an EGL window surface (call to eglCreateWindowSurface failed, reporting an error of EGL_BAD_MATCH)When running dosbox-staging with SDL in Wayland mode (`export SDL_VIDEODRIVER='wayland'`), it fails with such error:
```
2024-03-10 14:05:19.619 | SDL: Failed to create window: unable to create an EGL window surface (call to eglCreateWi...When running dosbox-staging with SDL in Wayland mode (`export SDL_VIDEODRIVER='wayland'`), it fails with such error:
```
2024-03-10 14:05:19.619 | SDL: Failed to create window: unable to create an EGL window surface (call to eglCreateWindowSurface failed, reporting an error of EGL_BAD_MATCH)
2024-03-10 14:05:19.619 | OPENGL: Could not create OpenGL window, using 'texture' output mode
2024-03-10 14:05:19.631 | SDL: Failed to create temporary window: unable to create an EGL window surface (call to eglCreateWindowSurface failed, reporting an error of EGL_BAD_MATCH)
Stack trace:
6 0x4d54de _start + 46
5 0x7fd3c2366785 __libc_start_main + 133
4 0x7fd3c23666ca /lib/x86_64-linux-gnu/libc.so.6(+0x276ca) [0x7fd3c23666ca]
3 0x77b3b0 sdl_main(int, char**) + 5632
2 0x98a1a6 Config::Init() const + 214
1 0x77879e dosbox() [0x77879e]
0 0x776c81 dosbox() [0x776c81]
2024-03-10 14:05:19.631 | ABORT: SDL: Could not initialize video: unable to create an EGL window surface (call to eglCreateWindowSurface failed, reporting an error of EGL_BAD_MATCH)
```
It started happening only recently in Mesa-main:
```
OpenGL renderer string: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 17.0.6, DRM 3.57, 6.8.0-rc7-dirty)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.1.0-devel (git-cc74a819e4)
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.1.0-devel (git-cc74a819e4)
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.1.0-devel (git-cc74a819e4)
```
It works fine for example with slightly earlier one (I'll try to find the exact offending change). I.e. for instance this one works fine (which is Mesa from around Feb 24, 2024.
```
OpenGL renderer string: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 19.0.0, DRM 3.57, 6.8.0-rc7-dirty)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.1.0-devel (git-423add61e2)
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.1.0-devel (git-423add61e2)
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.1.0-devel (git-423add61e2)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
```
* SDL version: 2.30.0
* Dosbox Staging: 0.81.0
* KDE Plasma 5.27.10https://gitlab.freedesktop.org/mesa/mesa/-/issues/10747[bisected][regression][zink][gen9] piglit failures on gen9 intel chips.2024-03-08T17:28:45Zngcortes[bisected][regression][zink][gen9] piglit failures on gen9 intel chips.Looks like these failures began after !27867 got merged.
You can review the failures here: https://mesa-ci.01.org/gl_main/builds/5609/group/63a9f0ea7bb98050796b649e85481845
stderr seems to mention an unsupported format:
```
...
MESA: ...Looks like these failures began after !27867 got merged.
You can review the failures here: https://mesa-ci.01.org/gl_main/builds/5609/group/63a9f0ea7bb98050796b649e85481845
stderr seems to mention an unsupported format:
```
...
MESA: error: zink: refusing to create possibly-srgb dmabuf due to missing driver support: PIPE_FORMAT_B8G8R8X8_SRGB not supported!
...
```ngcortesngcorteshttps://gitlab.freedesktop.org/mesa/mesa/-/issues/10428Visual artifacts on radeon video card in latest 24.0 branch2024-03-11T01:29:50ZMarco PiazzaVisual artifacts on radeon video card in latest 24.0 branch### Description
Latest mesa git self compiled has some trouble.
My gnome-shell (and GDM) flickers and many text are hidden until I pass over with the mouse.
### System information
```
inxi -GSC -xx
System:
Host: albireo Kernel: 6.6.7...### Description
Latest mesa git self compiled has some trouble.
My gnome-shell (and GDM) flickers and many text are hidden until I pass over with the mouse.
### System information
```
inxi -GSC -xx
System:
Host: albireo Kernel: 6.6.7-bfq arch: x86_64 bits: 64 compiler: gcc
v: 12.2.0 Desktop: GNOME v: 45.2 tk: GTK v: 3.24.38 wm: gnome-shell dm: GDM3
Distro: Debian GNU/Linux jessie/sid
CPU:
Info: quad core model: AMD A4-5000 APU with Radeon HD Graphics bits: 64
type: MCP arch: Jaguar rev: 1 cache: L1: 256 KiB L2: 2 MiB
Speed (MHz): avg: 1057 high: 1098 min/max: 800/1500 boost: disabled cores:
1: 934 2: 1098 3: 1098 4: 1098 bogomips: 11977
Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
Device-1: AMD Kabini [Radeon HD 8330] vendor: Toshiba driver: amdgpu
v: kernel arch: GCN-2 ports: active: LVDS-1 empty: HDMI-A-1,VGA-1
bus-ID: 00:01.0 chip-ID: 1002:9832
Device-2: AMD Sun PRO [Radeon HD 8570A/8570M] vendor: Toshiba
driver: amdgpu v: kernel arch: GCN-1 pcie: speed: 2.5 GT/s lanes: 4
bus-ID: 01:00.0 chip-ID: 1002:6663 temp: 40.0 C
Device-3: IMC Networks TOSHIBA Web Camera - HD driver: uvcvideo type: USB
rev: 2.0 speed: 480 Mb/s lanes: 1 bus-ID: 1-4:4 chip-ID: 13d3:5606
Display: x11 server: X.Org v: 1.20.9 with: Xwayland v: 23.2.3
compositor: gnome-shell driver: X: loaded: amdgpu unloaded: modesetting
alternate: fbdev,vesa dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1
Screen-1: 0 s-res: 1366x768 s-dpi: 96
Monitor-1: LVDS-1 mapped: LVDS model: LG Display 0x033a res: 1366x768
dpi: 101 diag: 395mm (15.5")
API: EGL v: 1.5 platforms: gbm: drv: N/A x11: drv: N/A
inactive: wayland,device
API: OpenGL v: 4.6 vendor: amd v: N/A glx-v: 1.4 es-v: 3.2
direct-render: yes renderer: AMD Radeon HD 8330 (radeonsi kabini LLVM
16.0.6 DRM 3.54 6.6.7-bfq) device-ID: 1002:9832
API: Vulkan v: 1.2.70 surfaces: xcb device: 0 type: integrated-gpu
driver: N/A device-ID: 1002:9832 device: 1 type: discrete-gpu driver: N/A
device-ID: 1002:6663 device: 2 type: cpu driver: N/A device-ID: 10005:0000
```
### Describe the issue
My gnome-shell screen has visual artifacts when usually it has none.
### Regression
Gnome-shell used to work as expected
### Extra information
It seems that the bug is releated to Wayland.
In fact usally gnome shell starts whith wayland rendering, but (as I can see in the command below now it start with Xorg rendering)
```
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x54 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 3 associated providers: 0 name:AMD Radeon HD 8330 @ pci:0000:00:01.0
Provider 1: id: 0x7c cap: 0xd, Source Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 0 name:AMD Radeon HD 8500M Series @ pci:0000:01:00.0
```https://gitlab.freedesktop.org/mesa/mesa/-/issues/10295Software rendering texture quality regression (anisotropic filtering) Mesa 21...2024-01-08T09:10:56ZUlrich HertleinSoftware rendering texture quality regression (anisotropic filtering) Mesa 21.2 -> Mesa 23.1### System information
- good: Mesa 21.2.6
- bad: Mesa 23.1.4
- OS: Ubuntu 20.04 / Rocky Linux 9
### Describe the issue
We've recently upgraded our server-side rendering containers to a newer Linux distro.
This upgraded the Mesa vers...### System information
- good: Mesa 21.2.6
- bad: Mesa 23.1.4
- OS: Ubuntu 20.04 / Rocky Linux 9
### Describe the issue
We've recently upgraded our server-side rendering containers to a newer Linux distro.
This upgraded the Mesa version from 21.2.6 to 23.1.4.
With the new Mesa version, we've noticed a severe regression in the quality of texture rendering.
The issue is not related to the OS upgrade, only to the Mesa version that is used.
We've been able to create a minimal desktop reproduction app (SDL2, GLU, GL 2.1) that shows the effect and can be made available on request.
Through `git bisect` we've been able to trace the root cause to the introduction of anisotropic filtering back in 2021:
```
commit 0d4d7594d14c06168ab8c75f67d4b32b359552f8
Author: Dave Airlie <airlied@redhat.com>
Date: Mon Feb 8 12:37:40 2021 +1000
llvmpipe: enable GL_ARB_texture_filter_anisotropic
```
### Regression
- using software rendering:
- good version: renders the textures sharply as expected (see below)
- bad version: renders the textures blurry
- using hardware rendering: no noticeable difference
- textures are rendered using an orthographic camera
- min_filter=NEAREST, mag_filter=NEAREST, generate_mipmap=TRUE, max_anisotropy=4 (default, because extension is supported)
- quads are rendered facing the camera, i.e. not at an angle
### Screenshots
- the left half shows hardware rendering (Mesa Intel(R) UHD Graphics)
- the right half shows software rendering (llvmpipe, enabled via `LIBGL_ALWAYS_SOFTWARE=1`)
- good:
![mesa_21.2.6_anisotropic_hw_vs_sw](/uploads/51508c538d0b99296db24a7dbd5c7535/mesa_21.2.6_anisotropic_hw_vs_sw.png)
- bad:
![mesa_23.2.1_anisotropic_hw_vs_sw](/uploads/7f4ae89949adfb1d759ed13720515c41/mesa_23.2.1_anisotropic_hw_vs_sw.png)Dave AirlieDave Airliehttps://gitlab.freedesktop.org/mesa/mesa/-/issues/10093[bisected] Zink "regression" with Intel DDX2023-11-03T22:39:38ZMatti Hämäläinen[bisected] Zink "regression" with Intel DDX(Yes, I am aware that the recommendation nowadays is for most people to use the modesetting DDX, but since the error message I get is a bit misleading, I thought to report this anyway.)
After Mesa commit cedb534a1763b6bd3c733d439e5d145a...(Yes, I am aware that the recommendation nowadays is for most people to use the modesetting DDX, but since the error message I get is a bit misleading, I thought to report this anyway.)
After Mesa commit cedb534a1763b6bd3c733d439e5d145ae6f1270e "egl/glx: don't load non-sw zink without dri3 support", when attempting to use Zink on my Haswell system (which is using Xorg with Intel DDX), practically all GL applications fail. Among other errors there is "DRI3 not available".
That message, added by the above mentioned commit, however, is a bit misleading. The error is reported if dri3_check_multibuffer() returns false, which occurs if DRI3 or Present extension are missing OR if their version(s) are too low. In my case, Intel DDX claims support for DRI3 1.0 and Present 1.2, whereas the check in Mesa requires DRI3 >= 1.2 (and Present >= 1.2).
So .. if DRI3 1.2 is actually required now, perhaps the error message should be altered, as nitpicky as that may be considering that modesetting DDX may be the only one (?) supporting it. Shrug.
(Patching the DRI3 version check allows me to run things under Zink as before.)https://gitlab.freedesktop.org/mesa/mesa/-/issues/10079clover/r600: crash in evergreen_cs_emit_vertex_buffers2024-01-27T08:50:00ZThomas Debesseclover/r600: crash in evergreen_cs_emit_vertex_buffersI wanted to check the status of [llvm-project#54942](https://github.com/llvm/llvm-project/issues/54942) affecting TeraScale 3 but it looks like I caught a regression in Clover instead.
I'm running Mesa current `main` (60cd0af06c081a6762...I wanted to check the status of [llvm-project#54942](https://github.com/llvm/llvm-project/issues/54942) affecting TeraScale 3 but it looks like I caught a regression in Clover instead.
I'm running Mesa current `main` (60cd0af06c081a6762d0598a9dfbbfc37c2b65d3).
LLVM is `16.0.6`.
I got the crash when trying to run the LuxBall scene from LuxMark 3.
I reproduce the crash on both TeraScale 3 and TeraScale 2.
## TeraScale 3 Cayman XT (AMD Radeon HD 6970)
```
Thread 12 "luxmark" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffccff96c0 (LWP 1149117)]
0x00007fffd672dd32 in evergreen_cs_emit_vertex_buffers ()
from lib/x86_64-linux-gnu/gallium-pipe/pipe_r600.so
Thread 12 (Thread 0x7fffccff96c0 (LWP 1149117) "luxmark"):
#0 0x00007fffd672dd32 in evergreen_cs_emit_vertex_buffers () from lib/x86_64-linux-gnu/gallium-pipe/pipe_r600.so
#1 0x00007fffd672ae7f in evergreen_launch_grid () from lib/x86_64-linux-gnu/gallium-pipe/pipe_r600.so
#2 0x00007fffdb28c311 in clover::kernel::launch(clover::command_queue&, std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&) () from lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#3 0x00007fffdb27fef1 in clover::event::trigger() () from lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#4 0x00007fffdb28154d in clover::hard_event::hard_event(clover::command_queue&, unsigned int, clover::ref_vector<clover::event> const&, std::function<void (clover::event&)>) () from lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#5 0x00007fffdb24dfa2 in clEnqueueNDRangeKernel () from lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#6 0x00005555559bc9e6 in slg::PathOCLBaseRenderThread::ThreadFilm::ClearFilm(cl::CommandQueue&, cl::Kernel&, unsigned long) ()
#7 0x00005555559c63b3 in slg::PathOCLBaseRenderThread::InitRender() ()
#8 0x00005555559c6454 in slg::PathOCLBaseRenderThread::Start() ()
#9 0x00005555559b73e1 in slg::PathOCLBaseRenderEngine::StartLockLess() ()
#10 0x00005555557f2b27 in slg::RenderEngine::Start() ()
#11 0x0000555555759533 in LuxRenderSession::Start() ()
#12 0x000055555572a5d4 in LuxMarkApp::EngineInitThreadImpl(LuxMarkApp*) ()
#13 0x0000555555add92b in thread_proxy ()
#14 0x00007ffff4297ada in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
#15 0x00007ffff432847c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
```
## TeraScale 2 Cypress XT (ATi Radeon HD 5870 Eyefinity⁶ Edition)
```
Thread 12 "luxmark" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffccff96c0 (LWP 1156866)]
0x00007fffd672dd32 in evergreen_cs_emit_vertex_buffers ()
from lib/x86_64-linux-gnu/gallium-pipe/pipe_r600.so
Thread 12 (Thread 0x7fffccff96c0 (LWP 1156866) "luxmark"):
#0 0x00007fffd672dd32 in evergreen_cs_emit_vertex_buffers () from lib/x86_64-linux-gnu/gallium-pipe/pipe_r600.so
#1 0x00007fffd672ae7f in evergreen_launch_grid () from lib/x86_64-linux-gnu/gallium-pipe/pipe_r600.so
#2 0x00007fffdb28c311 in clover::kernel::launch(clover::command_queue&, std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&) () from lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#3 0x00007fffdb27fef1 in clover::event::trigger() () from lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#4 0x00007fffdb28154d in clover::hard_event::hard_event(clover::command_queue&, unsigned int, clover::ref_vector<clover::event> const&, std::function<void (clover::event&)>) () from lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#5 0x00007fffdb24dfa2 in clEnqueueNDRangeKernel () from lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#6 0x00005555559bc9e6 in slg::PathOCLBaseRenderThread::ThreadFilm::ClearFilm(cl::CommandQueue&, cl::Kernel&, unsigned long) ()
#7 0x00005555559c63b3 in slg::PathOCLBaseRenderThread::InitRender() ()
#8 0x00005555559c6454 in slg::PathOCLBaseRenderThread::Start() ()
#9 0x00005555559b73e1 in slg::PathOCLBaseRenderEngine::StartLockLess() ()
#10 0x00005555557f2b27 in slg::RenderEngine::Start() ()
#11 0x0000555555759533 in LuxRenderSession::Start() ()
#12 0x000055555572a5d4 in LuxMarkApp::EngineInitThreadImpl(LuxMarkApp*) ()
#13 0x0000555555add92b in thread_proxy ()
#14 0x00007ffff4297ada in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
#15 0x00007ffff432847c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
```https://gitlab.freedesktop.org/mesa/mesa/-/issues/10057gen9 zink: regression on piglit.spec.glsl-1_50.gs-max-output2023-10-27T18:24:44ZMark Janesgen9 zink: regression on piglit.spec.glsl-1_50.gs-max-outputbisected to:
```
8ee0d6dd711e639fc713a6f6b87d9879f1cf1599
Author: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
zink: add a third cmdbuf for unsynchronized (not reordered) ops
this provides functionality for unsynchronized tex...bisected to:
```
8ee0d6dd711e639fc713a6f6b87d9879f1cf1599
Author: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
zink: add a third cmdbuf for unsynchronized (not reordered) ops
this provides functionality for unsynchronized texture uploads without
HIC support by adding a cmdbuf which can only be accessed directly by
the frontend thread
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25624>
```
output:
```
$ glsl-1.50-gs-max-output -scan 1 20 -auto -fbo
piglit: debug: Requested an OpenGL 3.2 Core Context, and received a matching 4.6 context
Case: instances = 8 points = 1 invocations = 32 outputs = 256 components = 0
Case: instances = 1 points = 8 invocations = 32 outputs = 256 components = 0
Case: instances = 2 points = 4 invocations = 32 outputs = 256 components = 0
Case: instances = 256 points = 1 invocations = 32 outputs = 8 components = 124
Case: instances = 1 points = 256 invocations = 32 outputs = 8 components = 124
Case: instances = 16 points = 16 invocations = 32 outputs = 8 components = 124
Case: instances = 184 points = 1 invocations = 20 outputs = 10 components = 11
Case: instances = 8 points = 4 invocations = 27 outputs = 42 components = 10
Case: instances = 3 points = 1297 invocations = 3 outputs = 7 components = 51
Case: instances = 3 points = 4 invocations = 23 outputs = 232 components = 0
Case: instances = 8 points = 5 invocations = 27 outputs = 67 components = 10
Case: instances = 15 points = 10 invocations = 4 outputs = 33 components = 18
Case: instances = 17 points = 17 invocations = 10 outputs = 21 components = 44
Case: instances = 2 points = 9 invocations = 28 outputs = 206 components = 0
Case: instances = 211 points = 1 invocations = 2 outputs = 131 components = 0
Probe at (0,216)
Expected: 0.000000 0.000000 0.000000 1.000000
Observed: 0.000000 0.000000 0.000000 0.000000
Case: instances = 138 points = 2 invocations = 31 outputs = 10 components = 86
Case: instances = 21 points = 11 invocations = 2 outputs = 104 components = 0
Case: instances = 3 points = 11 invocations = 16 outputs = 108 components = 2
Case: instances = 5 points = 1 invocations = 28 outputs = 177 components = 1
Case: instances = 1 points = 7 invocations = 28 outputs = 237 components = 0
```Mike BlumenkrantzMike Blumenkrantzhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/9925radeonsi: Minecraft + Sodium hangs on Vega 56/64 (bisected)2024-01-10T01:47:36Zgoeiecool9999radeonsi: Minecraft + Sodium hangs on Vega 56/64 (bisected)### System information
- OS: Arch Linux
- GPU: AMD RX Vega 56 (Advanced Micro Devices, Inc. \[AMD/ATI\] Vega 10 XL/XT \[Radeon RX Vega 56/64\])
- Kernel version: 6.4.16-273-tkg-bore
- Mesa version: 23.1.0
- Xserver version: X.Org X Serve...### System information
- OS: Arch Linux
- GPU: AMD RX Vega 56 (Advanced Micro Devices, Inc. \[AMD/ATI\] Vega 10 XL/XT \[Radeon RX Vega 56/64\])
- Kernel version: 6.4.16-273-tkg-bore
- Mesa version: 23.1.0
- Xserver version: X.Org X Server 1.21.1.8
- Desktop manager and compositor: XFCE4
### Describe the issue
Running minecraft with the sodium mod (performance improvement mod) immediately hangs as soon as the game loads into a world.
It recovers briefly but then immediately hangs again. It also causes visible corruption (vertex data). Hangs are accompanied by kernel log messages (see below)
This is tracked in [this sodium github issue.](https://github.com/CaffeineMC/sodium-fabric/issues/1792)
I think this is closely related to my other issue #9593 affecting Euro Truck Simulator 2. Behavior and the version where the problems started seem to be the same.
### Regression
I bisected this issue to commit: b5b0ded4c16c591aac9249e0a85f12f915143a8e.
Before this commit there is no problem.
### Log files as attachment
```[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_low timeout, but soft recovered
amdgpu 0000:0c:00.0: amdgpu: [gfxhub0] no-retry page fault (src_id:0 ring:24 vmid:3 pasid:32777, for process java pid 180280 thread java:cs0 pid 180412)
amdgpu 0000:0c:00.0: amdgpu: in page starting at address 0x0000800109bb1000 from IH client 0x1b (UTCL2)
amdgpu 0000:0c:00.0: amdgpu: VM_L2_PROTECTION_FAULT_STATUS:0x00301030
amdgpu 0000:0c:00.0: amdgpu: Faulty UTCL2 client ID: TCP (0x8)
amdgpu 0000:0c:00.0: amdgpu: MORE_FAULTS: 0x0
amdgpu 0000:0c:00.0: amdgpu: WALKER_ERROR: 0x0
amdgpu 0000:0c:00.0: amdgpu: PERMISSION_FAULTS: 0x3
amdgpu 0000:0c:00.0: amdgpu: MAPPING_ERROR: 0x0
amdgpu 0000:0c:00.0: amdgpu: RW: 0x0
```
### Screenshots/video files
See Sodium github issueTimur KristófTimur Kristófhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/9569r600: WebGL crashing since 23.1.02023-08-15T17:29:54ZAllen Ballwayr600: WebGL crashing since 23.1.0### System information
- OS: Chrome OS
- GPU: 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity 2 [Radeon HD 7420G] [1002:9992]
- also seen on 1002:9802, 1002:9992, 1002:9710, 1002:9807, 1002:68c0...### System information
- OS: Chrome OS
- GPU: 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity 2 [Radeon HD 7420G] [1002:9992]
- also seen on 1002:9802, 1002:9992, 1002:9710, 1002:9807, 1002:68c0, 1002:9648, 1002:9997, 1002:9806
- Kernel version: Linux localhost 5.15.124-20403-g0ee9b91ba1ab #1 SMP PREEMPT Fri Aug 4 19:04:07 PDT 2023 x86_64 AMD A4-4300M APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
- Mesa version: 23.1.4 (reproduced from 23.1.0, still happens in 23.1.5)
- Xserver version (if applicable): n/a
- Desktop manager and compositor: Chrome
### Describe the issue
Device will flicker black and occasionally crash graphics because of failing GPU when loading [webgl](webglsamples.org/aquarium/aquarium.html)
### Regression
I bisected until I found the commit which seems to cause the issue. Reverting this in 23.1.4 fixes the crash.
```
commit 244cc152d1b20592120ce1d5dd9627509b73d0b9
Author: Gert Wollny <gert.wollny@collabora.com>
Date: Tue Feb 28 17:54:46 2023 +0100
r600/sfn: redirect copy propagation to alu parent group
If an ALU instruction was emitted from the get-go as group, then
we have to make sure that replacing a source doesn't violate the
readport configuration in the group.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8374
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21684>
```
### Log files as attachment
[dmesg logs around the time of failure](https://gitlab.freedesktop.org/-/snippets/7671)https://gitlab.freedesktop.org/mesa/mesa/-/issues/9501doom3 demo (closed source) rendering artefacts in Mars globe2023-08-14T11:32:25ZAndrew Randrianasuludoom3 demo (closed source) rendering artefacts in Mars globeSo, on my new GeForce 710 I see those artifacts:
![doom3_artifacts1](/uploads/aecfa02ff3cae9fe9dd3cd523032ee12/doom3_artifacts1.png)
I have mesa 5325582968fe4dda5a47851536a6bb05b05bc973
glxinfo:
[glxinfo.log](/uploads/8e74c2c23faedc1...So, on my new GeForce 710 I see those artifacts:
![doom3_artifacts1](/uploads/aecfa02ff3cae9fe9dd3cd523032ee12/doom3_artifacts1.png)
I have mesa 5325582968fe4dda5a47851536a6bb05b05bc973
glxinfo:
[glxinfo.log](/uploads/8e74c2c23faedc19f6edfc26c25e9a17/glxinfo.log)
it says git-86bf78c8e0 but this is due to three patches I have on top of that, one fixing vdpau, one fixing indirect gl extensions and yet another one fixing asserts in qemu/sdl2.
apitrace:
[doom.x86.trace.xz](/uploads/d8a94ce71a68d3f565462472778b6383/doom.x86.trace.xz)https://gitlab.freedesktop.org/mesa/mesa/-/issues/9415RADV, regression : Objects randomly appear/disappear on Unreal Engine 4 title...2024-01-11T12:50:14ZMegWATTTRADV, regression : Objects randomly appear/disappear on Unreal Engine 4 titles using D3D12 backend on Polaris### Description
On UE4 titles using the D3D12 backend with VKD3D, some objects disapear and reappear intermittently (usually between each frames).
On Dead by Daylight, this affect only affect props (pallets, generators, hooks..) The de...### Description
On UE4 titles using the D3D12 backend with VKD3D, some objects disapear and reappear intermittently (usually between each frames).
On Dead by Daylight, this affect only affect props (pallets, generators, hooks..) The default D3D11 backend is unaffected by this bug.
On Hogwarts Legacy, Props and distant terrain also have the same issue. A lot more UE4 D3D12 titles are probably affected, I only tested those 2.
This bug only affect my Polaris10 GPU (RX 570), my Navi 22 (RX 6700) is unaffected.
I couldn't reproduce this bug on Lyra demo (using UE 5.2)
### Steps to reproduce
Running affected D3D12 UE4 games on polaris (and maybe other GCN cards).
### System information
- OS: Ubuntu 23.04
- GPU: RX 570 4GB
- Kernel version: 6.2.0-25-generic
- Mesa version: 23.1.3 from kisak-mesa
- Desktop environment: KDE
#### If applicable
- Wine/Proton version: 8.0-2
### Regression
The bug happen since d6761f54b5a470bf35591d3d89a83c0bea85eb92 from !22556.Samuel PitoisetSamuel Pitoisethttps://gitlab.freedesktop.org/mesa/mesa/-/issues/9321Incorrect PDF rendering with Firefox (QEMU using virtio GPU) [bisected]2023-08-07T17:39:45ZDiego ViolaIncorrect PDF rendering with Firefox (QEMU using virtio GPU) [bisected]### System information
Host:
- OS: Arch Linux
- GPU: 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT] [1002:73df] (rev c5)
- Kernel version: Linu...### System information
Host:
- OS: Arch Linux
- GPU: 03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT] [1002:73df] (rev c5)
- Kernel version: Linux ryzen 6.4.1-arch2-1 #1 SMP PREEMPT_DYNAMIC Tue, 04 Jul 2023 08:39:40 +0000 x86_64 GNU/Linux
- Mesa version: OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.1.3
- Xserver version (if applicable): The X.Org Foundation Xwayland Version 23.1.2 (12301002)
- Desktop manager and compositor: sway version 1.8.1
Guest:
- OS: Arch Linux
- GPU: 00:02.0 VGA compatible controller [0300]: Red Hat, Inc. Virtio 1.0 GPU [1af4:1050] (rev 01)
- Kernel version: Linux archvm 6.4.1-arch2-1 #1 SMP PREEMPT_DYNAMIC Tue, 04 Jul 2023 08:39:40 +0000 x86_64 GNU/Linux
- Mesa version: OpenGL version string: 4.3 (Compatibility Profile) Mesa 23.1.3
- Xserver version (if applicable): The X.Org Foundation Xwayland Version 23.1.2 (12301002)
- Desktop manager and compositor: sway version 1.8.1
### Describe the issue
When opening a PDF document using Firefox's built-in PDF reader, the document is rendered incorrectly on the guest but not on the host, the guest is Arch on QEMU using the virtio GPU drivers.
I am launching QEMU with the following command:
$ qemu-system-x86_64 -enable-kvm -drive file=arch.qcow2,if=virtio -m 8G -cpu host -smp 8 -M q35 -device virtio-vga-gl -display gtk,gl=on -device intel-hda -device hda-duplex
The host is using the exact same distro (Arch Linux) with the same packages.
- qemu-desktop 8.0.2-1.
- Firefox 115.0.3
### Regression
Yes.
### Screenshots/video files (if applicable)
What it looks like on the host:
![20230706_12h06m46s_grim](/uploads/eb638a4ffbef1e165d8f21c6c236d0ec/20230706_12h06m46s_grim.png)
What it looks like on the guest:
![H11L](/uploads/8bfd5e9889ba46732d7ab1d7fbe85728/H11L.png)Gert WollnyGert Wollnyhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/9189[RADV] Kernel Regression & Bisected. Uneven framepacing in Cyberpunk. Potenti...2024-03-24T03:54:30ZJaap Buurman[RADV] Kernel Regression & Bisected. Uneven framepacing in Cyberpunk. Potential RADV bug?### Description
I started playing Cyberpunk 2077 for the first time, and I was experiencing a lot of stuttering with my new 7900 XTX. I tried Googling to see if anyone else had this issue, which made me find this Reddit thread: https://...### Description
I started playing Cyberpunk 2077 for the first time, and I was experiencing a lot of stuttering with my new 7900 XTX. I tried Googling to see if anyone else had this issue, which made me find this Reddit thread: https://www.reddit.com/r/linux_gaming/comments/10bq13c/constant_stuttering_on_cyberpunk_anyone_else/
A framerate cap was mentioned as a workaround, and I can indeed confirm that this "solves" the issue. However, what caught my attention was a comment mentioning that this was introduced in the 5.19 kernel and was NOT present in the 5.18 kernel. I wanted to confirm this, and if it turned out to be true, Bisect it to find the commit that introduced the issue. Since I could not bisect it with my 7900 XTX (Since these older kernels do not support it), I reinstalled my trusty 6900XT, confirmed it also exhibited the same issue, and started bisecting between the v5.18 and v5.19 tag.
I double checked whether it is still an issue on the linux-git, and it is.
As it's a kernel regression, I initially reported it as a kernel bug here: https://gitlab.freedesktop.org/drm/amd/-/issues/2419
@ckoenig and @pepp looked into the issue, but suspected it might be a RADV bug that was only discovered after these changes to the kernel. Which is why I am here to post about this issue.
### Screenshots/video files
* Frame Pacing with bad commit: https://www.youtube.com/watch?v=WhCF5q9Sqlc
* Frame Pacing with good commit: https://www.youtube.com/watch?v=pxF_2CemAgo
### Steps to reproduce
As can be seen in the youtube videos, I am using the builtin benchmark together with mangohud to look for the framepacing issue in a reproducible way. However, the issue is also present during regular gameplay. The results of my kernel bisect is as follows:
Result of Bisect: first bad commit: [8bb31587820a6e04cb613b49238b1800d1a97223] drm/ttm: remove bo->moving
If you want to reproduce my findings, please note that I had to cherry pick the following two commits to make this commit and the one before it testable:
* 925b6e59138cefa47275c67891c65d48d3266d57 Revert "drm/amdgpu: add drm buddy support to amdgpu" (To be able to boot into my DE)
* 94f4c4965e5513ba624488f4b601d6b385635aec drm/amdgpu: partial revert "remove ctx->lock" v2 (To be able to run Cyberpunk)
Both thankfully apply cleanly on the commits that I had to test.
### System information
* Distro name and Version: Archlinux
* Kernel version: Bisected (But still an issue on 6.3.6)
* Driver version: tested with mesa 22.3.4-1 (But still an issue on 23.1.1)
* Desktop environment: Gnome 44.2
* GPU: Ran into the issue with my 7900 XTX. But also an issue on my 6900XT which I used for bisecting.
#### If applicable
- VKD3D version: Whatever is included in Steam's Proton 8.0-2
- Wine/Proton version: Proton 8.0-2
### Regression
Yes, but it is a kernel regression and NOT a mesa regression. However, it was suggested there that it still might be a RADV bug that is simply being uncovered by these kernel changes.https://gitlab.freedesktop.org/mesa/mesa/-/issues/9125kwin patch causes program using two gl windows to crash2023-12-02T21:22:18Zdeepthokwin patch causes program using two gl windows to crash### System information
```
System:
Host: streacom.mynet Kernel: 5.17.3-302.fc36.x86_64 arch: x86_64 bits: 64
compiler: gcc v: 2.37-24.fc36 Desktop: N/A wm: marco dm: LightDM
Distro: Fedora release 37 (Thirty Seven)
CPU:
Info...### System information
```
System:
Host: streacom.mynet Kernel: 5.17.3-302.fc36.x86_64 arch: x86_64 bits: 64
compiler: gcc v: 2.37-24.fc36 Desktop: N/A wm: marco dm: LightDM
Distro: Fedora release 37 (Thirty Seven)
CPU:
Info: quad core model: Intel Core i7-7700 bits: 64 type: MT MCP
arch: Kaby Lake rev: 9 cache: L1: 256 KiB L2: 1024 KiB L3: 8 MiB
Speed (MHz): avg: 1862 high: 3001 min/max: 800/4200 cores: 1: 3001
2: 1700 3: 1700 4: 1700 5: 1700 6: 1700 7: 1700 8: 1700 bogomips: 57600
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: Intel HD Graphics 630 vendor: ASUSTeK driver: i915 v: kernel
arch: Gen-9.5 ports: active: HDMI-A-2 empty: DP-1,HDMI-A-1 bus-ID: 00:02.0
chip-ID: 8086:5912
Display: x11 server: X.Org v: 1.20.14 compositor: marco v: 1.26.2 driver:
X: loaded: intel dri: i965 gpu: i915 display-ID: :99 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 16
Monitor-1: HDMI-A-2 mapped: default model: Philips FTV res: 1920x1080
diag: 734mm (28.9")
API: OpenGL v: N/A renderer: N/A direct-render: N/A
```
- OS: (`cat /etc/os-release | grep "NAME"`)
```
NAME="Fedora Linux"
VERSION_CODENAME=""
PRETTY_NAME="Fedora Linux 37 (Thirty Seven)"
CPE_NAME="cpe:/o:fedoraproject:fedora:37"
DEFAULT_HOSTNAME="fedora"
```
- GPU: (`lspci -nn | grep VGA` or `lshw -C display -numeric`)
```
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 [8086:5912] (rev 04)
```
- Kernel version: (run `uname -a`)
```
Linux streacom.mynet 5.17.3-302.fc36.x86_64 #1 SMP PREEMPT Sun Apr 17 13:22:18 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
```
- Mesa version: (`glxinfo -B | grep "OpenGL version string"`)
```
OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.0.3
```
- Xserver version (if applicable): (`sudo X -version`)
```
X.Org X Server 1.20.14
X Protocol Version 11, Revision 0
Build Operating System: 6.2.9-200.fc37.x86_64
Current Operating System: Linux daria.mynet 5.17.3-302.fc36.x86_64 #1 SMP PREEMPT Sun Apr 17 13:22:18 UTC 2022 x86_64
Kernel command line: root=zfs:zfs/fedora ro audit=0 spl.spl_hostid=0x33d16de6
Build Date: 25 April 2023 12:00:00AM
Build ID: xorg-x11-server 1.20.14-23.fc37
Current version of pixman: 0.40.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
```
### Describe the issue
I am the author of a complex program called neumodvb, which displays multiple mpv windows using opengl bindings.
All of this is called from wxwindows on top of gtk3.
Unfortunately in recent versions of fedora and ubuntu this has started crashing as soon as the 2nd mpv window is created.
I have tracked down the problem to mesa and by bisecting I have found that commit e13d53e1fdb8d7ae80901b66248e84ecc6dd9cfe
is the one which has created the crashes.
The reported error message is one like
```
python3: ../src/mesa/main/fbobject.c:3303: \_mesa_bind_framebuffers: Assertion \`newDrawFb' failed.
```
Reverting commit e13d53e1fdb8d7ae80901b66248e84ecc6dd9cfe on top of mesa 22.3.7 makes everything work again on fedora37
neumodvb is complex and it is not easy to make a simple standalone test case. Nevertheless, I hope a solution can be found
and I can test any patches for this problem.https://gitlab.freedesktop.org/mesa/mesa/-/issues/8954mesa 23.1.0-rc3 flickering textures/lighting in Unreal 4 games Polaris102024-01-13T05:03:55ZMike Houstonmesa 23.1.0-rc3 flickering textures/lighting in Unreal 4 games Polaris10AMD RX 570 Polaris10
Linux 6.3.0 (amdgpu)
Distro: Manjaro-Arch (customized)
X11 (not Wayland)
I got off the main branch at 23.1.0-rc2 and used that up until 22.1.0-rc3 was tagged, at which time I discovered flashing textures, surfaces, ...AMD RX 570 Polaris10
Linux 6.3.0 (amdgpu)
Distro: Manjaro-Arch (customized)
X11 (not Wayland)
I got off the main branch at 23.1.0-rc2 and used that up until 22.1.0-rc3 was tagged, at which time I discovered flashing textures, surfaces, and lighting in Unreal 4 games. It was most noticeable immediately on the main menu screen on Borderlands 3, and in game immediately with objects like vending machines. Also noticeable in the new Star Wars Jedi Survivor game, both in main menu and in game. Both of those DirectX 12 (I did not test any Unreal 4/DirectX 11 games)
Going back to my 23.1.0-rc2 build, it was back to normal. Unfortunate that so much time and so many commits to the main branch had occurred between my builds.
To identify what broke me, I switched to the main branch again, 23.2.0
I (sort of) bisected it, and definitively narrowed it down to this commit, for me.
commit d44651bf
radv: wait for occlusion queries in the resolve query shader
("one week ago" it said in the web interface...)
I then did "git revert d44651bf" and built, and the problem was again solved.
So then, against mesa-23.1.0-rc3, this fixes it for me. Tested with Borderlands 3 in menu and in game
```
--- mesa_orig/src/amd/vulkan/radv_query.c 2023-05-02 21:40:28.558408436 -0400
+++ mesa/src/amd/vulkan/radv_query.c 2023-05-02 21:57:53.019473703 -0400
@@ -139,31 +139,6 @@
nir_store_var(&b, outer_counter, nir_imm_int(&b, 0), 0x1);
nir_store_var(&b, available, nir_imm_true(&b), 0x1);
- nir_ssa_def *query_result_wait = nir_test_mask(&b, flags, VK_QUERY_RESULT_WAIT_BIT);
- nir_push_if(&b, query_result_wait);
- {
- /* Wait on the upper word of the last DB entry. */
- nir_push_loop(&b);
- {
- const uint32_t rb_avail_offset = 16 * util_last_bit64(enabled_rb_mask) - 4;
-
- /* Prevent the SSBO load to be moved out of the loop. */
- nir_scoped_memory_barrier(&b, NIR_SCOPE_INVOCATION, NIR_MEMORY_ACQUIRE, nir_var_mem_ssbo);
-
- nir_ssa_def *load_offset = nir_iadd_imm(&b, input_base, rb_avail_offset);
- nir_ssa_def *load = nir_load_ssbo(&b, 1, 32, src_buf, load_offset, .align_mul = 4,
- .access = ACCESS_COHERENT);
-
- nir_push_if(&b, nir_ige(&b, load, nir_imm_int(&b, 0x80000000)));
- {
- nir_jump(&b, nir_jump_break);
- }
- nir_pop_if(&b, NULL);
- }
- nir_pop_loop(&b, NULL);
- }
- nir_pop_if(&b, NULL);
-
nir_push_loop(&b);
nir_ssa_def *current_outer_count = nir_load_var(&b, outer_counter);
@@ -1566,6 +1541,19 @@
switch (pool->type) {
case VK_QUERY_TYPE_OCCLUSION:
+ if (flags & VK_QUERY_RESULT_WAIT_BIT) {
+ uint64_t enabled_rb_mask = cmd_buffer->device->physical_device->rad_info.enabled_rb_mask;
+ uint32_t rb_avail_offset = 16 * util_last_bit64(enabled_rb_mask) - 4;
+ for (unsigned i = 0; i < queryCount; ++i, dest_va += stride) {
+ unsigned query = firstQuery + i;
+ uint64_t src_va = va + query * pool->stride + rb_avail_offset;
+
+ radeon_check_space(cmd_buffer->device->ws, cs, 7);
+
+ /* Waits on the upper word of the last DB entry */
+ radv_cp_wait_mem(cs, WAIT_REG_MEM_GREATER_OR_EQUAL, src_va, 0x80000000, 0xffffffff);
+ }
+ }
radv_query_shader(cmd_buffer, &cmd_buffer->device->meta_state.query.occlusion_query_pipeline,
pool->bo, dst_buffer->bo, firstQuery * pool->stride,
dst_buffer->offset + dstOffset, pool->stride, stride, dst_size, queryCount,
```Samuel PitoisetSamuel Pitoisethttps://gitlab.freedesktop.org/mesa/mesa/-/issues/8946anv: Tom Clancy's Rainbow Six Siege [DX11: Image Corruption(FIXED)/Vulkan: cr...2023-07-06T21:44:05ZSopaDeMacaco-UmaDeliciaanv: Tom Clancy's Rainbow Six Siege [DX11: Image Corruption(FIXED)/Vulkan: crash on lauch]### System information
Please post `inxi -GSC -xx` output ([fenced with triple backticks](https://docs.gitlab.com/ee/user/markdown.html#code-spans-and-blocks)) OR fill information below manually
```
System:
Host: ArchLinux Kernel: 6....### System information
Please post `inxi -GSC -xx` output ([fenced with triple backticks](https://docs.gitlab.com/ee/user/markdown.html#code-spans-and-blocks)) OR fill information below manually
```
System:
Host: ArchLinux Kernel: 6.2.12-arch1-1.1 arch: x86_64 bits: 64
compiler: gcc v: 12.2.1 Desktop: KDE Plasma v: 5.27.4 tk: Qt v: 5.15.9
wm: kwin_wayland dm: N/A Distro: Arch Linux
CPU:
Info: 6-core model: AMD Ryzen 5 3600X bits: 64 type: MT MCP arch: Zen 2
rev: 0 cache: L1: 384 KiB L2: 3 MiB L3: 32 MiB
Speed (MHz): avg: 2555 high: 3800 min/max: 2200/4409 boost: enabled cores:
1: 3598 2: 2200 3: 2200 4: 2200 5: 2057 6: 2200 7: 3607 8: 2200 9: 2200
10: 2200 11: 2200 12: 3800 bogomips: 91244
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
Device-1: Intel DG2 [Arc A770] driver: i915 v: kernel arch: Gen-12.7 pcie:
speed: 2.5 GT/s lanes: 1 ports: active: DP-2 empty: DP-1, DP-3, DP-4,
HDMI-A-1, HDMI-A-2, HDMI-A-3 bus-ID: 2d:00.0 chip-ID: 8086:56a0
Display: wayland server: X.org v: 1.21.1.8 with: Xwayland v: 23.1.1
compositor: kwin_wayland driver: X: loaded: modesetting
alternate: fbdev,intel,vesa dri: iris gpu: i915 display-ID: 0
Monitor-1: DP-2 res: 1920x1080 size: N/A
API: OpenGL v: 4.6 Mesa 23.2.0-devel (git-bc8f7c53af) renderer: Mesa
Intel Arc A770 Graphics (DG2) direct-render: Yes
```
#### If applicable
- DXVK version: 2.1
- Wine/Proton version: 8.0
### Describe the issue
In Vulkan mode the game tries to make a black fullscreen and then crashes.
### Log files as attachment
Dmesg shows nothing, but here are proton logs.
[VULKANsteam-359550.log](/uploads/e5cb3aeb18d2116e4c48e4e151a967e9/VULKANsteam-359550.log)https://gitlab.freedesktop.org/mesa/mesa/-/issues/8809anv: Memory marked HOST_CACHED does not act cached2023-04-27T17:34:05ZEvan Tanganv: Memory marked HOST_CACHED does not act cached### System information
- OS: Fedora Linux 37 (KDE Plasma)
- GPU: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01)
- Kernel version: 6.2.8-200.fc37.x86_64
- Mesa version: 22.3.7
- Desktop manager and compositor:...### System information
- OS: Fedora Linux 37 (KDE Plasma)
- GPU: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01)
- Kernel version: 6.2.8-200.fc37.x86_64
- Mesa version: 22.3.7
- Desktop manager and compositor: KDE, kwin 5.27.3
### Describe the issue
To reproduce, run the following test program, which allocates memory of each HOST_VISIBLE type available, and times runs of memset, memcpy, and a bunch of volatile loads: [vkmemtest.zip](/uploads/06d9787f01d18da2f11a6c7b5cf140a4/vkmemtest.zip)
#### Expected result
Memory types with `VK_MEMORY_PROPERTY_HOST_CACHED_BIT` have similar read performance to a normal malloc buffer
#### Actual result
```
malloc memset: 104us
malloc memcpy: 191us
malloc load: 1063us
Intel(R) Xe Graphics (TGL GT2) memory 0 flags: DEVICE_LOCAL, HOST_VISIBLE, HOST_COHERENT, HOST_CACHED
Intel(R) Xe Graphics (TGL GT2) memory 0 memset: 84us
Intel(R) Xe Graphics (TGL GT2) memory 0 memcpy: 15853us
Intel(R) Xe Graphics (TGL GT2) memory 0 load: 505893us
llvmpipe (LLVM 15.0.7, 256 bits) memory 0 flags: DEVICE_LOCAL, HOST_VISIBLE, HOST_COHERENT, HOST_CACHED
llvmpipe (LLVM 15.0.7, 256 bits) memory 0 memset: 109us
llvmpipe (LLVM 15.0.7, 256 bits) memory 0 memcpy: 219us
llvmpipe (LLVM 15.0.7, 256 bits) memory 0 load: 1110us
```
For reference, here's the same test run on a steam deck. All memory marked `HOST_CACHED` has fast loads, while memory without the mark looks like the above Intel memory.
<details>
<summary>AMD Results</summary>
```
malloc memset: 373us
malloc memcpy: 272us
malloc load: 1217us
AMD Custom GPU 0405 (RADV VANGOGH) memory 2 flags: HOST_VISIBLE, HOST_COHERENT
AMD Custom GPU 0405 (RADV VANGOGH) memory 2 memset: 163us
AMD Custom GPU 0405 (RADV VANGOGH) memory 2 memcpy: 26622us
AMD Custom GPU 0405 (RADV VANGOGH) memory 2 load: 720550us
AMD Custom GPU 0405 (RADV VANGOGH) memory 3 flags: DEVICE_LOCAL, HOST_VISIBLE, HOST_COHERENT
AMD Custom GPU 0405 (RADV VANGOGH) memory 3 memset: 164us
AMD Custom GPU 0405 (RADV VANGOGH) memory 3 memcpy: 26758us
AMD Custom GPU 0405 (RADV VANGOGH) memory 3 load: 726533us
AMD Custom GPU 0405 (RADV VANGOGH) memory 4 flags: DEVICE_LOCAL, HOST_VISIBLE, HOST_COHERENT
AMD Custom GPU 0405 (RADV VANGOGH) memory 4 memset: 163us
AMD Custom GPU 0405 (RADV VANGOGH) memory 4 memcpy: 26735us
AMD Custom GPU 0405 (RADV VANGOGH) memory 4 load: 722475us
AMD Custom GPU 0405 (RADV VANGOGH) memory 5 flags: HOST_VISIBLE, HOST_COHERENT, HOST_CACHED
AMD Custom GPU 0405 (RADV VANGOGH) memory 5 memset: 361us
AMD Custom GPU 0405 (RADV VANGOGH) memory 5 memcpy: 202us
AMD Custom GPU 0405 (RADV VANGOGH) memory 5 load: 1207us
AMD Custom GPU 0405 (RADV VANGOGH) memory 6 flags: HOST_VISIBLE, HOST_COHERENT, HOST_CACHED
AMD Custom GPU 0405 (RADV VANGOGH) memory 6 memset: 426us
AMD Custom GPU 0405 (RADV VANGOGH) memory 6 memcpy: 334us
AMD Custom GPU 0405 (RADV VANGOGH) memory 6 load: 1198us
AMD Custom GPU 0405 (RADV VANGOGH) memory 8 flags: HOST_VISIBLE, HOST_COHERENT, DEVICE_COHERENT_AMD, DEVICE_UNCACHED_AMD
AMD Custom GPU 0405 (RADV VANGOGH) memory 8 memset: 164us
AMD Custom GPU 0405 (RADV VANGOGH) memory 8 memcpy: 26733us
AMD Custom GPU 0405 (RADV VANGOGH) memory 8 load: 724408us
AMD Custom GPU 0405 (RADV VANGOGH) memory 9 flags: DEVICE_LOCAL, HOST_VISIBLE, HOST_COHERENT, DEVICE_COHERENT_AMD, DEVICE_UNCACHED_AMD
AMD Custom GPU 0405 (RADV VANGOGH) memory 9 memset: 163us
AMD Custom GPU 0405 (RADV VANGOGH) memory 9 memcpy: 26936us
AMD Custom GPU 0405 (RADV VANGOGH) memory 9 load: 720116us
AMD Custom GPU 0405 (RADV VANGOGH) memory 10 flags: HOST_VISIBLE, HOST_COHERENT, HOST_CACHED, DEVICE_COHERENT_AMD, DEVICE_UNCACHED_AMD
AMD Custom GPU 0405 (RADV VANGOGH) memory 10 memset: 333us
AMD Custom GPU 0405 (RADV VANGOGH) memory 10 memcpy: 189us
AMD Custom GPU 0405 (RADV VANGOGH) memory 10 load: 1242us
```
</details>
### Regression
Yes, 582bf4d9f72f35bb56f06386ab3fb6b5384a4593
### Any extra information would be greatly appreciated
Associated dxvk issue: https://github.com/doitsujin/dxvk/issues/3340https://gitlab.freedesktop.org/mesa/mesa/-/issues/8763RADV preferred memory heap performance issues2023-07-24T10:19:40ZAdriano MartinsRADV preferred memory heap performance issues### Description
While this is not news, this issue is about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6833 behavior when vram//bandwidth limited and judging if its beneficial at all on such cases, otherwise its more of t...### Description
While this is not news, this issue is about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6833 behavior when vram//bandwidth limited and judging if its beneficial at all on such cases, otherwise its more of the same as #8107
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6833 description is not 100% accurate if you factor VRAM limited GPUs and overall performance, so i tested a couple of titles without it.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6833 is definitely more stable when RAM limited as it avoid crashes/freezes.
**EDIT**
The reason why I'm making this issue/list, its because most of these games are AAA games that are somewhat playable on Windows and runs exceptionally poorly on RADV when VRAM limited (even on high-end system, see issue 5902).
of course now 2GB and 4GB VRAM GPUs are obsolete but soon enough it will happen to RDNA1 and RDNA2 8GB GPUs, which are still very competitive with current gen gaming consoles.
**GAMES THAT RUN BETTER WITHOUT https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6833** (**4GB VRAM GPU / lowest settings**)
- **Stranger of Paradise Final Fantasy Origin** (game always uses +4gb of vram, from < 10FPS to 30~60)
- **Horizon Zero Dawn** (reduces long stutters)
- **The Last Of Us Part I** (from < 10FPS to ~30/40 FPS)
- **Returnal** (from < 20FPS to +60 FPS)
- **Alan Wake Remastered** (from < 20FPS to +60 FPS)
- **Sons of the Forest** (from < 20FPS to +40~60 FPS)
- **Marvel's Guardians of the Galaxy** (from < 20FPS to +40~60 FPS)
- **Star Wars Jedi: Fallen Order** (fixes massive slowdown when opening menus [dxvk](https://github.com/doitsujin/dxvk/issues/2552#issuecomment-1500457982))
**GAMES THAT BENEFIT FROM https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6833**
- **Metro Exodus Definitive Edition** (unplayable without it)
- **Dead Island 2** (unplayable without it)
**NO DIFFERENCE?**
- **F1 2022** doesn't seem to make any difference, it just slows down terribly when vram limited, AMDVLK works just fine here btw
### System information
- OS: EndeavourOS
- GPU: RX 6500 XT [1002:743f] (rev c1)- **PCI-E 3.0**
- Kernel version: 6.2.9
- Mesa version: Mesa 23.1.0-devel
- Desktop environment: KDE
#### If applicable
- Xserver version: 1.21.1.8
- DXVK version: 2.1
- VKD3D version: 2.8
- Wine/Proton version: Proton Experimental
**UPDATE**
Upgraded system to Ryzen 5 5600 + 16gb 3200mhz and now running under PCI-E 4.0.
While it did help reduce the issue at hand, it really doesn't make it go away.
it just delays more the inevitable performance chug when VRAM gets to +90% usage.