Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

squeaks · 2022-05-28 18:32:42

I'm having a problem with a program called FreeCAD where the 3d viewer is very laggy. The rest of the application seems fine and responsive, but whenever I try to draw, rotate, pan, etc in the 3d view, it becomes laggy and the fps is < 3, usually between 1-3 fps. I know this is a bug because FreeCAD is not known to be hard to run, and it runs perfectly fine on my other video card, a gtx 1070, where it runs at the refresh rate of whichever monitor it is on.

I suspect there is a locking problem caused by possibly a resource being unavailable. Where should I file a bug report?

To reproduce the problem,

I run FreeCAD which will hang if I don't require it to use xcb:

$ QT_QPA_PLATFORM=xcb ./FreeCAD --log-file `pwd`/`logdate`FreeCAD390.log

I then click new document, click create body, click create sketch, click XY_Plane in 3d view (which is laggy to select) and then Sketcher opens, then i click create circle, click in 3d view to initiate a new circle, drag and click to make the circle, then right click.

Now I have a circle like in the first image. Then I start a trace:
$ sudo strace -r -f --decode-fds=path,socket,dev,pidfd --decode-pids=comm -tt -v -T -C -o `logdate`strace_390.log -p $PID

Then I click and hold, and drag the circle in a direction and stop. Then I ctrl-c the trace.

I have tried the following:
amdgpu driver, radeon driver, amdgpu-pro (running progl FreeCAD).
Unplugging all but one monitor, rebooting, and running FreeCAD.
I've tried Xorg with xfce on another operating system.
amdgpu.dc=0,
amdgpu.dpm=0,
amdgpu.ex_hw_support=1.
I've compiled the upstream FreeCAD, which is where my logs are from.

Is it possible that having the amd r9 390 card in the 2nd pcie slot is a problem? I can imagine some loss of performance because I think the slot is x4 when I have my 1070 in the #1 pcie slot, but I observe this problem only in this specific application.

I've been trying piglit out and I get some failures. Piglit did hang on the gpu tests. It hung on ext_texture_env_combine-combine -auto -fbo, where strace indicates a deadlock loop. Piglit also crashed the video card when I ran all tests.

Operating System: Arch Linux
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.17.9-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor
Memory: 62.8 GiB of RAM
Graphics Processor: AMD Radeon R9 390 Series

dmesg

FreeCAD log

strace FreeCAD
At the bottom of the strace is the futex %time, which if you remove the polls which happen while no 3d movement is happening, results in very high 90+% futex time.

