mesa issueshttps://gitlab.freedesktop.org/mesa/mesa/-/issues2019-09-25T18:03:09Zhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/238llvmpipe crash in rendering on Atom2019-09-25T18:03:09ZBugzilla Migration Userllvmpipe crash in rendering on Atom## Submitted by comicfans44
Assigned to **mes..@..op.org**
**[Link to original bug (#94522)](https://bugs.freedesktop.org/show_bug.cgi?id=94522)**
## Description
mesa version 11.1.2
llvm 3.7.1
cpu: intel ATOM z520 :32bit only,supp...## Submitted by comicfans44
Assigned to **mes..@..op.org**
**[Link to original bug (#94522)](https://bugs.freedesktop.org/show_bug.cgi?id=94522)**
## Description
mesa version 11.1.2
llvm 3.7.1
cpu: intel ATOM z520 :32bit only,supports sse sse2 ssse3 but not sse4 nor avx
weston crash when calling eglSwapBuffers
backtrace shows crash thread receives SIGBUS
Thread 2 "llvmpipe-0" received signal SIGBUS, Bus error.
```
#0 0xb755e633 in ?? ()
#1 0xb6e2960b in lp_rast_shade_tile (task=0x80a9ab4, arg=...) at lp_rast.c:352
#2 0xb6e29981 in do_rasterize_bin (bin=<optimized out>, x=<optimized out>, y=<optimized out>, task=0x80a9ab4) at lp_rast.c:609
#3 rasterize_bin (y=<optimized out>, x=<optimized out>, bin=<optimized out>, task=0x80a9ab4) at lp_rast.c:628
#4 rasterize_scene (task=task@entry=0x80a9ab4, scene=<optimized out>) at lp_rast.c:688
#5 0xb6e2a10a in thread_function (init_data=0x80a9ab4) at lp_rast.c:828
#6 0xb6e29f25 in impl_thrd_routine (p=0x80a2498) at ../../../../include/c11/threads_posix.h:87
#7 0xb7c6f291 in start_thread () from target:/usr/lib/libpthread.so.0
#8 0xb7d75d7e in clone () from target:/usr/lib/libc.so.6
```
eglSwapBuffers calling thread:
0xb7fdbc11 in __kernel_vsyscall ()
```
#1 0xb7c74aab in pthread_cond_wait@@GLIBC_2.3.2 () from target:/usr/lib/libpthread.so.0
#2 0xb7d8248d in pthread_cond_wait@@GLIBC_2.3.2 () from target:/usr/lib/libc.so.6
#3 0xb6e2a55a in cnd_wait (mtx=0x80a9b64, cond=0x80a9b7c) at ../../../../include/c11/threads_posix.h:159
#4 pipe_semaphore_wait (sema=0x80a9b64) at ../../../../src/gallium/auxiliary/os/os_thread.h:259
#5 lp_rast_finish (rast=0x80a9aa8) at lp_rast.c:771
#6 0xb6e35aab in lp_setup_rasterize_scene (setup=0x811cac8) at lp_setup.c:180
#7 set_scene_state (setup=setup@entry=0x811cac8, new_state=new_state@entry=SETUP_FLUSHED, reason=0xb6f44308 <__func__.14289> "do_flush") at lp_setup.c:330
#8 0xb6e3666f in lp_setup_flush (setup=0x811cac8, fence=0x0, reason=0xb6f44308 <__func__.14289> "do_flush") at lp_setup.c:359
#9 0xb6e287f5 in llvmpipe_flush (pipe=0x80fc1a0, fence=0x0, reason=0xb6f44308 <__func__.14289> "do_flush") at lp_flush.c:55
#10 0xb6e27e33 in do_flush (pipe=0x80fc1a0, fence=0x0, flags=1) at lp_context.c:113
#11 0xb69b43b1 in st_flush (st=0x81ee428, fence=0x0, flags=1) at state_tracker/st_cb_flush.c:87
#12 0xb69fe5eb in st_context_flush (stctxi=0x81ee428, flags=2, fence=0x0) at state_tracker/st_manager.c:504
#13 0xb6ad192d in dri_flush (cPriv=0x80cb130, dPriv=0x80fb9b0, flags=5, reason=__DRI2_THROTTLE_SWAPBUFFER) at dri_drawable.c:538
#14 0xb753b82b in dri2_flush_drawable_for_swapbuffers (disp=0x80b7458, draw=0x80fb7f0) at drivers/dri2/egl_dri2.c:1318
#15 0xb75417e0 in dri2_drm_swap_buffers (drv=0x80b56c0, disp=0x80b7458, draw=0x80fb7f0) at drivers/dri2/platform_drm.c:441
#16 0xb7538db8 in dri2_swap_buffers (drv=0x80b56c0, dpy=0x80b7458, surf=0x80fb7f0) at drivers/dri2/egl_dri2.c:1333
#17 0xb75331b4 in eglSwapBuffers (dpy=0x80b7458, surface=0x80fb7f0) at main/eglapi.c:1010
```
another thread backtrace:
```
#0 0xb6e2b9e8 in do_block_16_32_1 (c=<synthetic pointer>, y=<optimized out>, x=<optimized out>, plane=0xb35b10f4, tri=0x812beb0, task=0x80a9bb0) at lp_rast_tri_tmp.h:136
#1 lp_rast_triangle_32_1 (task=0x80a9bb0, arg=...) at lp_rast_tri_tmp.h:232
#2 0xb6e29981 in do_rasterize_bin (bin=<optimized out>, x=<optimized out>, y=<optimized out>, task=0x80a9bb0) at lp_rast.c:609
#3 rasterize_bin (y=<optimized out>, x=<optimized out>, bin=<optimized out>, task=0x80a9bb0) at lp_rast.c:628
#4 rasterize_scene (task=task@entry=0x80a9bb0, scene=<optimized out>) at lp_rast.c:688
#5 0xb6e2a10a in thread_function (init_data=0x80a9bb0) at lp_rast.c:828
#6 0xb6e29f25 in impl_thrd_routine (p=0x8091c30) at ../../../../include/c11/threads_posix.h:87
#7 0xb7c6f291 in start_thread () from target:/usr/lib/libpthread.so.0
#8 0xb7d75d7e in clone () from target:/usr/lib/libc.so.6
```
Version: 11.1https://gitlab.freedesktop.org/mesa/mesa/-/issues/9373llvmpipe doesn't support linear modifiers2023-07-17T12:30:18ZXaver Huglllvmpipe doesn't support linear modifiersSimpledrm only supports linear modifiers, so the combination of the display driver with support for only explicit modifiers with the implicit modifiers only llvmpipe is a bit problematic. If the compositor intersects the supported 'modif...Simpledrm only supports linear modifiers, so the combination of the display driver with support for only explicit modifiers with the implicit modifiers only llvmpipe is a bit problematic. If the compositor intersects the supported 'modifiers' (`DRM_FORMAT_MOD_INVALID`) of llvmpipe and simpledrm, it comes up empty.
Working around this issue in compositors is simple enough (assume that linear modifiers are supported with implicit modifiers too, and allocate a buffer with implicit modifiers + `GBM_BO_USE_LINEAR`) but it doesn't feel like a correct solution.
An alternative solution to this could also be that simpledrm would report implicit modifiers as supported, and have llvmpipe deal with it in the usual way that other drivers deal with implicit modifiers for scanout.https://gitlab.freedesktop.org/mesa/mesa/-/issues/10574llvmpipe driver crash when cpu vendor id is AMD inside qemu since commit f92...2024-02-12T15:07:28ZLepton Wullvmpipe driver crash when cpu vendor id is AMD inside qemu since commit f92cadccc65128fdaa54e59ba40dcf75e90a25ddActually I am not sure if this is a llvm bug or mesa bug. But the behavior looks very strange.
Basically we are running mesa llvmpipe driver inside qemu and we basically use this flag to launch qemu `-cpu Haswell`
This works fine until...Actually I am not sure if this is a llvm bug or mesa bug. But the behavior looks very strange.
Basically we are running mesa llvmpipe driver inside qemu and we basically use this flag to launch qemu `-cpu Haswell`
This works fine until commit f92cadccc65128fdaa54e59ba40dcf75e90a25dd. Since they, mesa llvmpipe driver will just crash on any AMD work station with this complain:
"LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it!"
I checked and it seems in the old code path, it has "+64bits" in the feature list while the new code path dopesn't have it.
The strange part is: it only crash on AMD work station and still works fine on Intel work station. I checked the /proc/cpuinfo and it seems while both CPU was set to Haswell, they have different vendor_id on AMD/Intel. So I am guessing maybe vendor id will cuase some difference.
Then I confirmed that, if I am launching qemu with `-cpu "Haswell,vendor=AuthenticAMD"`, mesa llvmpipe will crash on both Intel/AMD workstation. But if I change the vendor string to anything else, then it works fine on both Intel/AMD workstation.
So the question is, why "AuthenticAMD" matter? BTW, the LLVM version is 12.0.1https://gitlab.freedesktop.org/mesa/mesa/-/issues/10486llvmpipe fails to build with LLVM 112024-01-23T21:25:08ZPavel Ondračkapavel.ondracka@gmail.comllvmpipe fails to build with LLVM 11```
../src/gallium/drivers/llvmpipe/lp_texture_handle.c: In function ‘lp_build_compile_function_type’:
../src/gallium/drivers/llvmpipe/lp_texture_handle.c:527:27: error: implicit declaration of function ‘LLVMPointerTypeInContext’; did yo...```
../src/gallium/drivers/llvmpipe/lp_texture_handle.c: In function ‘lp_build_compile_function_type’:
../src/gallium/drivers/llvmpipe/lp_texture_handle.c:527:27: error: implicit declaration of function ‘LLVMPointerTypeInContext’; did you mean ‘LLVMIntPtrTypeInContext’? [-Werror=implicit-function-declaration]
527 | LLVMTypeRef ret_type = LLVMPointerTypeInContext(gallivm->context, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~
| LLVMIntPtrTypeInContext
../src/gallium/drivers/llvmpipe/lp_texture_handle.c:527:27: error: initialization of ‘LLVMTypeRef’ {aka ‘struct LLVMOpaqueType *’} from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
cc1: some warnings being treated as errors
```
Probably minimum required LLVM version should have been updated in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27182 ?
cc @KonstantinSeurer
This is on 32bit Debian bullseye with LLVM 11.0.1 and gcc 10.2.1.https://gitlab.freedesktop.org/mesa/mesa/-/issues/9128llvmpipe_flush_resource race condition results in use-after-free2023-06-01T09:01:48Z小田喜陽彦llvmpipe_flush_resource race condition results in use-after-free### System information
- OS: Arch Linux ARM
- GPU: llvmpipe
- Kernel version: `Linux alarm 6.2.0-asahi-11-1-edge-ARCH #2 SMP PREEMPT_DYNAMIC Sun, 28 May 2023 13:06:27 +0000 aarch64 GNU/Linux`
- Mesa version: 23.1.1
- Xserver version (if...### System information
- OS: Arch Linux ARM
- GPU: llvmpipe
- Kernel version: `Linux alarm 6.2.0-asahi-11-1-edge-ARCH #2 SMP PREEMPT_DYNAMIC Sun, 28 May 2023 13:06:27 +0000 aarch64 GNU/Linux`
- Mesa version: 23.1.1
- Xserver version (if applicable): 1.21.1.8
- Desktop manager and compositor: GNOME
### Describe the issue
I experienced a crash when running `LIBGL_ALWAYS_SOFTWARE=1 firefox` and opening a file on: https://www.figma.com/
I got the following stacktrace by opening the coredump with gdb:
```
#0 __pthread_kill_implementation (threadid=281472070774976, signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x0000ffff70b227e4 in __pthread_kill_internal (signo=11, threadid=<optimized out>) at pthread_kill.c:78
#2 0x0000ffff70adb6fc in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
#3 0x0000ffff694b72b0 in () at /usr/lib/firefox/libxul.so
#4 0x0000ffff69d147f8 in () at /usr/lib/firefox/libxul.so
#5 0x0000ffff70f507ec in <signal handler called> ()
#6 lp_scene_is_resource_referenced (scene=0xffff1e2c08f0, resource=resource@entry=0xffff21bba300) at ../mesa/src/gallium/drivers/llvmpipe/lp_scene.c:519
#7 0x0000ffff488bc9a4 in lp_setup_is_resource_referenced (setup=0xffff2db48000, texture=0xffff21bba300) at ../mesa/src/gallium/drivers/llvmpipe/lp_setup.c:1128
#8 0x0000ffff488a0b40 in llvmpipe_is_resource_referenced (pipe=pipe@entry=0xffff10df4000, presource=presource@entry=0xffff21bba300, level=level@entry=0) at ../mesa/src/gallium/drivers/llvmpipe/lp_texture.c:844
#9 0x0000ffff488a2700 in llvmpipe_flush_resource
(pipe=pipe@entry=0xffff40a80000, resource=0xffff21bba300, level=level@entry=0, read_only=read_only@entry=1 '\001', cpu_access=cpu_access@entry=0 '\000', do_not_block=do_not_block@entry=0 '\000', reason=reason@entry=0xffff492d4758 "sampler_view")
at ../mesa/src/gallium/drivers/llvmpipe/lp_flush.c:126
#10 0x0000ffff488d53a4 in llvmpipe_set_sampler_views (pipe=0xffff40a80000, shader=MESA_SHADER_FRAGMENT, start=0, num=1, unbind_num_trailing_slots=0, take_ownership=true, views=0xffff52cacbf8)
at ../mesa/src/gallium/drivers/llvmpipe/lp_state_sampler.c:152
#11 0x0000ffff48555de8 in update_textures (st=<optimized out>, shader_stage=MESA_SHADER_FRAGMENT, prog=<optimized out>) at ../mesa/src/mesa/state_tracker/st_atom_texture.c:271
#12 0x0000ffff482df3e0 in st_validate_state (pipeline_state_mask=<optimized out>, st=0xffff39424000) at ../mesa/src/util/bitscan.h:115
#13 prepare_draw (st=0xffff39424000, ctx=<optimized out>, state_mask=<optimized out>) at ../mesa/src/mesa/state_tracker/st_draw.c:88
#14 0x0000ffff482df7d0 in st_draw_gallium (ctx=0xffff39488000, info=0xffff52cacdb8, drawid_offset=0, draws=0xffff52cacda8, num_draws=1) at ../mesa/src/mesa/state_tracker/st_draw.c:141
#15 0x0000ffff48482ae8 in _mesa_draw_arrays (ctx=0xffff39488000, mode=<optimized out>, start=<optimized out>, count=<optimized out>, numInstances=<optimized out>, baseInstance=<optimized out>) at ../mesa/src/mesa/main/draw.c:1202
#16 0x0000ffff663effa4 in () at /usr/lib/firefox/libxul.so
#17 0x0000ffff663ef7e0 in () at /usr/lib/firefox/libxul.so
#18 0x0000ffff663eee18 in () at /usr/lib/firefox/libxul.so
#19 0x0000ffff665427a0 in () at /usr/lib/firefox/libxul.so
#20 0x0000ffff6a64c504 in () at /usr/lib/firefox/libxul.so
#21 0x0000ffff6a8165f4 in () at /usr/lib/firefox/libxul.so
#22 0x0000ffff6a84bc30 in () at /usr/lib/firefox/libxul.so
#23 0x0000ffff6654d680 in () at /usr/lib/firefox/libxul.so
#24 0x0000ffff6654cd1c in () at /usr/lib/firefox/libxul.so
#25 0x0000ffff6654c5e0 in () at /usr/lib/firefox/libxul.so
#26 0x0000ffff6654be7c in () at /usr/lib/firefox/libxul.so
#27 0x0000ffff66553da8 in () at /usr/lib/firefox/libxul.so
#28 0x0000ffff6599956c in () at /usr/lib/firefox/libxul.so
#29 0x0000ffff6599d1f4 in () at /usr/lib/firefox/libxul.so
#30 0x0000ffff65fe84f0 in () at /usr/lib/firefox/libxul.so
#31 0x0000ffff65f9e454 in () at /usr/lib/firefox/libxul.so
#32 0x0000ffff65997028 in () at /usr/lib/firefox/libxul.so
#33 0x0000ffff7095dfd4 in () at /usr/lib/libnspr4.so
#34 0x0000ffff70b20aec in start_thread (arg=0xffffc96390cf) at pthread_create.c:442
#35 0x0000ffff70b8a5dc in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:79
```
Debugging for a while, I found there is a concurrent access on the scene from:
- `lp_scene_end_rasterization` called by
- `lp_setup_get_empty_scene` called by
- `set_scene_state` called by
- `lp_setup_update_state` called by
- `lp_setup_draw_elements` called by
- `vbuf_flush_vertices` called by
- `draw_pipeline_flush` called by
- `draw_do_flush` called by
- `draw_flush` called by
- `_mesa_draw_arrays`
`lp_scene_is_resource_referenced` is suspicious. It operates on all contexts holding only `screen->ctx_mutex`, which protects the list of contexts but does not protect contexts themselves. Adding `ctx_mutex` lock to `lp_scene_end_rasterization` prevented from crashing:
```diff
diff --git a/src/gallium/drivers/llvmpipe/lp_scene.c b/src/gallium/drivers/llvmpipe/lp_scene.c
index df16d4a3b40..136e81bd671 100644
--- a/src/gallium/drivers/llvmpipe/lp_scene.c
+++ b/src/gallium/drivers/llvmpipe/lp_scene.c
@@ -32,6 +32,7 @@
#include "util/u_inlines.h"
#include "util/format/u_format.h"
#include "lp_scene.h"
+#include "lp_screen.h"
#include "lp_fence.h"
#include "lp_debug.h"
#include "lp_context.h"
@@ -219,6 +220,10 @@ lp_scene_begin_rasterization(struct lp_scene *scene)
void
lp_scene_end_rasterization(struct lp_scene *scene)
{
+ struct llvmpipe_screen *lp_screen = llvmpipe_screen(scene->pipe->screen);
+
+ mtx_lock(&lp_screen->ctx_mutex);
+
/* Unmap color buffers */
for (unsigned i = 0; i < scene->fb.nr_cbufs; i++) {
if (scene->cbufs[i].map) {
@@ -324,6 +329,8 @@ lp_scene_end_rasterization(struct lp_scene *scene)
scene->alloc_failed = FALSE;
util_unreference_framebuffer_state(&scene->fb);
+
+ mtx_unlock(&lp_screen->ctx_mutex);
}
```
### Regression
Commit 38a2a2da3e5f7110ac53a1ffa5fe5617553895f7 introduced the suspicious code in `llvmpipe_flush_resource`.
### Log files as attachment
### Screenshots/video files (if applicable)
### Any extra information would be greatly appreciatedhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/243[llvmpipe] gtkopengl rendering glitches2022-10-30T22:13:37ZBugzilla Migration User[llvmpipe] gtkopengl rendering glitches## Submitted by Lukas K.
Assigned to **mes..@..op.org**
**[Link to original bug (#99863)](https://bugs.freedesktop.org/show_bug.cgi?id=99863)**
## Description
Created attachment 129746
test case
On llvmpipe, GtkGLarea causes the ...## Submitted by Lukas K.
Assigned to **mes..@..op.org**
**[Link to original bug (#99863)](https://bugs.freedesktop.org/show_bug.cgi?id=99863)**
## Description
Created attachment 129746
test case
On llvmpipe, GtkGLarea causes the whole window to get messed up: https://bugzilla.gnome.org/show_bug.cgi?id=778006
Even just creating a gl context for a widget causes glitchy rendering, see the attached python script for a test case.
**Attachment 129746**, "test case":
[gltest2.py](/uploads/bdaa423693d6de1527e8981a36a7625d/gltest2.py)https://gitlab.freedesktop.org/mesa/mesa/-/issues/4489llvmpipe: high address space consumption right after initialization which inc...2021-04-14T08:33:26ZOschowallvmpipe: high address space consumption right after initialization which increases with CPU core countWith the help of @axeldavy, we've discovered that llvmpipe allocates larges chucks of virtual address space right after initialization, which increases with the available logical CPU cores the system has. Gallium-nine always initializes ...With the help of @axeldavy, we've discovered that llvmpipe allocates larges chucks of virtual address space right after initialization, which increases with the available logical CPU cores the system has. Gallium-nine always initializes llvmpipe at start-up to use it for certain d3d functions and that causes problems with 32-bit games (99% of d3d9 games) running out of address space and crashing on high core-count CPUs.
For example, the game `Dragon's Dogma: Dark Arisen` is heavily affected and is unplayable on high core-count CPUs on gallium-nine as a result. Here are some numbers of VA usage on a 16 thread CPU and on the same CPU with all but 4 logical cores disabled:
16 threads: 3900MB (frequent crashes)
4 threads: 3200MB
16 threads + LP_NUM_THREADS=1: 3200MB
16 threads + patch to disable llvmpipe in nine [1]: 2900MB
The address space cost of llvmpipe with gallium-nine can also be reproduced without the involvement of wine with the [Xnine](https://github.com/axeldavy/Xnine) triangle samples (Makefile can be modified for 32-bit builds).
Address space usage for the `triangle_SDL` sample 32-bit build:
16 threads: 930MB
4 threads: 500MB
16 threads + LP_NUM_THREADS=1: 600MB
Now, while llvmpipe's address space usage isn't a problem for 64-bit applications at all, for 32-bit apps and gallium-nine it's the difference between perfectly playable games and just crashing - and the problem is only going to get worse the more CPU threads are available, it seems. I think @axeldavy has some ideas to work-around the problem from nine, but we thought it might be worth hearing if there are ideas to limit llvmpipe's address space usage for 32-bit builds for within llvmpipe itself.
[1]
[0001-TEST-to-disable-sw-rasterizer.patch](/uploads/3f063a16f1c7bbae98cd1df0e5297e54/0001-TEST-to-disable-sw-rasterizer.patch)https://gitlab.freedesktop.org/mesa/mesa/-/issues/10732llvmpipe: hook up KHR_partial_update2024-03-02T12:13:58ZMike Blumenkrantzllvmpipe: hook up KHR_partial_updateI ran out of time in refactoring to plug this in, but it should be pretty trivial:
* copy `zink_set_damage_region`
* add a case somewhere in lp_setup to add a new scissor based on the assembled damage regionI ran out of time in refactoring to plug this in, but it should be pretty trivial:
* copy `zink_set_damage_region`
* add a case somewhere in lp_setup to add a new scissor based on the assembled damage regionhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/7331llvmpipe/lavapipe: glDispatchCompute crash in Mesa 22.22022-09-29T14:27:36Zfridenmfllvmpipe/lavapipe: glDispatchCompute crash in Mesa 22.2### System information
- OS: Windows 11
- Mesa version: 22.2
### Describe the issue
I'm launching a compute shader that reads values from three SSBOs and writes to one SSBO, but the program always crashes at glDispatchCompute and I ex...### System information
- OS: Windows 11
- Mesa version: 22.2
### Describe the issue
I'm launching a compute shader that reads values from three SSBOs and writes to one SSBO, but the program always crashes at glDispatchCompute and I expected the call to succeed as it worked in 22.1.2 and 22.2 RC2, or at least get a debug message via glDebugMessageCallback, but instead it crashes when calling glDispatchCompute. I can't attach the code from the company I work at but I've attached a screenshot of the call stack with debug symbols which hopefully narrows down the search a bit.
### Regression
The exact same program worked for 22.1.2 and 22.2 RC1.
### Log files as attachment
llvmpipe:
![mesa_22.2_llvm_compute_crash_0](/uploads/7710c6c650f53bc851741f100b4ec39f/mesa_22.2_llvm_compute_crash_0.jpg)
lavapipe:
![image](/uploads/5c2ae8a7341126f7b4086f0e85e92127/image.png)https://gitlab.freedesktop.org/mesa/mesa/-/issues/9666llvmpipe LP_DEBUG without DEBUG but DEBUG still needed2023-12-08T17:32:29ZKrzysztof Sobieckillvmpipe LP_DEBUG without DEBUG but DEBUG still neededLP_DEBUG can be used without DEBUG but in many places it uses debug_printf that if built without BUILD won't print anything.
Was it made intentional?
@anholt !21086 ???LP_DEBUG can be used without DEBUG but in many places it uses debug_printf that if built without BUILD won't print anything.
Was it made intentional?
@anholt !21086 ???https://gitlab.freedesktop.org/mesa/mesa/-/issues/6402llvmpipe/lp_state_cs.c:1398:41: error: passing 'const void *const' to paramet...2023-03-12T13:10:27ZThomas Debessellvmpipe/lp_state_cs.c:1398:41: error: passing 'const void *const' to parameter of type 'void *' discards qualifiers### System information
- OS: Ubuntu 21.10 impish
- Mesa version: `main`
- LLVM: `master`
- Clang: `master`
### Describe the issue
I get the error while building `rusticl/wip` (!15439) branch **but the bug lies in a file from `main` no...### System information
- OS: Ubuntu 21.10 impish
- Mesa version: `main`
- LLVM: `master`
- Clang: `master`
### Describe the issue
I get the error while building `rusticl/wip` (!15439) branch **but the bug lies in a file from `main` not touched by this branch**.
```bat
../src/gallium/drivers/llvmpipe/lp_state_cs.c:1398:41: error: passing 'const void *const' to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
llvmpipe_cs_update_derived(llvmpipe, info->input);
^~~~~~~~~~~
../src/gallium/drivers/llvmpipe/lp_state_cs.c:1278:69: note: passing argument to parameter 'input' here
llvmpipe_cs_update_derived(struct llvmpipe_context *llvmpipe, void *input)
```
I compile Mesa using latest LLVM/Clang I built.
I use my [`user-rusticl`](https://gitlab.com/illwieckz/i-love-compute/-/blob/master/scripts/user-rusticl) build script to build LLVM, Clang and Mesa using the `rusticl/wip` branch (see !15439).
For some unknown reason when I build Mesa using my [`user-mesa`](https://gitlab.com/illwieckz/i-love-compute/-/blob/master/scripts/user-mesa) build script (`main`) branch I don't get the error but the `rusticl/wip` branch is just based on `main` and doesn't modify this file. When I build the whole Mesa from `main` I enable more Mesa component so maybe there is a side effect in disabling or enabling components?
In all case the problematic code lives in `main` branch.
I noticed such workaround makes the build continue but this is just hiding the problem:
```patch
diff --git a/src/gallium/drivers/llvmpipe/lp_state_cs.c b/src/gallium/drivers/llvmpipe/lp_state_cs.c
index 230004d799f..ebb6d1288dd 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_cs.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_cs.c
@@ -1395,7 +1395,7 @@ static void llvmpipe_launch_grid(struct pipe_context *pipe,
memset(&job_info, 0, sizeof(job_info));
- llvmpipe_cs_update_derived(llvmpipe, info->input);
+ llvmpipe_cs_update_derived(llvmpipe, (void *) info->input);
fill_grid_size(pipe, info, job_info.grid_size);
```https://gitlab.freedesktop.org/mesa/mesa/-/issues/5127llvmpipe: lp_test_arit test failed on mips64el and x86-64(if not using sse in...2021-07-27T12:27:39ZSui Jingfengllvmpipe: lp_test_arit test failed on mips64el and x86-64(if not using sse instruction set)88/99 mesa:llvmpipe / lp_test_arit FAIL 0.27 s (exit status 1)
/home/suijingfeng/WorkSpace/mesa-20.2.6/build/src/gallium/drivers/llvmpipe/lp_test_arit
round.v1(-0.5): ref = -0, out = -1, precision = -inf bits, FAIL
roun...88/99 mesa:llvmpipe / lp_test_arit FAIL 0.27 s (exit status 1)
/home/suijingfeng/WorkSpace/mesa-20.2.6/build/src/gallium/drivers/llvmpipe/lp_test_arit
round.v1(-0.5): ref = -0, out = -1, precision = -inf bits, FAIL
round.v1(0.5): ref = 0, out = 1, precision = -inf bits, FAIL
round.v4(-0.5): ref = -0, out = -1, precision = -inf bits, FAIL
round.v4(0.5): ref = 0, out = 1, precision = -inf bits, FAIL
round.v8(-0.5): ref = -0, out = -1, precision = -inf bits, FAIL
round.v8(0.5): ref = 0, out = 1, precision = -inf bits, FAIL
similar with https://gitlab.freedesktop.org/mesa/mesa/-/issues/3264https://gitlab.freedesktop.org/mesa/mesa/-/issues/9667llvmpipe: openxray hangs while using llvmpipe driver2023-08-21T15:30:47ZKrzysztof Sobieckillvmpipe: openxray hangs while using llvmpipe driver### System information
```
System:
Host: hades Kernel: 6.4.0-1-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 13.1.0 Desktop: GNOME v: 44.3 tk: GTK v: 3.24.38 wm: gnome-shell dm: GDM3
Distro: Debian GNU/Linux trixie/sid
CPU:
In...### System information
```
System:
Host: hades Kernel: 6.4.0-1-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 13.1.0 Desktop: GNOME v: 44.3 tk: GTK v: 3.24.38 wm: gnome-shell dm: GDM3
Distro: Debian GNU/Linux trixie/sid
CPU:
Info: quad core model: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx
bits: 64 type: MT MCP arch: Zen/Zen+ note: check rev: 1 cache: L1: 384 KiB
L2: 2 MiB L3: 4 MiB
Speed (MHz): avg: 1391 high: 1395 min/max: 1400/2100 boost: enabled cores:
1: 1394 2: 1393 3: 1389 4: 1382 5: 1390 6: 1392 7: 1393 8: 1395
bogomips: 33538
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
Device-1: AMD Picasso/Raven 2 [Radeon Vega Series / Radeon Mobile Series]
vendor: Lenovo driver: amdgpu v: kernel arch: GCN-5 pcie: speed: 8 GT/s
lanes: 16 ports: active: HDMI-A-1 off: eDP-1 empty: none bus-ID: 03:00.0
chip-ID: 1002:15d8 temp: 70.0 C
Device-2: Bison Integrated Camera driver: uvcvideo type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 bus-ID: 3-1.1:4 chip-ID: 5986:1135
Display: wayland server: X.org v: 1.21.1.8 with: Xwayland v: 23.2.0
compositor: gnome-shell driver: gpu: amdgpu display-ID: 0
Monitor-1: HDMI-A-1 model: Samsung res: 3840x2160 dpi: 69
diag: 1630mm (64.2")
Monitor-2: eDP-1 model: BOE Display 0x0812 res: 1920x1080 dpi: 142
diag: 395mm (15.5")
API: OpenGL v: 4.5 Mesa 23.1.6-1 renderer: llvmpipe (LLVM 15.0.7 256 bits)
direct-render: Yes
```
### Describe the issue
While starting a "New Game" or loading save file OpenXRay(https://github.com/OpenXRay/xray-16/) (Call of Pripyat data, CS too) hangs at loading screen
### Regression
No idea, works with RadeonSI
### Log files as attachment
Output from gdb(relevant part):
[OUT](/uploads/36f0a6c55e12b852d2a8e332258f1fa4/OUT)
### Screenshots/video files (if applicable)
Screen on which it freeze
![Zrzut_ekranu_z_2023-08-20_23-27-13](/uploads/49cd7ee94713c7555ca98a51d8f5bffe/Zrzut_ekranu_z_2023-08-20_23-27-13.png)
### Any extra information would be greatly appreciatedhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/229[llvmpipe] piglit arb_shader_texture_lod-texgrad fails2019-09-25T18:03:04ZBugzilla Migration User[llvmpipe] piglit arb_shader_texture_lod-texgrad fails## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#70359)](https://bugs.freedesktop.org/show_bug.cgi?id=70359)**
## Description
mesa: 8cb9cce0400362e913ad89f4ae981b8baf86bb57 (master)
$ ./bin/arb...## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#70359)](https://bugs.freedesktop.org/show_bug.cgi?id=70359)**
## Description
mesa: 8cb9cce0400362e913ad89f4ae981b8baf86bb57 (master)
$ ./bin/arb_shader_texture_lod-texgrad -auto
Left: texture2D, Right: texture2DGradARB
Probe color at (77,76)
Left: 0.000000 0.980392 0.015686 0.000000
Right: 0.000000 0.949020 0.047059 0.000000
PIGLIT: {'result': 'fail' }
47d0613eb70b2cb5d8837fe8e12325532a7918f5 is the first bad commit
commit 47d0613eb70b2cb5d8837fe8e12325532a7918f5
Author: Roland Scheidegger <sroland@vmware.com>
Date: Sat Oct 5 03:26:47 2013 +0200
gallivm: handle explicit derivatives for cubemaps
They need some special handling. Quite complicated.
Additionally, use the same code for implicit derivatives too if no_rho_approx
and no_quad_lod is set, because it seems while generally it should be ok
to use per quad lod for implicit derivatives there's at least some test which
insists that in case of cubemaps the shared lod value MUST come from a pixel
inside the primitive (due to the derivatives becoming different if a different
larger major axis is chosen).
v2: based on Brian's feedback, clean up code a bit.
And use sign bit of major axis instead of pre-select s/t/r sign for coord
mirroring (which should be the same in the end, saves 2 ands).
Also fix two bugs with select/mirror of derivatives, the minor axes need to
use major axis sign as well (instead of major derivative axis sign), and
don't mistakenly use absolute values of major derivative and inverse major
values.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
:040000 040000 87a36fd21fb08b5f4cdba877e5c2243eee0d73ba 36fbb692f6f3af2a56e437f8afbbf027683b7072 M src
bisect run success
Version: git
### Blocking
* [Bug 79039](https://bugs.freedesktop.org/show_bug.cgi?id=79039)https://gitlab.freedesktop.org/mesa/mesa/-/issues/234[llvmpipe] piglit ext_transform_feedback-immediate-reuse-uniform-buffer regre...2019-09-25T18:03:06ZBugzilla Migration User[llvmpipe] piglit ext_transform_feedback-immediate-reuse-uniform-buffer regression## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#90081)](https://bugs.freedesktop.org/show_bug.cgi?id=90081)**
## Description
mesa: 1eac3ae1a6ebecf353054d937dd603a11ea33fb3 (master 10.6.0-devel)
...## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#90081)](https://bugs.freedesktop.org/show_bug.cgi?id=90081)**
## Description
mesa: 1eac3ae1a6ebecf353054d937dd603a11ea33fb3 (master 10.6.0-devel)
$ ./bin/ext_transform_feedback-immediate-reuse-uniform-buffer -auto
Probe color at (16,0)
Expected: 0.062500 0.937500 0.062500
Observed: 0.000000 0.000000 0.000000
Probe color at (32,0)
Expected: 0.125000 0.875000 0.125000
Observed: 0.000000 0.000000 0.000000
Probe color at (48,0)
Expected: 0.187500 0.812500 0.187500
Observed: 0.000000 0.000000 0.000000
Probe color at (64,0)
Expected: 0.250000 0.750000 0.250000
Observed: 0.000000 0.000000 0.000000
Probe color at (80,0)
Expected: 0.312500 0.687500 0.312500
Observed: 0.000000 0.000000 0.000000
Probe color at (96,0)
Expected: 0.375000 0.625000 0.375000
Observed: 0.000000 0.000000 0.000000
Probe color at (112,0)
Expected: 0.437500 0.562500 0.437500
Observed: 0.000000 0.000000 0.000000
Probe color at (128,0)
Expected: 0.500000 0.500000 0.500000
Observed: 0.000000 0.000000 0.000000
Probe color at (144,0)
Expected: 0.562500 0.437500 0.562500
Observed: 0.000000 0.000000 0.000000
Probe color at (160,0)
Expected: 0.625000 0.375000 0.625000
Observed: 0.000000 0.000000 0.000000
Probe color at (176,0)
Expected: 0.687500 0.312500 0.687500
Observed: 0.000000 0.000000 0.000000
Probe color at (192,0)
Expected: 0.750000 0.250000 0.750000
Observed: 0.000000 0.000000 0.000000
Probe color at (208,0)
Expected: 0.812500 0.187500 0.812500
Observed: 0.000000 0.000000 0.000000
Probe color at (224,0)
Expected: 0.875000 0.125000 0.875000
Observed: 0.000000 0.000000 0.000000
Probe color at (240,0)
Expected: 0.937500 0.062500 0.937500
Observed: 0.000000 0.000000 0.000000
PIGLIT: {"result": "fail" }
586536a4e1c34725b3b38c3425db569fac0c91e9 is the first bad commit
commit 586536a4e1c34725b3b38c3425db569fac0c91e9
Author: Roland Scheidegger <sroland@vmware.com>
Date: Thu Apr 9 00:49:11 2015 +0200
gallivm: don't use control flow when doing indirect constant buffer lookups
llvm goes crazy when doing that, using way more memory and time, though there's
probably more to it - this points to a very much similar issue as fixed in
8a9f5ecdb116d0449d63f7b94efbfa8b205d826f. In any case I've seen a quite
plain looking vertex shader with just ~50 simple tgsi instructions (but with a
dozen or so such indirect constant buffer lookups) go from a terribly high
~440ms compile time (consuming 25MB of memory in the process) down to a still
awful ~230ms and 13MB with this fix (with llvm 3.3), so there's still obvious
improvements possible (but I have no clue why it's so slow...).
The resulting shader is most likely also faster (certainly seemed so though
I don't have any hard numbers as it may have been influenced by compile times)
since generally fetching constants outside the buffer range is most likely an
app error (that is we expect all indices to be valid).
It is possible this fixes some mysterious vertex shader slowdowns we've seen
ever since we are conforming to newer apis at least partially (the main draw
loop also has similar looking conditionals which we probably could do without -
if not for the fetch at least for the additional elts condition.)
v2: use static vars for the fake bufs, minor code cleanups
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
:040000 040000 3d9c36f85b3f7cf81413a06ea0454a4c035ea447 9d2ff2be20f10d6f129bc3e1a9979d2a97a37a79 M src
bisect run success
Version: 10.6
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=103762https://gitlab.freedesktop.org/mesa/mesa/-/issues/7783[llvmpipe] piglit fails spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input...2023-03-15T17:43:39Zernsteiswuerfel[llvmpipe] piglit fails spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-uint_uvec4-double_dmat3x4_array2-position sanity test (Big Endian ppc64)**spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-uint_uvec4-double_dmat3x4_array2-position** fails on Big Endian ppc64 with:
```
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 177
Probe c...**spec@arb_vertex_attrib_64bit@execution@vs_in@vs-input-uint_uvec4-double_dmat3x4_array2-position** fails on Big Endian ppc64 with:
```
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 177
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 194
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 211
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 228
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 245
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 262
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 279
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 296
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 313
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 330
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 347
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 364
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 381
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 398
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 415
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 432
Probe color at (0,0)
Expected: 0 255 0 255
Observed: 255 0 0 255
Test failure on line 449
```
Machine is a Talos II + Radeon X1550:
```
$ inxi -bZ
System:
Host: T800 Kernel: 6.0.9-gentoo-P9 arch: ppc64 bits: 64 Desktop: N/A
Distro: Gentoo Base System release 2.9
Machine:
Type: PPC System: T2P9D01 REV 1.01 details: N/A
CPU:
Info: 2x 4-core POWER9 altivec supported [MT MCP SMP] speed (MHz):
avg: 2154 min/max: 2154/3800
Graphics:
Device-1: AMD RV516 [Radeon X1300/X1550 Series] driver: radeon v: kernel
Device-2: ASPEED Graphics Family driver: N/A
Device-3: N/A driver: N/A
Display: x11 server: X.org v: 1.21.1.4 driver: X: loaded: radeon
unloaded: fbdev,modesetting gpu: radeon
resolution: <missing: xdpyinfo/xrandr> resolution: 1920x1080
OpenGL: renderer: llvmpipe (LLVM 15.0.5 128 bits)
v: 4.5 Mesa 22.3.0-rc4 (git-e16ab1b4cb)
$ glxinfo | grep -i opengl
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 15.0.5, 128 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 22.3.0-rc4 (git-e16ab1b4cb)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.5 (Compatibility Profile) Mesa 22.3.0-rc4 (git-e16ab1b4cb)
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.3.0-rc4 (git-e16ab1b4cb)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
```
Sanity testrun was done with _LIBGL_ALWAYS_SOFTWARE=1_. The other 29 sanity tests pass on llvmpipe. Results + Summary attached. [soft_22.3-rc4.tar.bz2](/uploads/84eb8a6cedfe8d9f06f0fb15bcfb0c47/soft_22.3-rc4.tar.bz2)https://gitlab.freedesktop.org/mesa/mesa/-/issues/230[llvmpipe] piglit gl-1.4-polygon-offset regression2019-09-25T18:03:05ZBugzilla Migration User[llvmpipe] piglit gl-1.4-polygon-offset regression## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#71199)](https://bugs.freedesktop.org/show_bug.cgi?id=71199)**
## Description
mesa: fa8b1514d31d1ffb3d9e2a208ac7d1bd774754b2 (master)
$ ./bin/glea...## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#71199)](https://bugs.freedesktop.org/show_bug.cgi?id=71199)**
## Description
mesa: fa8b1514d31d1ffb3d9e2a208ac7d1bd774754b2 (master)
$ ./bin/glean -t polygonOffset --quick
polygonOffset: FAIL rgba8, db, z24, s8, accrgba16, win+pmap, id 33
Actual MRD is too small (may cause incorrect results)
Ideal MRD at near plane is 1.19209e-07 (nominally 2 bits)
Actual MRD at near plane is 5.96046e-08 (nominally 1 bit)
Ideal MRD at infinity is 3.06118e-08 (nominally 1 bit)
Actual MRD at infinity is 5.96046e-08 (nominally 1 bit)
be0b67a1436eb2b899f9874725b2a68eb26f9f3f is the first bad commit
commit be0b67a1436eb2b899f9874725b2a68eb26f9f3f
Author: Matthew McClure <mcclurem@vmware.com>
Date: Tue Oct 22 15:48:00 2013 -0700
util,llvmpipe: correctly set the minimum representable depth value
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
:040000 040000 705fdddb5369a190f9fa393549692d5d05dd5d5b 0e7c6c6eb72429cbdceb2b3b85673b48c25ed5eb M src
bisect run success
Version: git
### Blocking
* [Bug 79039](https://bugs.freedesktop.org/show_bug.cgi?id=79039)https://gitlab.freedesktop.org/mesa/mesa/-/issues/235[llvmpipe] piglit glsl-max-varyings >max_varying_components regression2019-09-25T18:03:07ZBugzilla Migration User[llvmpipe] piglit glsl-max-varyings >max_varying_components regression## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#91099)](https://bugs.freedesktop.org/show_bug.cgi?id=91099)**
## Description
mesa: e31bce4041122cd00712b60b4dc1eae6486f6579 (master 10.7.0-devel)
...## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#91099)](https://bugs.freedesktop.org/show_bug.cgi?id=91099)**
## Description
mesa: e31bce4041122cd00712b60b4dc1eae6486f6579 (master 10.7.0-devel)
$ ./bin/glsl-max-varyings --exceed-limits -auto
Vertical axis: Increasing numbers of varyings.
Horizontal axis: Which of the varyings contains the color.
GL_MAX_VARYING_FLOATS = 128
glsl-max-varyings: src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4655: ureg_dst dst_register(st_translate*, gl_register_file, unsigned int, unsigned int): Assertion `index < VARYING_SLOT_MAX' failed.
Aborted (core dumped)
```
(gdb) bt
#0 0x00007fc07799b267 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007fc07799ceca in __GI_abort () at abort.c:89
#2 0x00007fc07799403d in __assert_fail_base (fmt=0x7fc077af6028 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7fc076a3e67b "index < VARYING_SLOT_MAX", file=file@entry=0x7fc076a3d708 "src/mesa/state_tracker/st_glsl_to_tgsi.cpp",
line=line@entry=4655,
function=function@entry=0x7fc076a3ff00 <dst_register(st_translate*, gl_register_file, unsigned int, unsigned int)::__PRETTY_FUNCTION__> "ureg_dst dst_register(st_translate*, gl_register_file, unsigned int, unsigned int)") at assert.c:92
#3 0x00007fc0779940f2 in __GI___assert_fail (assertion=0x7fc076a3e67b "index < VARYING_SLOT_MAX",
file=0x7fc076a3d708 "src/mesa/state_tracker/st_glsl_to_tgsi.cpp", line=4655,
function=0x7fc076a3ff00 <dst_register(st_translate*, gl_register_file, unsigned int, unsigned int)::__PRETTY_FUNCTION__> "ureg_dst dst_register(st_translate*, gl_register_file, unsigned int, unsigned int)") at assert.c:101
#4 0x00007fc075bebc69 in dst_register (t=0xc31420, file=PROGRAM_OUTPUT, index=56, array_id=0) at src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4655
#5 0x00007fc075bec3aa in translate_dst (t=0xc31420, dst_reg=0xcda7d8, saturate=false, clamp_color=false)
at src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4756
#6 0x00007fc075becb15 in compile_tgsi_instruction (t=0xc31420, inst=0xcda7c0, clamp_dst_color_output=false)
at src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4904
#7 0x00007fc075beef45 in st_translate_program (ctx=0x7fc0784fe010, procType=1, ureg=0xe79180, program=0xe26870, proginfo=0xf08070, numInputs=3,
inputMapping=0xf08448, inputSlotToAttr=0x0, inputSemanticName=0x0, inputSemanticIndex=0x0, interpMode=0x0, interpLocation=0x0, numOutputs=33,
outputMapping=0xf08610, outputSlotToAttr=0xf086f0, outputSemanticName=0xf087d0 "", outputSemanticIndex=0xf08808 "", passthrough_edgeflags=0 '\000',
clamp_color=0 '\000') at src/mesa/state_tracker/st_glsl_to_tgsi.cpp:5581
#8 0x00007fc075a68de5 in st_translate_vertex_program (st=0xa64210, stvp=0xf08070, key=0x7ffe56dacd60) at src/mesa/state_tracker/st_program.c:348
#9 0x00007fc075a69027 in st_get_vp_variant (st=0xa64210, stvp=0xf08070, key=0x7ffe56dacd60) at src/mesa/state_tracker/st_program.c:440
#10 0x00007fc075bbe1f2 in update_vp (st=0xa64210) at src/mesa/state_tracker/st_atom_shader.c:158
#11 0x00007fc075bb925b in st_validate_state (st=0xa64210) at src/mesa/state_tracker/st_atom.c:214
#12 0x00007fc075a63e73 in st_draw_vbo (ctx=0x7fc0784fe010, prims=0x7ffe56dacf70, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0,
max_index=3, tfb_vertcount=0x0, indirect=0x0) at src/mesa/state_tracker/st_draw.c:199
#13 0x00007fc075ba6212 in vbo_draw_arrays (ctx=0x7fc0784fe010, mode=5, start=0, count=4, numInstances=1, baseInstance=0)
at src/mesa/vbo/vbo_exec_array.c:645
#14 0x00007fc075ba6ca0 in vbo_exec_DrawArrays (mode=5, start=0, count=4) at src/mesa/vbo/vbo_exec_array.c:797
#15 0x0000000000401ef2 in draw (num_varyings=33) at piglit/tests/shaders/glsl-max-varyings.c:233
#16 0x000000000040208c in piglit_display () at piglit/tests/shaders/glsl-max-varyings.c:273
#17 0x00007fc078067f8e in run_test (gl_fw=0x976980, argc=2, argv=0x7ffe56dad448)
at piglit/tests/util/piglit-framework-gl/piglit_winsys_framework.c:79
#18 0x00007fc07804c999 in piglit_gl_test_run (argc=2, argv=0x7ffe56dad448, config=0x7ffe56dad300)
at piglit/tests/util/piglit-framework-gl.c:191
#19 0x00000000004014fd in main (argc=2, argv=0x7ffe56dad448) at piglit/tests/shaders/glsl-max-varyings.c:48
(gdb) frame 4
#4 0x00007fc075bebc69 in dst_register (t=0xc31420, file=PROGRAM_OUTPUT, index=56, array_id=0) at src/mesa/state_tracker/st_glsl_to_tgsi.cpp:4655
4655 assert(index < VARYING_SLOT_MAX);
(gdb) print /d VARYING_SLOT_MAX
$1 = 56
```
Version: 10.6
### Blocking
* [Bug 90539](https://bugs.freedesktop.org/show_bug.cgi?id=90539)https://gitlab.freedesktop.org/mesa/mesa/-/issues/241[llvmpipe] piglit linestipple regression2022-10-30T22:13:36ZBugzilla Migration User[llvmpipe] piglit linestipple regression## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#96518)](https://bugs.freedesktop.org/show_bug.cgi?id=96518)**
## Description
mesa: 4825264f75c83576f251290547f121f066b46a70 (master 12.1.0-devel)
...## Submitted by Vinson Lee
Assigned to **mes..@..op.org**
**[Link to original bug (#96518)](https://bugs.freedesktop.org/show_bug.cgi?id=96518)**
## Description
mesa: 4825264f75c83576f251290547f121f066b46a70 (master 12.1.0-devel)
$ ./bin/linestipple -auto
Testing Baseline:
PIGLIT: {"subtest": {"Baseline" : "pass"}}
Testing Restarting lines within a single Begin-End block:
PIGLIT: {"subtest": {"Restarting lines within a single Begin-End block" : "pass"}}
Testing Line strip:
Probe color at (34,20)
Expected: 0.000000 0.000000 0.000000
Observed: 1.000000 1.000000 0.000000
PIGLIT: {"subtest": {"Line strip" : "fail"}}
Testing Line loop:
PIGLIT: {"subtest": {"Line loop" : "pass"}}
Testing Factor 2x:
PIGLIT: {"subtest": {"Factor 2x" : "pass"}}
Testing Factor 3x:
PIGLIT: {"subtest": {"Factor 3x" : "pass"}}
PIGLIT: {"result": "fail" }
320d1191c61a0a82444605c12e5c4b2ee0b241eb is the first bad commit
commit 320d1191c61a0a82444605c12e5c4b2ee0b241eb
Author: Jose Fonseca <jfonseca@vmware.com>
Date: Mon Apr 4 00:05:33 2016 +0100
gallivm: Use llvm.fmuladd.*.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
:040000 040000 31dca10c80a2741d596cb6d81cd6015e1312dc2e e24948d177adab4b2fc35cd186d8dbffec3f3a0d M src
bisect run success
Version: 13.0
### Blocking
* [Bug 98471](https://bugs.freedesktop.org/show_bug.cgi?id=98471)https://gitlab.freedesktop.org/mesa/mesa/-/issues/6214llvmpipe: RFE -- add missing subgroup operation "SHUFFLE"2022-04-22T16:02:29ZAllan MacKinnonllvmpipe: RFE -- add missing subgroup operation "SHUFFLE"I'd like to bring up my compute-heavy libraries on llvmpipe but need `SUBGROUP_FEATURE_SHUFFLE_BIT`.
The rest would be nice to have too.
Not implemented:
```
SUBGROUP_FEATURE_SHUFFLE_BIT
SUBGROUP_FEATURE_SHUFFLE_RELATIVE_BIT
SUBGROUP_...I'd like to bring up my compute-heavy libraries on llvmpipe but need `SUBGROUP_FEATURE_SHUFFLE_BIT`.
The rest would be nice to have too.
Not implemented:
```
SUBGROUP_FEATURE_SHUFFLE_BIT
SUBGROUP_FEATURE_SHUFFLE_RELATIVE_BIT
SUBGROUP_FEATURE_CLUSTERED_BIT
SUBGROUP_FEATURE_QUAD_BIT
```