mesa issues
https://gitlab.freedesktop.org/mesa/mesa/-/issues
2024-03-13T15:54:10Z
https://gitlab.freedesktop.org/mesa/mesa/-/issues/10811
etnaviv glReadPixels hits slow paths
2024-03-13T15:54:10Z
Derek Foreman
etnaviv glReadPixels hits slow paths
weston (https://gitlab.freedesktop.org/wayland/weston) takes screenshots by asynchronous readback to a buffer object, as of https://gitlab.freedesktop.org/wayland/weston/-/commit/b9be532b27dd8ee38b531fa8ed40ad020a51ab43 (which is not at ...
weston (https://gitlab.freedesktop.org/wayland/weston) takes screenshots by asynchronous readback to a buffer object, as of https://gitlab.freedesktop.org/wayland/weston/-/commit/b9be532b27dd8ee38b531fa8ed40ad020a51ab43 (which is not at this time in a release)
This `glReadPixels()` takes a very pessimistic path in the etnaviv driver, involving a large number of `convert_ubyte` calls, taking hundreds of milliseconds.
My naive and incorrect fix for this in !28116 proposed enabling BLIT texture transfers, but that has disappointing side effects, breaking all of the CI.
To hit this slow path, using weston new enough to include this code hit mod-S to capture a screenshot, or launch `weston --debug` and run the `weston-screenshooter` client.
I'm seeing this on hardware with a GC7000 GPU.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/10535
etnaviv: glmark2 terrain exceeds maximum instructions on GC600 (i.MX8M Mini)
2024-02-01T07:15:38Z
Alexander Stein
etnaviv: glmark2 terrain exceeds maximum instructions on GC600 (i.MX8M Mini)
### System information
- OS:
```
NAME="Dumpling Wayland (TQ-Systems Dumpling Wayland Distribution)"
PRETTY_NAME="Dumpling Wayland (TQ-Systems Dumpling Wayland Distribution) 4.0.15 (kirkstone)"
DISTRO_CODENAME="kirkstone"
```
- GPU:
```...
### System information
- OS:
```
NAME="Dumpling Wayland (TQ-Systems Dumpling Wayland Distribution)"
PRETTY_NAME="Dumpling Wayland (TQ-Systems Dumpling Wayland Distribution) 4.0.15 (kirkstone)"
DISTRO_CODENAME="kirkstone"
```
- GPU:
```
dmesg|grep etnaviv-gpu
[ 1.525414] etnaviv-gpu 38000000.gpu: model: GC600, revision: 4653
[ 1.531707] etnaviv-gpu 38000000.gpu: Need to move linear window on MC1.0, disabling TS
[ 1.539745] etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
```
- Kernel version: `Linux tqma8-common 6.8.0-rc2-next-20240131+ #2229 SMP PREEMPT Wed Jan 31 10:59:48 CET 2024 aarch64 aarch64 aarch64 GNU/Linux`
- Mesa version: `OpenGL ES 2.0 Mesa 24.1.0-devel (git-6c570f7a98)`
- Desktop manager and compositor: `weston 10.0.2`
### Describe the issue
Running the `terrain` benchmark of glmark2 results in a failed shader compilation:
```
glmark2-es2-wayland -b terrain
=======================================================
glmark2 2023.01
=======================================================
OpenGL Information
GL_VENDOR: Mesa
GL_RENDERER: Vivante GC600 rev 4653
GL_VERSION: OpenGL ES 2.0 Mesa 24.1.0-devel (git-6c570f7a98)
Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
Surface Size: 800x600 windowed
=======================================================
MESA: error: etna_compile_check_limits:1044: Number of instructions (410) exceeds maximum 256
error: compile failed!
[terrain] <default>:MESA: error: etna_compile_check_limits:1044: Number of instructions (410) exceeds maximum 256
error: compile failed!
MESA: error: etna_draw_vbo:311: compiled shaders are not okay
MESA: error: etna_compile_check_limits:1044: Number of instructions (410) exceeds maximum 256
error: compile failed!
MESA: error: etna_draw_vbo:311: compiled shaders are not okay
MESA: error: etna_compile_check_limits:1044: Number of instructions (410) exceeds maximum 256
error: compile failed!
MESA: error: etna_draw_vbo:311: compiled shaders are not okay
MESA: error: etna_compile_check_limits:1044: Number of instructions (410) exceeds maximum 256
error: compile failed!
MESA: error: etna_draw_vbo:311: compiled shaders are not okay
MESA: error: etna_compile_check_limits:1044: Number of instructions (410) exceeds maximum 256
error: compile failed!
MESA: error: etna_draw_vbo:311: compiled shaders are not okay
^C FPS: 7 FrameTime: 147.385 ms
=======================================================
glmark2 Score: 6
=======================================================
```
### Log files as attachment
- Nothing is printed to dmesg
### Any extra information would be greatly appreciated
<details><summary>GPU features from /sys/kernel/debug/dri/etnaviv/gpu</summary>
```
$ cat /sys/kernel/debug/dri/etnaviv/gpu
38000000.gpu Status:
identity
model: 0x600
revision: 0x4653
product_id: 0x70005
customer_id: 0x102
eco_id: 0x0
features
major_features: 0xa0e9e4ac
minor_features0: 0xe1299fff
minor_features1: 0xbe13b219
minor_features2: 0xca110010
minor_features3: 0x08000001
minor_features4: 0x00020102
minor_features5: 0x00020000
minor_features6: 0x00000000
minor_features7: 0x00000000
minor_features8: 0x00000000
minor_features9: 0x00000000
minor_features10: 0x00000000
minor_features11: 0x00000000
specs
stream_count: 4
register_max: 64
thread_count: 256
vertex_cache_size: 8
shader_core_count: 1
nn_core_count: 0
pixel_pipes: 1
vertex_output_buffer_size: 512
buffer_size: 0
instruction_count: 256
num_constants: 320
varyings_count: 8
axi: 0x00000000
idle: 0x7fffffff
DMA seems to be stuck
address 0: 0xc8baf7d8
address 1: 0xc8baf7d8
state 0: 0x00000000
state 1: 0x00000000
last fetch 64 bit word: 0x9d9ffeff 0xc9cf2579
38008000.gpu Status:
identity
model: 0x520
revision: 0x5341
product_id: 0x5202
customer_id: 0x0
eco_id: 0x0
features
major_features: 0xe02c7eca
minor_features0: 0xe9399eff
minor_features1: 0xfe1fb2db
minor_features2: 0xceff0080
minor_features3: 0x10000005
minor_features4: 0x00000000
minor_features5: 0x00020000
minor_features6: 0x00000000
minor_features7: 0x00000000
minor_features8: 0x00000000
minor_features9: 0x00000000
minor_features10: 0x00000000
minor_features11: 0x00000000
specs
stream_count: 1
register_max: 64
thread_count: 256
vertex_cache_size: 8
shader_core_count: 1
nn_core_count: 0
pixel_pipes: 1
vertex_output_buffer_size: 512
buffer_size: 0
instruction_count: 256
num_constants: 168
varyings_count: 8
axi: 0x000000fd
idle: 0x7fffffff
DMA seems to be stuck
address 0: 0xccf7dc88
address 1: 0xccf7dc88
state 0: 0x00000000
state 1: 0x00000000
last fetch 64 bit word: 0x97176fa8 0xf0e7fd0f
```
</details>
<details><summary>Dumped shader</summary>
```
ETNA_MESA_DEBUG=dump_shaders glmark2-es2-wayland -b terrain
=======================================================
glmark2 2023.01
=======================================================
OpenGL Information
GL_VENDOR: Mesa
GL_RENDERER: Vivante GC600 rev 4653
GL_VERSION: OpenGL ES 2.0 Mesa 24.1.0-devel (git-6c570f7a98)
Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
Surface Size: 800x600 windowed
=======================================================
shader: MESA_SHADER_FRAGMENT
source_sha1: {0x0c1897fa, 0x6afb3506, 0xfefc58fd, 0xbc53ee22, 0x7f305cd4}
name: GLSL1
internal: false
stage: 4
next_stage: 4
inputs_read: 32
outputs_written: 2
subgroup_size: 1
bit_sizes_float: 0x20
bit_sizes_int: 0x21
flrp_lowered: true
inputs: 1
outputs: 1
uniforms: 2
decl_var uniform INTERP_MODE_NONE none mediump float time (2, 0, 0)
decl_var uniform INTERP_MODE_NONE none mediump vec2 uvScale (1, 1, 0)
decl_var shader_in INTERP_MODE_NONE none mediump vec2 packed:vUv (VARYING_SLOT_VAR0.xy, 0, 0)
decl_var shader_out INTERP_MODE_NONE none mediump vec4 gl_FragColor (FRAG_RESULT_COLOR.xyzw, 0, 0)
decl_function main (0 params)
impl main {
block b0: // preds:
32 %0 = load_const (0x00000000 = 0.000000)
32x2 %1 = @load_input (%0 (0x0)) (base=0, range=1, component=0, dest_type=float32, io location=VARYING_SLOT_VAR0 slots=1 mediump) // packed:vUv
32 %2 = load_const (0x3f800000 = 1.000000)
32x2 %3 = @load_uniform (%0 (0x0)) (base=1, range=1, dest_type=float32) // uvScale
32 %5 = fadd %3.y, %1.y
32 %6 = @load_uniform (%0 (0x0)) (base=0, range=1, dest_type=float32) // time
32 %7 = fneg %6
32 %8 = load_const (0x40000000 = 2.000000)
32 %9 = load_const (0x3f000000 = 0.500000)
32 %10 = load_const (0x40800000 = 4.000000)
32 %11 = load_const (0x3e800000 = 0.250000)
32 %12 = load_const (0x41000000 = 8.000000)
32 %13 = load_const (0x3e000000 = 0.125000)
32 %14 = load_const (0x3eaaaaab = 0.333333)
32 %15 = load_const (0x3e2aaaab = 0.166667)
32 %16 = load_const (0x43908000 = 289.000000)
32x2 %17 = load_const (0x00000000, 0x3f800000) = (0.000000, 1.000000)
32 %18 = load_const (0x40e00000 = 7.000000)
32 %19 = load_const (0x42440000 = 49.000000)
32 %20 = load_const (0x3f19999a = 0.600000)
32 %21 = load_const (0x42280000 = 42.000000)
32x3 %22 = vec3 %1.x, %5, %7
32 %23 = fdot3 %22, %14 (0.333333).xxx
32x3 %24 = fadd %22, %23.xxx
32x3 %25 = ffloor %24
32x3 %27 = fadd %22, %25
32 %28 = fdot3 %25, %15 (0.166667).xxx
32x3 %29 = fadd %27, %28.xxx
32x3 %610 = sge %29, %29.yzx
32x3 %38 = fadd %2 (1.000000).xxx, %610
32x3 %39 = fmin %610, %38.zxy
32x3 %40 = fmax %610, %38.zxy
32x3 %42 = fadd %29, %39
32x3 %43 = fadd %42, %15 (0.166667).xxx
32x3 %45 = fadd %29, %40
32x3 %46 = fadd %45, %14 (0.333333).xxx
32 %47 = load_const (0xbf000000 = -0.500000)
32x3 %48 = fadd %47 (-0.500000).xxx, %29
32 %49 = load_const (0x3b62c4a7 = 0.003460)
32x3 %50 = fmul %25, %49 (0.003460).xxx
32x3 %51 = ffloor %50
32x3 %731 = ffma %16 (289.000000).xxx, %51, %25
32x4 %55 = vec4 %17 (0x0, 0x3f800000).x, %39.z, %40.z, %17 (0x0, 0x3f800000).y
32x4 %56 = fadd %731.zzzz, %55
32 %57 = load_const (0x42080000 = 34.000000)
32x4 %729 = ffma %56, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %60 = fmul %729, %56
32x4 %61 = fmul %60, %49 (0.003460).xxxx
32x4 %62 = ffloor %61
32x4 %65 = fadd %60, %731.yyyy
32x4 %728 = ffma %16 (289.000000).xxxx, %62, %65
32x4 %67 = vec4 %17 (0x0, 0x3f800000).x, %39.y, %40.y, %17 (0x0, 0x3f800000).y
32x4 %68 = fadd %728, %67
32x4 %726 = ffma %68, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %71 = fmul %726, %68
32x4 %72 = fmul %71, %49 (0.003460).xxxx
32x4 %73 = ffloor %72
32x4 %76 = fadd %71, %731.xxxx
32x4 %725 = ffma %16 (289.000000).xxxx, %73, %76
32x4 %78 = vec4 %17 (0x0, 0x3f800000).x, %39.x, %40.x, %17 (0x0, 0x3f800000).y
32x4 %79 = fadd %725, %78
32x4 %723 = ffma %79, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %82 = fmul %723, %79
32x4 %83 = fmul %82, %49 (0.003460).xxxx
32x4 %84 = ffloor %83
32x4 %722 = ffma %16 (289.000000).xxxx, %84, %82
32x3 %88 = load_const (0x3e924925, 0xbf6db6db, 0x3e124925) = (0.285714, -0.928571, 0.142857)
32 %89 = load_const (0x3ca72f06 = 0.020408)
32x4 %90 = fmul %89 (0.020408).xxxx, %722
32x4 %91 = ffloor %90
32x4 %720 = ffma %19 (49.000000).xxxx, %91, %722
32x4 %95 = fmul %720, %88 (0.285714, -0.928571, 0.142857).zzzz
32x4 %96 = ffloor %95
32x4 %718 = ffma %96, %88 (0.285714, -0.928571, 0.142857).xxxx, %88 (0.285714, -0.928571, 0.142857).yyyy
32x4 %717 = ffma %18 (7.000000).xxxx, %96, %720
32x4 %102 = ffloor %717
32x4 %715 = ffma %102, %88 (0.285714, -0.928571, 0.142857).xxxx, %88 (0.285714, -0.928571, 0.142857).yyyy
32x4 %107 = fadd %2 (1.000000).xxxx, %718
32x4 %110 = fadd %107, %715
32x4 %613 = sge %0 (0.000000).xxxx, %110
32x4 %121 = vec4 %718.x, %718.y, %715.x, %715.y
32x4 %122 = ffloor %121
32x4 %714 = ffma %122, %8 (2.000000).xxxx, %2 (1.000000).xxxx
32x4 %713 = ffma %613.xxyy, %714.xzyw, %121.xzyw
32x4 %129 = vec4 %718.z, %718.w, %715.z, %715.w
32x4 %130 = ffloor %129
32x4 %711 = ffma %130, %8 (2.000000).xxxx, %2 (1.000000).xxxx
32x4 %710 = ffma %613.zzww, %711.xzyw, %129.xzyw
32x3 %136 = vec3 %713.x, %713.y, %110.x
32 %137 = fdot3 %136, %136
32x3 %138 = vec3 %713.z, %713.w, %110.y
32 %139 = fdot3 %138, %138
32x3 %140 = vec3 %710.x, %710.y, %110.z
32 %141 = fdot3 %140, %140
32x3 %142 = vec3 %710.z, %710.w, %110.w
32 %143 = fdot3 %142, %142
32 %144 = load_const (0x3fe57be0 = 1.792843)
32 %145 = load_const (0x3f5a8e5c = 0.853735)
32x4 %146 = vec4 %137, %139, %141, %143
32x4 %708 = ffma %145 (0.853735).xxxx, %146, %144 (1.792843).xxxx
32x3 %150 = fmul %136, %708.xxx
32x3 %151 = fmul %138, %708.yyy
32x3 %152 = fmul %140, %708.zzz
32x3 %153 = fmul %142, %708.www
32 %154 = fdot3 %29, %29
32 %155 = fdot3 %43, %43
32 %156 = fdot3 %46, %46
32 %157 = fdot3 %48, %48
32x4 %158 = vec4 %154, %155, %156, %157
32x4 %160 = fadd %20 (0.600000).xxxx, %158
32x4 %161 = fmax %160, %0 (0.000000).xxxx
32x4 %162 = fmul %161, %161
32 %163 = fdot3 %150, %29
32 %164 = fdot3 %151, %43
32 %165 = fdot3 %152, %46
32 %166 = fdot3 %153, %48
32x4 %167 = fmul %162, %162
32x4 %168 = vec4 %163, %164, %165, %166
32 %169 = fdot4 %167, %168
32 %170 = fmul %21 (42.000000), %169
32x3 %172 = fmul %22, %8 (2.000000).xxx
32 %173 = fdot3 %172, %14 (0.333333).xxx
32x3 %174 = fadd %172, %173.xxx
32x3 %175 = ffloor %174
32x3 %177 = fadd %172, %175
32 %178 = fdot3 %175, %15 (0.166667).xxx
32x3 %179 = fadd %177, %178.xxx
32x3 %615 = sge %179, %179.yzx
32x3 %188 = fadd %2 (1.000000).xxx, %615
32x3 %189 = fmin %615, %188.zxy
32x3 %190 = fmax %615, %188.zxy
32x3 %192 = fadd %179, %189
32x3 %193 = fadd %192, %15 (0.166667).xxx
32x3 %195 = fadd %179, %190
32x3 %196 = fadd %195, %14 (0.333333).xxx
32x3 %197 = fadd %47 (-0.500000).xxx, %179
32x3 %198 = fmul %175, %49 (0.003460).xxx
32x3 %199 = ffloor %198
32x3 %706 = ffma %16 (289.000000).xxx, %199, %175
32x4 %203 = vec4 %17 (0x0, 0x3f800000).x, %189.z, %190.z, %17 (0x0, 0x3f800000).y
32x4 %204 = fadd %706.zzzz, %203
32x4 %704 = ffma %204, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %207 = fmul %704, %204
32x4 %208 = fmul %207, %49 (0.003460).xxxx
32x4 %209 = ffloor %208
32x4 %212 = fadd %207, %706.yyyy
32x4 %703 = ffma %16 (289.000000).xxxx, %209, %212
32x4 %214 = vec4 %17 (0x0, 0x3f800000).x, %189.y, %190.y, %17 (0x0, 0x3f800000).y
32x4 %215 = fadd %703, %214
32x4 %701 = ffma %215, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %218 = fmul %701, %215
32x4 %219 = fmul %218, %49 (0.003460).xxxx
32x4 %220 = ffloor %219
32x4 %223 = fadd %218, %706.xxxx
32x4 %700 = ffma %16 (289.000000).xxxx, %220, %223
32x4 %225 = vec4 %17 (0x0, 0x3f800000).x, %189.x, %190.x, %17 (0x0, 0x3f800000).y
32x4 %226 = fadd %700, %225
32x4 %698 = ffma %226, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %229 = fmul %698, %226
32x4 %230 = fmul %229, %49 (0.003460).xxxx
32x4 %231 = ffloor %230
32x4 %697 = ffma %16 (289.000000).xxxx, %231, %229
32x4 %235 = fmul %89 (0.020408).xxxx, %697
32x4 %236 = ffloor %235
32x4 %695 = ffma %19 (49.000000).xxxx, %236, %697
32x4 %240 = fmul %695, %88 (0.285714, -0.928571, 0.142857).zzzz
32x4 %241 = ffloor %240
32x4 %693 = ffma %241, %88 (0.285714, -0.928571, 0.142857).xxxx, %88 (0.285714, -0.928571, 0.142857).yyyy
32x4 %692 = ffma %18 (7.000000).xxxx, %241, %695
32x4 %247 = ffloor %692
32x4 %690 = ffma %247, %88 (0.285714, -0.928571, 0.142857).xxxx, %88 (0.285714, -0.928571, 0.142857).yyyy
32x4 %252 = fadd %2 (1.000000).xxxx, %693
32x4 %255 = fadd %252, %690
32x4 %618 = sge %0 (0.000000).xxxx, %255
32x4 %266 = vec4 %693.x, %693.y, %690.x, %690.y
32x4 %267 = ffloor %266
32x4 %689 = ffma %267, %8 (2.000000).xxxx, %2 (1.000000).xxxx
32x4 %688 = ffma %618.xxyy, %689.xzyw, %266.xzyw
32x4 %274 = vec4 %693.z, %693.w, %690.z, %690.w
32x4 %275 = ffloor %274
32x4 %686 = ffma %275, %8 (2.000000).xxxx, %2 (1.000000).xxxx
32x4 %685 = ffma %618.zzww, %686.xzyw, %274.xzyw
32x3 %281 = vec3 %688.x, %688.y, %255.x
32 %282 = fdot3 %281, %281
32x3 %283 = vec3 %688.z, %688.w, %255.y
32 %284 = fdot3 %283, %283
32x3 %285 = vec3 %685.x, %685.y, %255.z
32 %286 = fdot3 %285, %285
32x3 %287 = vec3 %685.z, %685.w, %255.w
32 %288 = fdot3 %287, %287
32x4 %289 = vec4 %282, %284, %286, %288
32x4 %683 = ffma %145 (0.853735).xxxx, %289, %144 (1.792843).xxxx
32x3 %293 = fmul %281, %683.xxx
32x3 %294 = fmul %283, %683.yyy
32x3 %295 = fmul %285, %683.zzz
32x3 %296 = fmul %287, %683.www
32 %297 = fdot3 %179, %179
32 %298 = fdot3 %193, %193
32 %299 = fdot3 %196, %196
32 %300 = fdot3 %197, %197
32x4 %301 = vec4 %297, %298, %299, %300
32x4 %303 = fadd %20 (0.600000).xxxx, %301
32x4 %304 = fmax %303, %0 (0.000000).xxxx
32x4 %305 = fmul %304, %304
32 %306 = fdot3 %293, %179
32 %307 = fdot3 %294, %193
32 %308 = fdot3 %295, %196
32 %309 = fdot3 %296, %197
32x4 %310 = fmul %305, %305
32x4 %311 = vec4 %306, %307, %308, %309
32 %312 = fdot4 %310, %311
32 %313 = fmul %21 (42.000000), %312
32 %681 = ffma %9 (0.500000), %313, %170
32x3 %317 = fmul %22, %10 (4.000000).xxx
32 %318 = fdot3 %317, %14 (0.333333).xxx
32x3 %319 = fadd %317, %318.xxx
32x3 %320 = ffloor %319
32x3 %322 = fadd %317, %320
32 %323 = fdot3 %320, %15 (0.166667).xxx
32x3 %324 = fadd %322, %323.xxx
32x3 %620 = sge %324, %324.yzx
32x3 %333 = fadd %2 (1.000000).xxx, %620
32x3 %334 = fmin %620, %333.zxy
32x3 %335 = fmax %620, %333.zxy
32x3 %337 = fadd %324, %334
32x3 %338 = fadd %337, %15 (0.166667).xxx
32x3 %340 = fadd %324, %335
32x3 %341 = fadd %340, %14 (0.333333).xxx
32x3 %342 = fadd %47 (-0.500000).xxx, %324
32x3 %343 = fmul %320, %49 (0.003460).xxx
32x3 %344 = ffloor %343
32x3 %680 = ffma %16 (289.000000).xxx, %344, %320
32x4 %348 = vec4 %17 (0x0, 0x3f800000).x, %334.z, %335.z, %17 (0x0, 0x3f800000).y
32x4 %349 = fadd %680.zzzz, %348
32x4 %678 = ffma %349, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %352 = fmul %678, %349
32x4 %353 = fmul %352, %49 (0.003460).xxxx
32x4 %354 = ffloor %353
32x4 %357 = fadd %352, %680.yyyy
32x4 %677 = ffma %16 (289.000000).xxxx, %354, %357
32x4 %359 = vec4 %17 (0x0, 0x3f800000).x, %334.y, %335.y, %17 (0x0, 0x3f800000).y
32x4 %360 = fadd %677, %359
32x4 %675 = ffma %360, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %363 = fmul %675, %360
32x4 %364 = fmul %363, %49 (0.003460).xxxx
32x4 %365 = ffloor %364
32x4 %368 = fadd %363, %680.xxxx
32x4 %674 = ffma %16 (289.000000).xxxx, %365, %368
32x4 %370 = vec4 %17 (0x0, 0x3f800000).x, %334.x, %335.x, %17 (0x0, 0x3f800000).y
32x4 %371 = fadd %674, %370
32x4 %672 = ffma %371, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %374 = fmul %672, %371
32x4 %375 = fmul %374, %49 (0.003460).xxxx
32x4 %376 = ffloor %375
32x4 %671 = ffma %16 (289.000000).xxxx, %376, %374
32x4 %380 = fmul %89 (0.020408).xxxx, %671
32x4 %381 = ffloor %380
32x4 %669 = ffma %19 (49.000000).xxxx, %381, %671
32x4 %385 = fmul %669, %88 (0.285714, -0.928571, 0.142857).zzzz
32x4 %386 = ffloor %385
32x4 %667 = ffma %386, %88 (0.285714, -0.928571, 0.142857).xxxx, %88 (0.285714, -0.928571, 0.142857).yyyy
32x4 %666 = ffma %18 (7.000000).xxxx, %386, %669
32x4 %392 = ffloor %666
32x4 %664 = ffma %392, %88 (0.285714, -0.928571, 0.142857).xxxx, %88 (0.285714, -0.928571, 0.142857).yyyy
32x4 %397 = fadd %2 (1.000000).xxxx, %667
32x4 %400 = fadd %397, %664
32x4 %623 = sge %0 (0.000000).xxxx, %400
32x4 %411 = vec4 %667.x, %667.y, %664.x, %664.y
32x4 %412 = ffloor %411
32x4 %663 = ffma %412, %8 (2.000000).xxxx, %2 (1.000000).xxxx
32x4 %662 = ffma %623.xxyy, %663.xzyw, %411.xzyw
32x4 %419 = vec4 %667.z, %667.w, %664.z, %664.w
32x4 %420 = ffloor %419
32x4 %660 = ffma %420, %8 (2.000000).xxxx, %2 (1.000000).xxxx
32x4 %659 = ffma %623.zzww, %660.xzyw, %419.xzyw
32x3 %426 = vec3 %662.x, %662.y, %400.x
32 %427 = fdot3 %426, %426
32x3 %428 = vec3 %662.z, %662.w, %400.y
32 %429 = fdot3 %428, %428
32x3 %430 = vec3 %659.x, %659.y, %400.z
32 %431 = fdot3 %430, %430
32x3 %432 = vec3 %659.z, %659.w, %400.w
32 %433 = fdot3 %432, %432
32x4 %434 = vec4 %427, %429, %431, %433
32x4 %657 = ffma %145 (0.853735).xxxx, %434, %144 (1.792843).xxxx
32x3 %438 = fmul %426, %657.xxx
32x3 %439 = fmul %428, %657.yyy
32x3 %440 = fmul %430, %657.zzz
32x3 %441 = fmul %432, %657.www
32 %442 = fdot3 %324, %324
32 %443 = fdot3 %338, %338
32 %444 = fdot3 %341, %341
32 %445 = fdot3 %342, %342
32x4 %446 = vec4 %442, %443, %444, %445
32x4 %448 = fadd %20 (0.600000).xxxx, %446
32x4 %449 = fmax %448, %0 (0.000000).xxxx
32x4 %450 = fmul %449, %449
32 %451 = fdot3 %438, %324
32 %452 = fdot3 %439, %338
32 %453 = fdot3 %440, %341
32 %454 = fdot3 %441, %342
32x4 %455 = fmul %450, %450
32x4 %456 = vec4 %451, %452, %453, %454
32 %457 = fdot4 %455, %456
32 %458 = fmul %21 (42.000000), %457
32 %655 = ffma %11 (0.250000), %458, %681
32x3 %462 = fmul %22, %12 (8.000000).xxx
32 %463 = fdot3 %462, %14 (0.333333).xxx
32x3 %464 = fadd %462, %463.xxx
32x3 %465 = ffloor %464
32x3 %467 = fadd %462, %465
32 %468 = fdot3 %465, %15 (0.166667).xxx
32x3 %469 = fadd %467, %468.xxx
32x3 %625 = sge %469, %469.yzx
32x3 %478 = fadd %2 (1.000000).xxx, %625
32x3 %479 = fmin %625, %478.zxy
32x3 %480 = fmax %625, %478.zxy
32x3 %482 = fadd %469, %479
32x3 %483 = fadd %482, %15 (0.166667).xxx
32x3 %485 = fadd %469, %480
32x3 %486 = fadd %485, %14 (0.333333).xxx
32x3 %487 = fadd %47 (-0.500000).xxx, %469
32x3 %488 = fmul %465, %49 (0.003460).xxx
32x3 %489 = ffloor %488
32x3 %654 = ffma %16 (289.000000).xxx, %489, %465
32x4 %493 = vec4 %17 (0x0, 0x3f800000).x, %479.z, %480.z, %17 (0x0, 0x3f800000).y
32x4 %494 = fadd %654.zzzz, %493
32x4 %652 = ffma %494, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %497 = fmul %652, %494
32x4 %498 = fmul %497, %49 (0.003460).xxxx
32x4 %499 = ffloor %498
32x4 %502 = fadd %497, %654.yyyy
32x4 %651 = ffma %16 (289.000000).xxxx, %499, %502
32x4 %504 = vec4 %17 (0x0, 0x3f800000).x, %479.y, %480.y, %17 (0x0, 0x3f800000).y
32x4 %505 = fadd %651, %504
32x4 %649 = ffma %505, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %508 = fmul %649, %505
32x4 %509 = fmul %508, %49 (0.003460).xxxx
32x4 %510 = ffloor %509
32x4 %513 = fadd %508, %654.xxxx
32x4 %648 = ffma %16 (289.000000).xxxx, %510, %513
32x4 %515 = vec4 %17 (0x0, 0x3f800000).x, %479.x, %480.x, %17 (0x0, 0x3f800000).y
32x4 %516 = fadd %648, %515
32x4 %646 = ffma %516, %57 (34.000000).xxxx, %2 (1.000000).xxxx
32x4 %519 = fmul %646, %516
32x4 %520 = fmul %519, %49 (0.003460).xxxx
32x4 %521 = ffloor %520
32x4 %645 = ffma %16 (289.000000).xxxx, %521, %519
32x4 %525 = fmul %89 (0.020408).xxxx, %645
32x4 %526 = ffloor %525
32x4 %643 = ffma %19 (49.000000).xxxx, %526, %645
32x4 %530 = fmul %643, %88 (0.285714, -0.928571, 0.142857).zzzz
32x4 %531 = ffloor %530
32x4 %641 = ffma %531, %88 (0.285714, -0.928571, 0.142857).xxxx, %88 (0.285714, -0.928571, 0.142857).yyyy
32x4 %640 = ffma %18 (7.000000).xxxx, %531, %643
32x4 %537 = ffloor %640
32x4 %638 = ffma %537, %88 (0.285714, -0.928571, 0.142857).xxxx, %88 (0.285714, -0.928571, 0.142857).yyyy
32x4 %542 = fadd %2 (1.000000).xxxx, %641
32x4 %545 = fadd %542, %638
32x4 %628 = sge %0 (0.000000).xxxx, %545
32x4 %556 = vec4 %641.x, %641.y, %638.x, %638.y
32x4 %557 = ffloor %556
32x4 %637 = ffma %557, %8 (2.000000).xxxx, %2 (1.000000).xxxx
32x4 %636 = ffma %628.xxyy, %637.xzyw, %556.xzyw
32x4 %564 = vec4 %641.z, %641.w, %638.z, %638.w
32x4 %565 = ffloor %564
32x4 %634 = ffma %565, %8 (2.000000).xxxx, %2 (1.000000).xxxx
32x4 %633 = ffma %628.zzww, %634.xzyw, %564.xzyw
32x3 %571 = vec3 %636.x, %636.y, %545.x
32 %572 = fdot3 %571, %571
32x3 %573 = vec3 %636.z, %636.w, %545.y
32 %574 = fdot3 %573, %573
32x3 %575 = vec3 %633.x, %633.y, %545.z
32 %576 = fdot3 %575, %575
32x3 %577 = vec3 %633.z, %633.w, %545.w
32 %578 = fdot3 %577, %577
32x4 %579 = vec4 %572, %574, %576, %578
32x4 %631 = ffma %145 (0.853735).xxxx, %579, %144 (1.792843).xxxx
32x3 %583 = fmul %571, %631.xxx
32x3 %584 = fmul %573, %631.yyy
32x3 %585 = fmul %575, %631.zzz
32x3 %586 = fmul %577, %631.www
32 %587 = fdot3 %469, %469
32 %588 = fdot3 %483, %483
32 %589 = fdot3 %486, %486
32 %590 = fdot3 %487, %487
32x4 %591 = vec4 %587, %588, %589, %590
32x4 %593 = fadd %20 (0.600000).xxxx, %591
32x4 %594 = fmax %593, %0 (0.000000).xxxx
32x4 %595 = fmul %594, %594
32 %596 = fdot3 %583, %469
32 %597 = fdot3 %584, %483
32 %598 = fdot3 %585, %486
32 %599 = fdot3 %586, %487
32x4 %600 = fmul %595, %595
32x4 %601 = vec4 %596, %597, %598, %599
32 %602 = fdot4 %600, %601
32 %603 = fmul %21 (42.000000), %602
32 %629 = ffma %13 (0.125000), %603, %655
32 %607 = deref_var &gl_FragColor (shader_out vec4)
32x4 %608 = vec4 %629, %629, %629, %2 (0x3f800000)
@store_deref (%607, %608) (wrmask=xyzw, access=none)
// succs: b1
block b1:
}
```
</details>
https://gitlab.freedesktop.org/mesa/mesa/-/issues/10072
[CI] all drivers need to review & trim their post-merge jobs
2023-12-07T08:25:23Z
Eric Engestrom
eric@engestrom.ch
[CI] all drivers need to review & trim their post-merge jobs
Have a look at the jobs in the post-merge pipelines: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines?ref=main&source=push
A lot of these are repeats of what Marge already runs pre-merge, and are therefore using up resources for no ...
Have a look at the jobs in the post-merge pipelines: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines?ref=main&source=push
A lot of these are repeats of what Marge already runs pre-merge, and are therefore using up resources for no reason.
Tagging all drivers; please untag yourself once you have gone through and removed everything that doesn't need to be there.
Have a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25960 for how to remove redundant tests from post-marge-merge.
Feel free to ask for help here if you can't figure out how to modify your job.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/10007
etnaviv: gc2000 gles2 regression
2023-10-20T13:06:23Z
Emma Anholt
emma@anholt.net
etnaviv: gc2000 gles2 regression
In 843f2eb3c8effa955d8e1da04696ec11b18b7c5a..35ae5dce, so probably !25751, we're now getting failures in gles2:
```
23-10-18 14:51:51 R SERIAL> ERROR - dEQP error: u_blitter:611: Caught recursion. This is a driver bug.
[...]
23-10-18 14...
In 843f2eb3c8effa955d8e1da04696ec11b18b7c5a..35ae5dce, so probably !25751, we're now getting failures in gles2:
```
23-10-18 14:51:51 R SERIAL> ERROR - dEQP error: u_blitter:611: Caught recursion. This is a driver bug.
[...]
23-10-18 14:57:04 R SERIAL> dEQP-GLES2.functional.texture.size.2d.64x64_rgba4444_mipmap,Fail
23-10-18 14:57:04 R SERIAL> dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.2d_rgb,Crash
23-10-18 14:57:04 R SERIAL> dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.2d_rgba,Crash
23-10-18 14:57:04 R SERIAL> dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.cube_rgb,Crash
23-10-18 14:57:04 R SERIAL> dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.cube_rgba,Crash
```
https://gitlab.freedesktop.org/mesa/mesa/-/issues/9967
etnaviv gc2000_gles2_asan job pass zero tests
2023-10-11T11:31:21Z
Erik Faye-Lund
kusmabite@gmail.com
etnaviv gc2000_gles2_asan job pass zero tests
See this job: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/50092433
It seems like some memleaks ends up causing *all* tests to fail on the gc2000_gles2_asan job. This has been failing every single nightly on the CI for a long, long t...
See this job: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/50092433
It seems like some memleaks ends up causing *all* tests to fail on the gc2000_gles2_asan job. This has been failing every single nightly on the CI for a long, long time.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/9811
OPENGL SPEC CHANGE: gl_Layer and gl_ViewportIndex behavior
2024-03-22T14:15:44Z
Mike Blumenkrantz
OPENGL SPEC CHANGE: gl_Layer and gl_ViewportIndex behavior
I'm not sure which drivers this may affect, so here's a ticket for everyone to examine. As of the WG call yesterday, I managed to push through a decision regarding out-of-range behavior with gl_Layer+gl_ViewportIndex: out-of-range should...
I'm not sure which drivers this may affect, so here's a ticket for everyone to examine. As of the WG call yesterday, I managed to push through a decision regarding out-of-range behavior with gl_Layer+gl_ViewportIndex: out-of-range should be considered undefined, and any spec language requiring out-of-range values to be preserved was a description of nvidia hardware behavior and not an intended requirement.
While it's no longer WG policy to issue spec updates for non-core extensions, I've made https://github.com/KhronosGroup/OpenGL-Registry/pull/587 for posterity.
In short, if you have extra hacks/workarounds in your driver to preserve out-of-range values on these builtins, you can now delete them, as the [tests which verify out-of-range preservation](https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/839) have also been deleted.
I'll close this ticket in a couple weeks (or once there's no further activity).
https://gitlab.freedesktop.org/mesa/mesa/-/issues/9694
Unable to free CMA memory used via BO created SCANOUT flag if it was mapped w...
2023-12-12T14:44:07Z
Rainier Lamers
Unable to free CMA memory used via BO created SCANOUT flag if it was mapped with GBM_BO_MAP
- OS: ARM32 Linux 5.7.10 on STM32MP157 using Buildroot
- GPU: Vivante GC400
- Kernel version: 5.7.10
- Mesa version: 23.1.4
- Desktop manager and compositor: None - straight OpenGL ES2 similar to and inspired by kmscube
### Describe th...
- OS: ARM32 Linux 5.7.10 on STM32MP157 using Buildroot
- GPU: Vivante GC400
- Kernel version: 5.7.10
- Mesa version: 23.1.4
- Desktop manager and compositor: None - straight OpenGL ES2 similar to and inspired by kmscube
### Describe the issue
After a typical creation of a BO object which allocates from CMA:
bo = gbm_bo_create(gbm.dev,
1024, 768,
GBM_FORMAT_RGB565,
GBM_BO_USE_SCANOUT | GBM_BO_USE_RENDERING);
Followed by something like:
FRAMEBUFFER1 = gbm_bo_map(bo, 0, 0, 1024, 768, GBM_BO_TRANSFER_READ_WRITE, &stride, &map_data1);
....
gbm_bo_unmap(bo,map_data1);
results in the allocated CMA memory area not being freed on application termination or any attempt to destroy the BO (such as with GBM_BO_DESTROY()). This results in a massive memory leak.
If GBM_BO_USE_SCANOUT flag is not used then the buffer can be deallocated as expected but CMA memory may not have been allocated as a contiguous block.
The problem also applies to BO objects not used as rendering buffers such as:
videobuffer = gbm_bo_create(gbm.dev, 360, 625*3, GBM_FORMAT_ABGR8888, GBM_BO_USE_SCANOUT | GBM_BO_USE_LINEAR);
GBM_BO_USE_SCANOUT needs to be used here as using only GBM_BO_USE_LINEAR still results in fragmented memory allocation (but solves the problem of the memory leak).
The issue can easily be observed using kmscube sightly modified to add the gbm_bo_map (or add the GBM_BO_USE_SCANOUT flag to the argb texture example which uses gbm_bo_map) and observe declining CMA memory using # cat /proc/meminfo after every run (increase size of memory allocation for texture BO to make it more dramatic).
------------
Background: I need user space mapped addresses of the display framebuffers for post OpenGL rendering access. I worked around the above problem by avoiding the use of gbm_bo_map by interrogating the actual buffer address set in the LCD interface peripheral which contains the physical address of the current displaying framebuffer and then do a simple mmap() but so far have not figured out how to obtain the physical address of a BO once allocated by sane means (I use gbm_bo_map followed by virtual to physical translation to get the actual physical address needed for the hardware). So for my case I need a video streaming buffer which works great using the above but still have a significant memory leak for this one.
Alternate DMA-Buf mmap via FD has a limitation that PROT_WRITE cannot be used - so user space mmap is restricted to read-only access. Not sure there are valid reasons for this limitation.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/9334
Etnaviv Mesa driver works good on ARM ?
2023-10-16T19:16:21Z
Mario Marietto
Etnaviv Mesa driver works good on ARM ?
Hello.
Any of you, guys, had a success story of using Etnaviv Mesa driver with whatever graphics on ARM platform? Is it feasible to start X11/Wayland/FB with a Vivante GPU and RGB/MIPI display ?
Hello.
Any of you, guys, had a success story of using Etnaviv Mesa driver with whatever graphics on ARM platform? Is it feasible to start X11/Wayland/FB with a Vivante GPU and RGB/MIPI display ?
https://gitlab.freedesktop.org/mesa/mesa/-/issues/9283
[etnaviv] - screen flickering on i.MX6DL with QtWebEngine Qt 6.5
2023-08-04T08:31:56Z
Johannes Pointner
[etnaviv] - screen flickering on i.MX6DL with QtWebEngine Qt 6.5
### System information
- OS: Yocto Mickledore
- GPU: Vivante GC880 rev5106 (i.MX6DL)
- Kernel version: 6.1.33
- Mesa version: 23.0.3
- Desktop manager and compositor: QtWayland compositor
### Describe the issue
Scrolling in the QtWeb...
### System information
- OS: Yocto Mickledore
- GPU: Vivante GC880 rev5106 (i.MX6DL)
- Kernel version: 6.1.33
- Mesa version: 23.0.3
- Desktop manager and compositor: QtWayland compositor
### Describe the issue
Scrolling in the QtWebEngine cause a screen flickering and a wrong rendering of some parts of the display as you can see in the attached videos.
It worked until mesa 22.2.0 and it seems that the following commit cause this:
[etnaviv: rework resource status tracking (again)](https://gitlab.freedesktop.org/mesa/mesa/-/commit/09934730540bf6aa47e08b9bb1c6bf77a9493f4d)
If I partly(I have to remove the whole mutex part otherwise I only get a black screen) revert the commit, it works again as before.
![PXL_20230628_131616257_3](/uploads/20340e17e9fa3623bd2d7b6b08b56e07/PXL_20230628_131616257_3.mp4)
![PXL_20230628_143944361_3](/uploads/72407d309c7a6222c61d7654f59ad578/PXL_20230628_143944361_3.mp4)
Upgrading to mesa 23.1.1 didn't make a difference.
Lucas Stach
Lucas Stach
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8916
Surfaceless mode ES2.0 number of vertices limitation
2023-06-02T18:51:34Z
Rainier Lamers
Surfaceless mode ES2.0 number of vertices limitation
### System information
- OS: Linux 5.7.10 on ARM32 running on STM32MP157 CPU
- GPU: Vivante GC400
- Mesa version: 23.0.0, ES2.0, DRM
### Describe the issue
The number of vertices in surfaceless mode appears to be limited to around 18...
### System information
- OS: Linux 5.7.10 on ARM32 running on STM32MP157 CPU
- GPU: Vivante GC400
- Mesa version: 23.0.0, ES2.0, DRM
### Describe the issue
The number of vertices in surfaceless mode appears to be limited to around 1800. After this no further triangles are rendered and no GLError returned. In surface mode this limitation does not exist.
The issue can be easily seen using the kmscube test program (relatively recent version that supports surfaceless mode "kmscube -x"). Compile kmscube after replacing file cube-smooth.c with the attached version. The attached version simply draws many small rotating cubes instead of one.
kmscube (no args) draws 1000 small cubes (correct)
kmscube -x draws the first 150 cubes only (about 1800 vertices)
***Update: After more experimenting it appears the limitation is not related to number of triangles/vertices but rather to the number of glDrawArray calls. Drawing more triangles using a single draw call (Triangle strip) increases the number of triangles actually drawn to screen. Reducing calls to a 1/6th increases number of triangles drawn by 3 approximately. Surface mode draws correct in all cases.
### Attachment: modified cube-smooth.c
[cube-smooth.c](/uploads/c2dd6e9c90f037af94b9f222bed5c084/cube-smooth.c)
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8426
GPU hung on i.MX6QP using v6.1 kernel, mesa 22.3.6, Qt5
2023-03-31T15:58:34Z
Sebastian Reichel
GPU hung on i.MX6QP using v6.1 kernel, mesa 22.3.6, Qt5
Hi,
### System information
- OS: Yocto sumo based (very old!)
- GPU: Vivante GC3000 inside of i.MX6QP
- Kernel version: v6.1 + some extra patches adding HW support and DCIC
- Mesa version: 22.3.6
- Desktop manager and compositor: based...
Hi,
### System information
- OS: Yocto sumo based (very old!)
- GPU: Vivante GC3000 inside of i.MX6QP
- Kernel version: v6.1 + some extra patches adding HW support and DCIC
- Mesa version: 22.3.6
- Desktop manager and compositor: based on https://wiki.qt.io/QtWayland (Qt5)
### issue description
```
2023-03-02T09:43:20+0100 kernel: etnaviv-gpu 130000.gpu: recover hung GPU!
2023-03-02T09:43:21+0100 kernel: etnaviv-gpu 130000.gpu: recover hung GPU!
```
The exact steps to reproduce the problem is unknown. Initially (older kernel and mesa) it was possible to reproduce hungs by running `glmark2-es2-drm` for a few hours/days, but that no longer works with mesa 22.3.6 (system can run `glmark2-es2-drm` for weeks without any hung now). Qt on the other hand still produces hungs sporadically. When a hung appears, there is a high chance, that a second one happens shortly after (but not always). A similar machine running the same software, but being based on i.MX6Q (without P) seems to be unaffected. A colleague of mine pointed me to a patch from @lynxeye that adds brown-out detection support for the GPU regulator and no brownouts are detected for the hardware.
### Logs
[devcoredump.bin.xz](/uploads/4900289f4229235940aa6e511b2efd36/devcoredump.bin.xz)
```
=== Register dump
0000000c = 00000099
00000000 = 00040900
00000004 = 7ffffffa Idle: FE- DE+ PE- SH+ PA+ SE+ RA+ TX+ VG+ IM+ FP+ TS+
00000008 = 00002200
00000014 = ffffffff
00000018 = 14010000
0000001c = e0287cad
00000020 = 00002000
00000024 = ffff5450
00000028 = 20140617
0000002c = 20575900
00000034 = c9799efb
00000038 = 00000000
00000070 = 00000000
00000100 = 00140021
00000104 = 00030000
00000108 = 000010f8
0000010c = 015d0880
00000400 = 00000000
00000404 = 00000000
00000408 = 00000000
0000040c = 00000000
00000410 = 00000000
00000414 = 3c000000
00000418 = 00000000
0000041c = 00000000
00000420 = 00000000
00000424 = 00000000
00000428 = 00000000
0000042c = 00030000
00000480 = 00000000
0000065c = 00000001
00000660 = 00000015 Cmd: [stall DMA: idle Fetch: idle] Req idle Cal idle
00000664 = 00001200 Command DMA address
00000668 = 48000000 FE fetched word 0
0000066c = 00000701 FE fetched word 1
00000670 = 00000000
=== Buffers
Num Name IOVA Size
0 reg 00000000 00000128 296
1 mmu 00000000 00005000 20480
* 2 ring 00001000 00001000 4096
3 cmd 0000a000 000005c8 1480
4 bomap 00000000 00000320 800
5 bo fd8c1000 00001000 4096
6 bo fe212000 00030000 196608
7 bo ff1d3000 00001000 4096
8 bo fd696000 0000a000 40960
9 bo fe5c6000 00028000 163840
Checking MMU entries... failed
Buf 5 Offset 00000000: 000002f6 70942000
Buf 6 Offset 00000000: 00000000 56867000
Buf 6 Offset 00001000: 00000000 56868000
Buf 6 Offset 00002000: 00000000 56869000
Buf 6 Offset 00003000: 00000000 5686a000
Buf 6 Offset 00004000: 00000000 5686b000
Buf 6 Offset 00005000: 00000001 5686c000
Buf 6 Offset 00006000: 00000001 5686d000
Buf 6 Offset 00007000: 00000000 5686e000
Buf 6 Offset 00008000: 00000000 5686f000
Buf 6 Offset 00009000: 00000000 56870000
Buf 6 Offset 0000a000: 00000000 56871000
Buf 6 Offset 0000b000: 00000000 56872000
Buf 6 Offset 0000c000: 00000000 56873000
Buf 6 Offset 0000d000: 00000000 56874000
Buf 6 Offset 0000e000: 00000000 56875000
Buf 6 Offset 0000f000: 00000000 56876000
Buf 6 Offset 00010000: 00000000 56877000
Buf 6 Offset 00011000: 00000000 56878000
Buf 6 Offset 00012000: 00000000 56879000
Buf 6 Offset 00013000: 00000000 5687a000
Buf 6 Offset 00014000: 03020100 5687b000
Buf 6 Offset 00015000: 07060504 5687c000
Buf 6 Offset 00016000: 0b0a0908 5687d000
Buf 6 Offset 00017000: 40404040 5687e000
Buf 6 Offset 00018000: 0c404040 5687f000
Buf 6 Offset 00019000: 100f0e0d 56880000
Buf 6 Offset 0001a000: 14131211 56881000
Buf 6 Offset 0001b000: 18171615 56882000
Buf 6 Offset 0001c000: 1c1b1a19 56883000
Buf 6 Offset 0001d000: 201f1e1d 56884000
Buf 6 Offset 0001e000: 24232221 56885000
Buf 6 Offset 0001f000: 40404025 56886000
Buf 6 Offset 00020000: 26404040 568c6000
Buf 6 Offset 00021000: 2a292827 568c7000
Buf 6 Offset 00022000: 2e2d2c2b 568c8000
Buf 6 Offset 00023000: 3231302f 568c9000
Buf 6 Offset 00024000: 36353433 568ca000
Buf 6 Offset 00025000: 3a393837 568cb000
Buf 6 Offset 00026000: 3e3d3c3b 568cc000
Buf 6 Offset 00027000: 0000003f 568cd000
Buf 6 Offset 00028000: 00000000 568ce000
Buf 6 Offset 00029000: 00000000 568cf000
Buf 6 Offset 0002a000: 00000000 568d0000
Buf 6 Offset 0002b000: 00000000 568d1000
Buf 6 Offset 0002c000: 00000005 568d2000
Buf 6 Offset 0002d000: 6562616c 568d3000
Buf 6 Offset 0002e000: 0000006c 568d4000
Buf 6 Offset 0002f000: 00000000 568d5000
Buf 7 Offset 00000000: ffec98bc 568d6000
Buf 8 Offset 00000000: 0001d67f 70bb5000
Buf 8 Offset 00001000: 00000000 70bb8000
Buf 8 Offset 00002000: 0001d680 708e3000
Buf 8 Offset 00003000: 00000000 708df000
Buf 8 Offset 00004000: 0001d681 708e4000
Buf 8 Offset 00005000: 00000000 70bbc000
Buf 8 Offset 00006000: 0001d682 70bbd000
Buf 8 Offset 00007000: 00000000 708e0000
Buf 8 Offset 00008000: 0001d683 708e6000
Buf 8 Offset 00009000: 00000000 70bbe000
Buf 9 Offset 00000000: 00000000 568d7000
Buf 9 Offset 00001000: 00000000 568d8000
Buf 9 Offset 00002000: 00000000 568d9000
Buf 9 Offset 00003000: 00000000 568da000
Buf 9 Offset 00004000: 00000000 568db000
Buf 9 Offset 00005000: 00000000 568dc000
Buf 9 Offset 00006000: 00000000 568dd000
Buf 9 Offset 00007000: 00000000 568de000
Buf 9 Offset 00008000: 00000000 568df000
Buf 9 Offset 00009000: 00000000 568e0000
Buf 9 Offset 0000a000: 00000000 568e1000
Buf 9 Offset 0000b000: 00000000 568e2000
Buf 9 Offset 0000c000: 00000000 568e3000
Buf 9 Offset 0000d000: 00000000 568e4000
Buf 9 Offset 0000e000: 00000000 568e5000
Buf 9 Offset 0000f000: 00000000 568e6000
Buf 9 Offset 00010000: 00000000 568e7000
Buf 9 Offset 00011000: 00000000 568e8000
Buf 9 Offset 00012000: 00000000 568e9000
Buf 9 Offset 00013000: 00000000 568ea000
Buf 9 Offset 00014000: 00000000 568eb000
Buf 9 Offset 00015000: 00000000 568ec000
Buf 9 Offset 00016000: 00000000 568ed000
Buf 9 Offset 00017000: 00000000 568ee000
Buf 9 Offset 00018000: 00000000 568ef000
Buf 9 Offset 00019000: 00000000 568f0000
Buf 9 Offset 0001a000: 00000000 568f1000
Buf 9 Offset 0001b000: 00000000 568f2000
Buf 9 Offset 0001c000: 00000000 568f3000
Buf 9 Offset 0001d000: 00000000 568f4000
Buf 9 Offset 0001e000: 00000000 568f5000
Buf 9 Offset 0001f000: 00000000 568f6000
Buf 9 Offset 00020000: 00000000 568f7000
Buf 9 Offset 00021000: 00000000 568f8000
Buf 9 Offset 00022000: 00000000 568f9000
Buf 9 Offset 00023000: 00000000 568fa000
Buf 9 Offset 00024000: 00000000 568fb000
Buf 9 Offset 00025000: 00000000 568fc000
Buf 9 Offset 00026000: 00000000 568fd000
Buf 9 Offset 00027000: 00000000 568fe000
```
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8384
wayland direct scan-out on kmsro devices (imx-drm with etnaviv on i.MX6)
2023-04-30T08:54:28Z
Christian Meissl
wayland direct scan-out on kmsro devices (imx-drm with etnaviv on i.MX6)
### System information
- OS: custom build from yocto
- GPU: Vivante GC2000 rev 5108 (Etnaviv)
- Kernel version: 5.15.55
- Mesa version: 22.3.5
- Xserver version (if applicable): -
- Desktop manager and compositor: Compositor based on sm...
### System information
- OS: custom build from yocto
- GPU: Vivante GC2000 rev 5108 (Etnaviv)
- Kernel version: 5.15.55
- Mesa version: 22.3.5
- Xserver version (if applicable): -
- Desktop manager and compositor: Compositor based on smithay
### Issue
As discussed in #dri-devel I am trying to get direct scan-out of EGL clients under wayland to work on the i.MX6.
When running `glmark2-es2-wayland` the buffers will first use a modifier unsuited for scan-out and are rejected as expected.
As soon as the compositor provides a scan-out tranche the client switches to linear. The linear buffers can be successfully imported through gbm but `drmModeAddFB2` fails for the imported bo.
Relevant log entry from dmesg:
```
imx-drm display-subsystem: [drm:drm_gem_fb_init_with_funcs] Failed to lookup GEM object
```
I am not familiar with the inner workings but I tried to analyze what is going on and this is what I believe to have found out:
It seems that to get a scan-out able buffer from etnaviv the following condition in `etna_resource_alloc` has to be true:
```
unlikely(templat->bind & PIPE_BIND_SCANOUT) && screen->ro
```
This will then use kmsro by calling `renderonly_scanout_for_resource` to get a scan-out buffer which the driver imports
for rendering.
So how to make that to evaluate to `true`:
- First `PIPE_BIND_SCANOUT` has to be set, this is done by passing `__DRI_IMAGE_USE_SCANOUT` to `loader_dri_create_image` in `platform_wayland.c`
- kmsro has to be used to have a `screen->ro`, this is done by `kmsro_drm_screen_create` in `kmsro_drm_winsys.c`
A requirement for actually receiving `PIPE_BIND_SCANOUT` in `etna_resource_alloc` is the use of `wl_dmabuf` and a scan-out tranche in the wayland platform.
`kmsro` will only be used when the compositor passes a device that will result in the loader creating kmsro. In case of the i.mx6 the `imx-drm` device node.
But it seems that these two requirements are contradictory, if the main device passed to the wayland platform is not a render node the dmabuf feedback will be ignored as it falls back to `wl_drm`. If a render node is passed the feedback is used and the scanout flag is set but kmsro will not be used.
Importing and scanning out buffers imported from gstreamer `waylandsink` works as expected.
I found #5099, but that has been fixed by !12018.
cc @robclark @emersion @daniels @austriancoder
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8180
etnaviv MMU fault and memory corruption caused by bogus glVertexAttribPointer...
2023-01-31T13:38:43Z
Lukas F. Hartmann
lukas@mntmn.com
etnaviv MMU fault and memory corruption caused by bogus glVertexAttribPointer() arguments
Tracing an annoying hang and MMU faults in telegram-desktop (when viewing media) on imx8mq/GC7000 rev 6124, I found that something related to glVertexAttribPointer() is the culprit.
Mesa is latest from git (`OpenGL version string: 2.1 M...
Tracing an annoying hang and MMU faults in telegram-desktop (when viewing media) on imx8mq/GC7000 rev 6124, I found that something related to glVertexAttribPointer() is the culprit.
Mesa is latest from git (`OpenGL version string: 2.1 Mesa 23.1.0-devel (git-17b610771d)`), Kernel is 6.1.7.
I hacked together a minimal test program which reproduces the issue:
```c
// Minimal OpenGL shader example using OpenGL directly
#include <math.h>
#include <stdio.h>
#include <GL/glew.h>
#include <GL/glut.h>
GLuint vao;
GLuint vbo;
GLuint idx;
GLuint tex;
GLuint program;
int width = 320;
int height = 240;
void onDisplay(void)
{
glClear(GL_COLOR_BUFFER_BIT);
glDrawElements(GL_TRIANGLES, 3, GL_UNSIGNED_INT, (void
*)0);
glutSwapBuffers();
}
void onResize(int w, int h)
{
width = w; height = h;
glViewport(0, 0, (GLsizei)w, (GLsizei)h);
}
GLfloat vertices[] = {
0.5f, 0.5f, 0.0f, 1.0f, 1.0f,
-0.5f, 0.5f, 0.0f, 0.0f, 1.0f,
-0.5f, -0.5f, 0.0f, 0.0f, 0.0f
};
unsigned int indices[] = { 0, 1, 2 };
int main(int argc, char** argv)
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB);
glutInitWindowSize(width, height);
glutCreateWindow("mini");
glewExperimental = GL_TRUE;
glewInit();
glGenVertexArrays(1, &vao);
glBindVertexArray(vao);
glGenBuffers(1, &vbo);
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
glGenBuffers(1, &idx);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, idx);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW);
// invalid last parameter
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 5 * sizeof(float), (void *)0xffff);
glEnableVertexAttribArray(0);
glutDisplayFunc(onDisplay);
glutReshapeFunc(onResize);
glutMainLoop();
glDisableVertexAttribArray(0);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
glDeleteBuffers(1, &idx);
glBindBuffer(GL_ARRAY_BUFFER, 0);
glDeleteBuffers(1, &vbo);
glBindVertexArray(0);
glDeleteVertexArrays(1, &vao);
return 0;
}
```
The program is compiled with `gcc -o test test.c -lGL -lGLEW -lGLU -lglut`.
Executing it causes kernel messages like:
```
[ 5480.472043] etnaviv-gpu 38000000.gpu: MMU fault status 0x00000001
[ 5480.478161] etnaviv-gpu 38000000.gpu: MMU 0 fault addr 0xfd4baf00
[ 5481.490650] etnaviv-gpu 38000000.gpu: recover hung GPU!
[ 5604.120350] Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF
[ 5779.887180] Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF
[ 5780.176308] Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF
```
Changing the first and last arguments to glVertexAttribPointer() causes other severe effects. For example, with the first parameter as -1 and the last as 0, textures of other programs (under sway) are trashed or disappear. It is also possible to completely hang the machine.
Lucas Stach
Lucas Stach
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7898
etnaviv: mesa-22.3.0 regression on i.MX8M Mini
2022-12-29T19:26:24Z
Alexander Stein
etnaviv: mesa-22.3.0 regression on i.MX8M Mini
### System information
- OS: `Dumpling Wayland (TQ-Systems Dumpling Wayland Distribution)`
- GPU:
```
dmesg|grep etnaviv-gpu
[ 1.390820] etnaviv-gpu 38000000.gpu: model: GC600, revision: 4653
[ 1.397082] etnaviv-gpu 38000000.gpu: ...
### System information
- OS: `Dumpling Wayland (TQ-Systems Dumpling Wayland Distribution)`
- GPU:
```
dmesg|grep etnaviv-gpu
[ 1.390820] etnaviv-gpu 38000000.gpu: model: GC600, revision: 4653
[ 1.397082] etnaviv-gpu 38000000.gpu: Need to move linear window on MC1.0, disabling TS
[ 1.405107] etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
```
- Kernel version: `Linux tqma8-common 6.1.0-next-20221214+ #1063 SMP PREEMPT Wed Dec 14 11:02:52 CET 2022 aarch64 aarch64 aarch64 GNU/Linux`
- Mesa version: `GL version: OpenGL ES 2.0 Mesa 23.0.0-devel (git-9dedbf66f6)`
- Desktop manager and compositor: `weston 10.0.2`
### Describe the issue
Starting with commit d08bd9a8d8b ("etnaviv: don't expose array and 3D texture support on pre-halti GPUs") `weston` displays just a black screen.
Trying the immediate commit before 2b0f77bde56 ("etnaviv: allow 3D textures with TS in transfer"), `weston` displays as expected.
### Regression
Starting with commit d08bd9a8d8b ("etnaviv: don't expose array and 3D texture support on pre-halti GPUs") this regression occured.
### Log files as attachment
When starting `weston` at some point the following Mesa messages are output:
```
Mesa: User error: GL_INVALID_VALUE in glTexImage2D(invalid width=1280 or height=32 or depth=1)
Mesa: 1 similar GL_INVALID_VALUE errors
Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
Mesa: User error: GL_INVALID_OPERATION in glTexSubImage2D(invalid texture level 0)
```
### Any extra information would be greatly appreciated
Apparently this doesn't happen with an i.MX8M **Nano**, so I suspect this is due to that the GPU on i.MX8M **Mini** only supports OpenGLES 2, rather than version 3.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7679
etnaviv: broken rendering due to TS sharing
2022-11-17T10:03:38Z
Lucas Stach
etnaviv: broken rendering due to TS sharing
The new TS sharing functionality does break the wdisplays application (https://github.com/luispabon/wdisplays). Corruption is transient. Bigger application window width (>1000 pixels) seem to hide the issue.
Looks like invalid TS buffer...
The new TS sharing functionality does break the wdisplays application (https://github.com/luispabon/wdisplays). Corruption is transient. Bigger application window width (>1000 pixels) seem to hide the issue.
Looks like invalid TS buffer access (wrong offset or something like that).
Examples of corruption:
http://dump.mntmn.com/screenshot-2022-11-10-16-41-53.png
http://dump.mntmn.com/screenshot-2022-11-10-16-43-11.png
Lucas Stach
Lucas Stach
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7678
etnaviv: broken SVG rendering in Chromium due to MSAA
2023-04-23T17:11:51Z
Lucas Stach
etnaviv: broken SVG rendering in Chromium due to MSAA
Skia uses MSAA to render SVG images when available. Etnaviv MSAA is falling apart in that case, even with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19582 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19571...
Skia uses MSAA to render SVG images when available. Etnaviv MSAA is falling apart in that case, even with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19582 and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19571 applied. This needs fixing before the 22.3 final release, or at least a debug switch so users can disable MSAA support when necessary.
Examples of the corruption:
http://dump.mntmn.com/screenshot-2022-11-10-18-56-12.png
http://dump.mntmn.com/screenshot-2022-11-10-18-58-27.png
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7665
etnaviv 16-bit DMA buffer import
2023-03-12T12:58:50Z
Dorota Czaplejewicz (Purism)
etnaviv 16-bit DMA buffer import
I'm trying to use 16-bit depth grayscale buffers with etnaviv. There's an issue where I can't import a previously allocated DMA buffer.
The code I use for the import:
```
EGLint const attrs[] = {
EGL_WIDTH, (int)pixelSize.width,
...
I'm trying to use 16-bit depth grayscale buffers with etnaviv. There's an issue where I can't import a previously allocated DMA buffer.
The code I use for the import:
```
EGLint const attrs[] = {
EGL_WIDTH, (int)pixelSize.width,
EGL_HEIGHT, (int)pixelSize.height,
EGL_LINUX_DRM_FOURCC_EXT, (int)format.get_fourcc(),
EGL_DMA_BUF_PLANE0_FD_EXT, fd,
EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
EGL_DMA_BUF_PLANE0_PITCH_EXT, (int)pixelSize.width * bytes_per_pixel,
EGL_NONE,
};
auto eglCreateImageKHR = (PFNEGLCREATEIMAGEKHRPROC)eglGetProcAddress("eglCreateImageKHR");
auto image = eglCreateImageKHR (
egl.display,
EGL_NO_CONTEXT,
EGL_LINUX_DMA_BUF_EXT,
NULL,
attrs
);
```
eglCreateImageKHR will always fail. The reason is that the fourcc is `R16 `, and it gets converted internally into `PIPE_FORMAT_R16_UNORM` via `dri2_get_mapping_by_fourcc` in `dri2_create_image_from_fd`. The vivante hardware doesn't seem to support 16-bit unorm types, so it is guaranteed to fail.
Vivante does support `PIPE_FORMAT_R16_UINT` at least in some hardware versions, but there's currently no way to request a buffer of this type.
Should `PIPE_FORMAT_R16_UNORM` be unconditionally converted into `PIPE_FORMAT_R16_UINT` for importing? Both satisfy user's fourcc request for a R16 type.
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7652
etnaviv: compiler assertion fail in glmark2 terrain
2022-11-23T19:13:39Z
Lucas Stach
etnaviv: compiler assertion fail in glmark2 terrain
Since 45a111c21c23be94f9297650fb8428fe2acf5641, which is part of the current 22.3-rc1, glmark2 terrain fails on >= halti2 GPUs with the following assertion:
`src/gallium/drivers/etnaviv/etnaviv_compiler_nir.c:501: emit_alu: Assertion '!...
Since 45a111c21c23be94f9297650fb8428fe2acf5641, which is part of the current 22.3-rc1, glmark2 terrain fails on >= halti2 GPUs with the following assertion:
`src/gallium/drivers/etnaviv/etnaviv_compiler_nir.c:501: emit_alu: Assertion '!asrc->negate && alu->op != nir_op_fneg' failed.`
According to rnndb it might be possible to handle negation on float immediates by setting `AMODE = 1`, but this needs validation.
Christian Gmeiner
Christian Gmeiner
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7496
etnaviv: implement buffer and texture clears
2022-12-02T17:08:37Z
Lucas Stach
etnaviv: implement buffer and texture clears
Rusticl requires the buffer and texture clear Gallium calls (see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18986/diffs?commit_id=5e78ea2935e4d3cbcbfc9ec0a6b32d791798188d). While the util implementation might suffice to sa...
Rusticl requires the buffer and texture clear Gallium calls (see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18986/diffs?commit_id=5e78ea2935e4d3cbcbfc9ec0a6b32d791798188d). While the util implementation might suffice to satisfy the requirement, we can certainly do better by having a RS/BLT targeted implementation of those APIs. As this is a improvement I had somewhere down on my TODO list anyway, bumping the priority of this might be a good idea.
Lucas Stach
Lucas Stach
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7153
regression: etnaviv rendering issues since 22.2.0
2022-09-14T09:18:00Z
Adrien Ramos
regression: etnaviv rendering issues since 22.2.0
### System information
- OS: Debian GNU/Linux bookworm/sid
- GPU: Vivante GC7000 rev 6214, imx-dcssdrmfb
- Kernel version: Linux king 5.18.0-reform2-arm64 #1 SMP Debian 5.18.14-1+reform1 (2022-08-07) aarch64 GNU/Linux
- Mesa version: Op...
### System information
- OS: Debian GNU/Linux bookworm/sid
- GPU: Vivante GC7000 rev 6214, imx-dcssdrmfb
- Kernel version: Linux king 5.18.0-reform2-arm64 #1 SMP Debian 5.18.14-1+reform1 (2022-08-07) aarch64 GNU/Linux
- Mesa version: OpenGL version string: 2.1 Mesa 22.2.0-rc3
- Desktop manager and compositor: Sway wayland compositor 1.7
### Describe the issue
Rendering of some programs is broken since 22.2.0-rc2, especially programs using SDL2 or a GTK webview.
Some parts of UI appear to not be rendered, some sections of windows stay the background color of the program, or plain black.
Terminal output for these programs show this line being repeated quite frequently
```
MESA: error: etna_cmd_stream_flush:238: submit failed: -28 (No space left on device)
```
Quick testing with 22.2.0-rc1 shows that the error message is printed but rendering appears to be working, since 22.2.0-rc2 the message is more frequent and rendering is broken.
The latest main branch from today (b8c861b86438f6d38d8dda792de9ac5f7e4bb13b) also has the issue.
### Regression
I can’t reproduce this behavior at all with Mesa 22.1.7.
### Screenshots/video files (if applicable)
![screenshot-2022-08-30-12-11-16](/uploads/9d4694cffbbc3e769ddedba9be149085/screenshot-2022-08-30-12-11-16.png)