strace FreeCAD
This is an earlier strace I made, without the -T option. This trace makes it easier to see the total time taken for system call because there is one line per call, instead of showing different threads in between the start and end of a call.
I find lines like:
0.151194 ioctl(9, DRM_IOCTL_AMDGPU_WAIT_CS, 0x7fff60aa0d60) = 0
and
0.000037 futex(0x7fff60aa1888, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = -1 EAGAIN (Resource temporarily unavailable)

to be interesting. That is quite a long ioctl call. 151ms would already make for a < 10 fps.

Anyway, can anyone offer thoughts on whether this is a mesa, amdgpu, kernel, drm, or what kind of bug?

Last edited by squeaks (2022-05-28 18:54:10)

squeaks · 2022-05-28 20:56:13

glxinfo -B

[user-arch@antec-arch amdgpu]$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon R9 390 Series (hawaii, LLVM 13.0.1, DRM 3.44, 5.17.9-arch1-1) (0x67b1)
    Version: 22.1.0
    Accelerated: yes
    Video memory: 8192MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 6081 MB, largest block: 6081 MB
    VBO free aux. memory - total: 8079 MB, largest block: 8079 MB
    Texture free memory - total: 6081 MB, largest block: 6081 MB
    Texture free aux. memory - total: 8079 MB, largest block: 8079 MB
    Renderbuffer free memory - total: 6081 MB, largest block: 6081 MB
    Renderbuffer free aux. memory - total: 8079 MB, largest block: 8079 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 8192 MB
    Total available memory: 16384 MB
    Currently available dedicated video memory: 6081 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon R9 390 Series (hawaii, LLVM 13.0.1, DRM 3.44, 5.17.9-arch1-1)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.1.0
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.1.0
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.1.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

This piglit test never completes, it just seems to look similar to my FreeCAD problem.
strace -r --decode-fds=path,socket,dev,pidfd --decode-pids=comm -tt -v -T -C -o ~/Documents/Code/amdgpu/`logdate`_strace_ext_texture_env_combine-combine ./bin/ext_texture_env_combine-combine --auto -fbo
https://gist.github.com/preasumiturreus … 92f8aaadae

Last edited by squeaks (2022-05-28 20:58:47)

Lone_Wolf · 2022-05-31 11:09:01

Impossible to say where to file a bug report without first narrowing down possible causes .

Command line: BOOT_IMAGE=/@/vmlinuz-linux root=UUID=7b1fdb45-1f0e-476a-a3cf-e8496a016e79 rw rootflags=subvol=@/.snapshots/1/snapshot fbcon=map:1 vfio-pci.ids=10de:1b81,10de:10f0 radeon.cik_support=0 amdgpu.cik_support=1 cryptdevice=UUID=92d82e93-487b-49a4-ad83-81ad126c8980:cryptnvme_root root=/dev/mapper/cryptnvme_root

Looks like you are passing through the nvidia card, making the amd card the primary one.

Some motherboards / chipsets need the primary card to be in the primary PCIe slot for full functionality .
Have you tried with :
r390 in primary slot, nvidia card in secondary slot ?
just the r390 card present in primary slot and no other card in the system ?

Last edited by Lone_Wolf (2022-05-31 11:09:57)

squeaks · 2022-06-01 03:00:30

Lone_Wolf wrote:

Have you tried with :
r390 in primary slot, nvidia card in secondary slot ?
just the r390 card present in primary slot and no other card in the system ?

I have moved the r390 to the primary slot, nvidia in secondary slot. I have not tried just the 390 present. I will do that. Before I do, I will summarize what else I've tried...

I've done some investigation of the FreeCAD source, running FreeCAD in a debugger. On my Kwin system, by default, FreeCAD runs as a wayland application.

1. FreeCAD has an option Preferences > Display: "Use software opengl" which is not honored. FreeCAD calls QApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);
I know it is not honored because when I run

$ WAYLAND_DEBUG=1 FreeCAD |& tee `logdate`390wayland.out

The output of lsof /dev/dri/renderD128 indicates hardware acceleration:

...snip...
FreeCAD   93234 user-arch  mem    CHR 226,128           240 /dev/dri/renderD128
FreeCAD   93234 user-arch    6u   CHR 226,128      0t0  240 /dev/dri/renderD128
FreeCAD   93234 user-arch    7u   CHR 226,128      0t0  240 /dev/dri/renderD128
FreeCAD   93234 user-arch    8u   CHR 226,128      0t0  240 /dev/dri/renderD128
FreeCAD   93234 user-arch    9u   CHR 226,128      0t0  240 /dev/dri/renderD128

FreeCAD log https://gist.github.com/preasumiturreus … d893bbea20
wayland log https://gist.github.com/preasumiturreus … 918ef0e632

Log: OpenGL version is: 4.6 ((null))

In this method, FreeCAD shows it's splash screen, loads the main UI, and accepts input to create a new document, but when the 3d view window opens it hangs... it is unresponsive to inputs, the entire program window changes to the application not responding color (brightens). It seems to go back to normal color after a while but still not respond to input, then brighten again. Clicking the X, top right corner will close.

2. Forcing FreeCAD to run as an xwayland application is better than option 1. The program works functionally, but poor 3d view performance. Curiously, moving the 390 card from pcie slot 2 to pcie slot 1 improved fps by double for this method: from ~3 fps to ~7 fps. Motherboard documentation tells me pcie_1 is x16 and pcie_2 is x4.

$ QT_QPA_PLATFORM=xcb ~/Documents/GitHub/FreeCAD/build/bin/FreeCAD --log-file `logdate`FreeCAD_xcb.log

lsof /dev/dri/renderD128 does include FreeCAD, indicating hardware acceleration. When dragging a drawing object across the screen, radeontop shows the graphics pipe and shader clock go to 100% and other statistics < 10%; then ceasing to move the object values are < 10%, shader clock at idle frequency.

Log: OpenGL version is: 4.6 (4.6 (Compatibility Profile) Mesa 22.1.0)

FreeCAD log https://gist.github.com/preasumiturreus … b62c9a267b

3. FreeCAD with opengl software rendering forced. FreeCAD runs as a wayland application. 3d view performance is smooth until the shape is moved a long distance quickly. CPU usage is ~800% and 30 Watts.

$ LIBGL_ALWAYS_SOFTWARE=true ~/Documents/GitHub/FreeCAD/build/bin/FreeCAD --log-file `logdate`FreeCAD_libglsoftware.log

lsof /dev/dri/renderD128 does not show FreeCAD.

Log: OpenGL version is: 4.5 ((null))

FreeCAD log https://gist.github.com/preasumiturreus … ce2f5944da
The log shows variable numbers of "Log: Sketcher::Solve()-DogLeg-T:0" between redraws. Basically I noticed fast motion dropped fps and so I moved fast and slowly. The "Log: actualRedrawStart" are logging commands I added to FreeCAD.

void View3DInventorViewer::actualRedraw()
{
    Base::Console().Log("actualRedrawStart\n");
    switch (renderType) {
    case Native:
        renderScene();
        break;
    case Framebuffer:
        renderFramebuffer();
        break;
    case Image:
        renderGLImage();
        break;
    }
    Base::Console().Log("ENDActualRedraw\n");
}

4. FreeCAD with software rendering and as an xwayland application. Performance is best this way, there is no drop in fps when moving object quickly. FPS is 70-110, dependent mostly on application window size. CPU usage is ~500% and 20 Watts.

$ QT_QPA_PLATFORM=xcb LIBGL_ALWAYS_SOFTWARE=true ~/Documents/GitHub/FreeCAD/build/bin/FreeCAD --log-file `logdate`FreeCAD_xcb_libglsoftware.log

lsof /dev/dri/renderD128 does not show FreeCAD.

Log: OpenGL version is: 4.5 (4.5 (Compatibility Profile) Mesa 22.1.0)

FreeCAD log https://gist.github.com/preasumiturreus … 1188afdf9b

I found the libGL variable option at https://docs.mesa3d.org/envvars.html
I probably found the QT_QPA_PLATFORM=xcb variable option in QT5 documentation.

It's curious that the FreeCAD logs report different openGL versions.

I'm going to go pull the nvidia card and repeat these tests.

squeaks · 2022-06-01 08:40:24

I repeated all the tests and it's the same with the amd card in pcie slot 1 and no other cards installed.

Lone_Wolf · 2022-06-01 15:23:02

That seems to rule out anything hardware related as possible cause. (including nvidia - amd conflicts)

looking at kernel level now

squeaks wrote:

I have tried the following:
amdgpu driver, radeon driver, amdgpu-pro (running progl FreeCAD).

Where you say radeon driver was that xf86-video-ati or with the radeon kernel module ?
If the former, please try with the radeon kernel module .

Does the issue also occur with an older kernel like linux-lts ?

Last edited by Lone_Wolf (2022-06-01 15:23:34)

squeaks · 2022-06-02 04:12:56

Lone_Wolf wrote:

Where you say radeon driver was that xf86-video-ati or with the radeon kernel module ?
If the former, please try with the radeon kernel module .

I do not have xf86-video-ati installed. I edited the grub line "radeon.cik_support=0 amdgpu.cik_support=1" to "radeon.cik_support=1 amdgpu.cik_support=0". And of course I had to de-blacklist radeon by renaming /etc/modprobe.d/radeon.conf to radeon.conf.bak. I've simply left the radeon.conf.bak because I don't think it's causing any issue.

$ lsmod | grep -i radeon
radeon               1880064  0
...
$ cat /proc/fb 
0 amdgpudrmfb

I do find it curious that radeon still appears in Dmesg as [ 7.100780] [drm] radeon kernel modesetting enabled.

I've proven to myself this is caused by May 25 20:28:34 antec-arch sudo[27731]: user-arch : TTY=pts/8 ; PWD=/etc/modprobe.d ; USER=root ; COMMAND=/usr/bin/mv radeon.conf radeon.conf.bak

And ever since, "[drm] radeon kernel modesetting enabled." appears in the journal at boot time. ($ journalctl -g radeon)

It makes it easier to try radeon driver at boot time not to blacklist it, instead using kernel options.

Lone_Wolf wrote:

Does the issue also occur with an older kernel like linux-lts ?

Yes, it occurs with linux-lts (5.15), and an aur linux-lts54. I tried to boot linux-lts419 but received a kernel panic, initramfs unpacking failed: junk in compressed archive.

I know you said let's try to debug a kernel problem, but the scope of that I'm unsure. I'm not too familiar with historical developments, for instance where historically the DRI/DRM changes occurred. Gallium, winsys, etc. I think the scope of where the problem could be is pretty large. It could still be a QT5 or FreeCAD problem, including some drawing library.

I think this problem has probably been around since 2019, as a shot in the dark. FreeCAD Forum here someone complained about the performance degredation. His hardware is similar to mine.

Debian 9 mesa-utils version, for instance.

Last edited by squeaks (2022-06-02 04:13:09)

Lone_Wolf · 2022-06-02 08:32:42

I do find it curious that radeon still appears in Dmesg as [ 7.100780] [drm] radeon kernel modesetting enabled.

No idea why, but that is common for cards supported by radeon kernel module when used with amdgpu.

The thread on freecad forum you linked in #7 mentions UI performance issues in almost every part of freecad, your issues are limited to the 3d view, right ?

I know you said let's try to debug a kernel problem, but the scope of that I'm unsure. I'm not too familiar with historical developments, for instance where historically the DRI/DRM changes occurred. Gallium, winsys, etc. I think the scope of where the problem could be is pretty large. It could still be a QT5 or FreeCAD problem, including some drawing library.

I should have been more precise : I doubt this is a kernel level problem, but needed more info to confirm / deny that.

Going to try to summarize what (I think) is known now :

There's an issue with 3d view in freecad on an Amd R9 390.

The issue doesn't occur on native X or Wayland, only on XWayland .
When using software rendering on XWayland the issue is not present.

Potential hardware low level causes have been eliminated by testing.

Use of radeon or amdgpu kernel modules doesn't affect the issue.

LTS Kernels 5.15 and 5.4 also have the issue.

There are huge differences in design and history between radeon & amdgpu.
An issue that is present with both is very likely to be on a lower level OR a higher level .

Also there have been major changes in the kernel graphics system since 5.4 .

Combined all the above points to a higher level issue.

In mesa your card is driven by the radeonsi driver (it works with both amdgpu and radeon kernel modules) .
This makes it a likely suspect.
However if mesa radeonsi was the cause, I would expect the issue to occur on all of X, Wayland and XWayland .

That suggests XWayland as next suspect .

NOTE:
The above depends heavily on assumptions I made in/during analysing the available info .
In case one or more of those assumptions are wrong, the whole analysis could be worthless or need to be redone.

Squeaks and thread followers, please check my analysis.

squeaks · 2022-06-02 12:54:48

Lone_Wolf wrote:

The thread on freecad forum you linked in #7 mentions UI performance issues in almost every part of freecad, your issues are limited to the 3d view, right ?

My issues are limited to the 3d view, I think his description of his problem was more vague but without certainty I think his were also limited to 3d view. He describes his process to create the problem in the same way.

I'll mark my proofs as (1-4).

Lone_Wolf wrote:

Going to try to summarize what (I think) is known now :
There's an issue with 3d view in freecad on an Amd R9 390.
The issue doesn't occur on native X or Wayland, only on XWayland .
When using software rendering on XWayland the issue is not present.

Not quite correct. The issue doesn't occur on native X, XWayland(4), or Wayland(3) with LIBGL_ALWAYS_SOFTWARE=true (software rendering).

In native X and Xwayland(2) (latter by QT_QPA_PLATFORM=xcb), the issue occurs (the 3d view operates at 3-7 fps when an object is being created, panned, or moved).

The application just doesn't work in Wayland(1), it hangs loading 3d view, without error, just not responding.

I reconfirmed the native X results in Arch, just now. I hadn't used native X in arch, but I had tested in native X on another similar distro. There is no difference in symptoms between native X and Xwayland.

So per your analysis, I think mesa radeonsi is a possible cause.

I'm wondering if there is a configuration problem.

Lone_Wolf · 2022-06-04 10:22:53

For clarity :

When using LIBGL_ALWAYS_SOFTWARE=true the issue is not present ?

Without software rendering all 3 platforms ( x, wayland , xwayland ) have issues ?

LIBGL_ALWAYS_SOFTWARE=true uses swrast aka llvmpipe which does all rendering on the cpu, so this does point to an issue in mesa radeonsi.

Can you try with mesa-git from aur to verify whether the issue is still present in latest trunk builds ?

squeaks · 2022-06-05 14:39:44

Lone_Wolf wrote:

For clarity :
When using LIBGL_ALWAYS_SOFTWARE=true the issue is not present ?
Without software rendering all 3 platforms ( x, wayland , xwayland ) have issues ?

Yes correct.

I tried with mesa-git. mesa-git-22.2.0_devel.154893.f160a3b2d67a.d41d8cd98f00b204e9800998ecf8427e-1-x86_64.pkg.tar.zst

I'm trying to verify that I properly built against aur llvm-minimal-git. I don't think I did.

[user-arch@antec-arch mesa-git]$ printenv | grep -i LLVM
MESA_WHICH_LLVM=1
[user-arch@antec-arch mesa-git]$ echo $CHROOT
/home/user-arch/Documents/Code/ABS/chroot
[user-arch@antec-arch mesa-git]$ makechrootpkg -c -r $CHROOT

Then I installed mesa-git with pacman -U <mesa-git....tar.zst>

I re-tested and the behavior is the same as with extra/mesa.

[user-arch@antec-arch mesa-git]$ pacman -Qi mesa-git 
Name            : mesa-git
Version         : 22.2.0_devel.154891.4b3afed35a2.d41d8cd98f00b204e9800998ecf8427e-1
Description     : an open-source implementation of the OpenGL specification, git version
Architecture    : x86_64
URL             : https://www.mesa3d.org
Licenses        : custom
Groups          : None
Provides        : mesa  opencl-mesa  vulkan-intel  vulkan-radeon  vulkan-mesa-layer  libva-mesa-driver  mesa-vdpau
                  vulkan-swrast  vulkan-driver  mesa-libgl  opengl-driver  opencl-driver
Depends On      : libdrm  libxxf86vm  libxdamage  libxshmfence  libelf  libomxil-bellagio  libunwind  libglvnd  wayland
                  lm_sensors  libclc  vulkan-icd-loader  zstd  expat  [b]llvm-libs=13.0.1[/b]
Optional Deps   : opengl-man-pages: for the OpenGL API man pages
                  clang: opencl [installed]
                  compiler-rt: opencl [installed]
Required By     : cogl  fbida  glmark2-git  gputest  gst-plugins-base-libs  gtk3  libglvnd  mpv  qemu-ui-opengl
                  qemu-vhost-user-gpu  qt5-base  qt6-base  virglrenderer  weston  xorg-server-devel  zoom

I'm now trying to actually compile mesa-git against aur llvm-minimal git. I will build https://aur.archlinux.org/llvm-minimal-git.git in the chroot. Then install it to the chroot: makechrootpkg -c -r $CHROOT -I llvm-minimal-git-<someversion>.pkg.tar.zst. I suspect it will tell me it replaces llvm-libs, and I will replace llvm-libs. Then I will makechrootpackage in the mesa-git directory, and re-install that package to my system.

After setting MESA_WHICH_LLVM=1, I expected makechrootpkg to obtain the correct llvm and build it, or at least give me an error for missing dependency and stop. But an installable mesa-git package was created I think against llvm-libs-13.0.1.

squeaks · 2022-06-05 23:47:10

I was unable to build llvm-minimal-git in a clean chroot. What I found in the check.log does not appear to be something I did wrong.

  
[user-arch@antec-arch llvm-minimal-git]$ echo $CHROOT 
/home/user-arch/Documents/Code/ABS/chroot  
[user-arch@antec-arch llvm-minimal-git]$ makechrootpkg -c -r $CHROOT
...
/build/llvm-minimal-git/src/llvm-project/clang/include/clang/AST/DeclObjC.h:1043:30: warning: the address '&clang::ObjCMethodDecl::isClassMethod' will never be NULL [-Waddress]
 1043 |                              &ObjCMethodDecl::isClassMethod>;
      |                              ^
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in check().
    Aborting...
==> ERROR: Build failed, check /home/user-arch/Documents/Code/ABS/chroot/user-arch/build

What I think is relevant from check.log:

[11/155] Building CXX object tools/clang/tools/extra/unittests/clang-apply-replacements/CMakeFiles/ClangApplyReplacementsTests.dir/ApplyReplacementsTest.cpp.o
[12/155] Linking CXX executable tools/clang/tools/extra/pseudo/unittests/ClangPseudoTests
FAILED: tools/clang/tools/extra/pseudo/unittests/ClangPseudoTests 
: && /usr/bin/c++ -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wmisleading-indentation -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now    -Wl,--gc-sections tools/clang/tools/extra/pseudo/unittests/CMakeFiles/ClangPseudoTests.dir/BracketTest.cpp.o tools/clang/tools/extra/pseudo/unittests/CMakeFiles/ClangPseudoTests.dir/DirectiveTreeTest.cpp.o tools/clang/tools/extra/pseudo/unittests/CMakeFiles/ClangPseudoTests.dir/ForestTest.cpp.o tools/clang/tools/extra/pseudo/unittests/CMakeFiles/ClangPseudoTests.dir/GLRTest.cpp.o tools/clang/tools/extra/pseudo/unittests/CMakeFiles/ClangPseudoTests.dir/GrammarTest.cpp.o tools/clang/tools/extra/pseudo/unittests/CMakeFiles/ClangPseudoTests.dir/LRTableTest.cpp.o tools/clang/tools/extra/pseudo/unittests/CMakeFiles/ClangPseudoTests.dir/TokenTest.cpp.o -o tools/clang/tools/extra/pseudo/unittests/ClangPseudoTests  -Wl,-rpath,/build/llvm-minimal-git/src/_build/lib  lib/libllvm_gtest_main.a  lib/libllvm_gtest.a  lib/libclang-cpp.so.15  lib/libclangPseudo.a  lib/libclangPseudoGrammar.a  -lpthread  lib/libclangLex.a  lib/libclangBasic.a  lib/libLLVM-15.so && :
/usr/bin/ld: tools/clang/tools/extra/pseudo/unittests/CMakeFiles/ClangPseudoTests.dir/BracketTest.cpp.o: in function `clang::pseudo::verifyBrackets(llvm::StringRef) [clone .localalias]':
BracketTest.cpp:(.text._ZN5clang6pseudo14verifyBracketsEN4llvm9StringRefE+0x122): undefined reference to `llvm::Annotations::Annotations(llvm::StringRef)'
collect2: error: ld returned 1 exit status
[13/155] Building CXX object tools/clang/tools/extra/include-cleaner/unittests/CMakeFiles/ClangIncludeCleanerTests.dir/WalkASTTest.cpp.o

check log
build log

llvm-minimal-git-15.0.0_r425684.3583826bb52a-1-x86_64-pkgver.log : 15.0.0_r425684.3583826bb52a

I may try to build another llvm package in the chroot. I want to make somewhat sure that I can correctly use the tools so I am confident when I discuss errors.

Oh, is there way to make mesa use less or no threads? That's one big difference between running FreeCAD on nvidia vs amdgpu was that pstree indicated many threads (a dozen or so) in the amdgpu case. I just thought maybe it'd be something to try.

Last edited by squeaks (2022-06-05 23:47:27)

squeaks · 2022-06-06 03:55:49

Good news, I think I'm learning.

I was able to build packages for llvm in the following way, using --nocheck option:

[user-arch@antec-arch llvm-minimal-git]$ makechrootpkg -c -r $CHROOT -I llvm-libs-minimal-git-15.0.0_r425694.3f33d67d8a5c-1-x86_64.pkg.tar.zst -I llvm-minimal-git-15.0.0_r425694.3f33d67d8a5c-1-x86_64.pkg.tar.zst -- --nocheck

I have learned that this is silly. That command rebuilds the llvm-minimal-git package, but it does install the two packages which are just a couple hours old versions of llvm-minimal-git that I specify with -I options to my user-arch chroot.

Then, I build the mesa-git package as follows, omitting the -c option to prevent my user-arch chroot from removing the llvm-minimal-git packages and replacing them with llvm-libs. Also, the -I specified packages update the chroot to include the updated versions of llvm-minimal-git. I had to move the <package>.zst files into the mesa-git PKGBUILD directory. Presumably because once makechrootpkg gets kicked off it doesn't understand the full path to my llvm-minimal-git PKGBUILD directory.

[user-arch@antec-arch mesa-git]$ makechrootpkg -r $CHROOT -I llvm-libs-minimal-git-15.0.0_r425698.cfdd2b1aef19-1-x86_64.pkg.tar.zst -I llvm-minimal-git-15.0.0_r425698.cfdd2b1aef19-1-x86_64.pkg.tar.zst

I'm guessing it's not wise to regularly omit the -c, clean the chroot before building option, but hopefully a harmless error in this case.

$ pacman -Qi mesa-git

[user-arch@antec-arch mesa-git]$ pacman -Qi mesa-git
Name            : mesa-git
Version         : 22.2.0_devel.154913.de63ccfc1e86.d41d8cd98f00b204e9800998ecf8427e-1
Description     : an open-source implementation of the OpenGL specification, git version
Architecture    : x86_64
URL             : https://www.mesa3d.org
Licenses        : custom
Groups          : None
Provides        : mesa  opencl-mesa  vulkan-intel  vulkan-radeon  vulkan-mesa-layer  libva-mesa-driver  mesa-vdpau
                  vulkan-swrast  vulkan-driver  mesa-libgl  opengl-driver  opencl-driver
Depends On      : libdrm  libxxf86vm  libxdamage  libxshmfence  libelf  libomxil-bellagio  libunwind  libglvnd  wayland
                  lm_sensors  libclc  vulkan-icd-loader  zstd  expat  llvm-libs-minimal-git
Optional Deps   : opengl-man-pages: for the OpenGL API man pages
Required By     : cogl  fbida  glmark2-git  gputest  gst-plugins-base-libs  gtk3  libglvnd  mpv  qemu-ui-opengl
                  qemu-vhost-user-gpu  qt5-base  qt6-base  virglrenderer  weston  xorg-server-devel  zoom
Optional For    : obs-studio  ocl-icd  vulkan-icd-loader  waffle
Conflicts With  : mesa  opencl-mesa  vulkan-intel  vulkan-radeon  vulkan-mesa-layer  libva-mesa-driver  mesa-vdpau
                  vulkan-swrast  mesa-libgl
Replaces        : None
Installed Size  : 167.59 MiB
Packager        : Unknown Packager
Build Date      : Sun 05 Jun 2022 11:32:01 PM EDT
Install Date    : Sun 05 Jun 2022 11:48:29 PM EDT
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : None

Up next, I will test glxgears and FreeCAD again. I expect the same results, or a catastrophe.

Lone_Wolf · 2022-06-06 17:46:15

- chroots don't use environment vars from the user envirnoment they're run from.
The only way I know to build mesa-git against llvm-minimal-git (or the other llvm trunk variants) in a chroot is to hardcode the desired value for MESA_WHICH_LLVM in the PKGBUILD

You could also try the package I switched to, mesa-minimal-git (also in aur) . It has a hard dependency on llvm-minimal-git .

- llvm-minimal-git is setup to work with repo llvm as best as possible.
llvm-libs and llvm-libs-minimal-git do coexist, llvm and llvm-minimal-git don't .

- the check() function in llvm-minimal-git & llvm-git is known to fail very often.
I build llvm-minimal-git atleast once a week and have to use --nocheck approx 7 out of 10 times.
Around the release of a new version this often improves, sometimes I don't need --nocheck 4 weeks in a row.

I have some doubts whether mesa trunk / llvm trunk will make a difference in your issue, but it's one of the things that should be clear before filing a mesa bug .

Arch Linux

#1 2022-05-28 18:32:42

Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#2 2022-05-28 20:56:13

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#3 2022-05-31 11:09:01

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#4 2022-06-01 03:00:30

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#5 2022-06-01 08:40:24

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#6 2022-06-01 15:23:02

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#7 2022-06-02 04:12:56

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#8 2022-06-02 08:32:42

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#9 2022-06-02 12:54:48

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#10 2022-06-04 10:22:53

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#11 2022-06-05 14:39:44

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#12 2022-06-05 23:47:10

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#13 2022-06-06 03:55:49

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

#14 2022-06-06 17:46:15

Re: Where should I file bug report FREECAD DRM_IOCTL_AMDGPU_WAIT_CS

Board footer