Summary: | ir3_compiler valgrind build error | ||
---|---|---|---|
Product: | Mesa | Reporter: | Vinson Lee <vlee> |
Component: | Drivers/Gallium/Freedreno | Assignee: | Rob Clark <robclark> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | fdo-bugs, krh, robclark |
Version: | git | Keywords: | bisected, regression |
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 108530 |
Description
Vinson Lee
2018-10-29 20:34:02 UTC
f3cc0d2747568a186dba433ac94af607c38fa024 is the first bad commit commit f3cc0d2747568a186dba433ac94af607c38fa024 Author: Rob Clark <robdclark@gmail.com> Date: Sun Oct 21 10:22:11 2018 -0400 freedreno: import libdrm_freedreno + redesign submit In the pursuit of lowering driver overhead, it became clear that some amount of redesign of how libdrm_freedreno constructs the submit ioctl would be needed. In particular, as the gallium driver is starting to make heavier use of CP_SET_DRAW_STATE state groups/objects, the over- head of tracking cmd buffers and relocs becomes too much. And for "streaming" state, which isn't ever reused (like uniform uploads) the overhead of allocating/freeing ringbuffer[1] objects is too high. This redesign makes two main changes: 1) Introduces a fd_submit object for tracking bos and cmds table for the submit ioctl, making ringbuffer objects more light- weight. This was previously done in the ringbuffer. But we have many ringbuffer instances involved in a submit (gmem + draw + potentially 1000's of state-group rbs), and only need a single bos and cmds table. (Reloc table is still per-rb) The submit is also a convenient place for a slab allocator for ringbuffer objects. Other options would have required locking because, while we can guarantee allocations will only happen on a single thread, free's could happen either on the application thread or the flush_queue thread. With the slab allocator in the submit object, any frees that happen on the flush_queue thread happen after we know that the application thread is done with the submit. 2) Introduce a new "softpin" msm_ringbuffer_sp implementation that does not use relocs and only has cmds table entries for IB1 (ie. the cmdstream buffers that kernel needs to CP_INDIRECT_BUFFER to from the RB). To do this properly will require some updates on the kernel side, so whether you get the softpin or legacy submit/ringbuffer implementation at runtime depends on your kernel version. To make all these changes in libdrm would basically require adding a libdrm_freedreno2, so this is a good point to just pull the libdrm code into mesa. Plus it allows for using mesa's hashtable, slab allocator, etc. And it lets us have asserts enabled for debug mesa buids but omitted for release builds. And it makes life easier if further API changes become necessary. At this point I haven't tried to pull in the kgsl backend. Although I left the level of vfunc indirection which would make it possible to have other backends. (And this was convenient to keep to allow for the "softpin" ringbuffer to coexist.) NOTE: if bisecting a build error takes you here, try a clean build. There are a bunch of ways things can go wrong if you still have libdrm_freedreno cflags. [1] "ringbuffer" is probably a bad name, the only level of cmdstream buffer that is actually a ring is RB managed by kernel. User- space cmdstream is all IB1/IB2 and state-groups. Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Signed-off-by: Rob Clark <robdclark@gmail.com> :100644 100644 634245807f3d560409433432f2bad86dc6cf600b 156fb15fd3d51ce48703be6cefc5fe305dc1e7be M configure.ac :100644 100644 690e7d3d8aa08279187a653b0294808c4b0393f4 18667988bac059c0bc61f727af605b1c6fff5f98 M meson.build :040000 040000 40abeeed98712b7daffe7a0522d53a6d3f3dbaf7 b99c9a3cc23081994bb78e63c004de197a4d60ea M src bisect run success (In reply to Vinson Lee from comment #0) > CXXLD ir3_compiler > /usr/bin/ld: > /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a- > m_main.o): in function `_start': > (.text+0x0): multiple definition of `_start'; > /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o:(. > text+0x0): first defined here > /usr/bin/ld: > /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a- > m_main.o): relocation R_X86_64_32S against undefined symbol > `vgPlain_interim_stack' can not be used when making a PIE object; recompile > with -fPIC > /usr/bin/ld: > /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a- > m_trampoline.o): relocation R_X86_64_32 against `.text' can not be used when > making a PIE object; recompile with -fPIC > /usr/bin/ld: > /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a- > dispatch-amd64-linux.o): relocation R_X86_64_32S against symbol > `vgPlain_stats__n_xindirs_32' can not be used when making a PIE object; > recompile with -fPIC > /usr/bin/ld: final link failed: nonrepresentable section on output > collect2: error: ld returned 1 exit status is this with autotools build, I guess? Could you let me know what configure line you use? It looks like ir3_compiler is enabled by default for autotools build, which seems to more or less work except for this error (which looks different from what you see): /usr/bin/ld: cannot find -lcoregrind-amd64-linux /usr/bin/ld: cannot find -lvex-amd64-linux (I'm not entirely sure what the issue in either case is, although given that I use meson for development these days, I'd be ok with the option of just removing ir3_compiler from autotools build) (In reply to Rob Clark from comment #2) > (In reply to Vinson Lee from comment #0) > > CXXLD ir3_compiler > > /usr/bin/ld: > > /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a- > > m_main.o): in function `_start': > > (.text+0x0): multiple definition of `_start'; > > /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o:(. > > text+0x0): first defined here > > /usr/bin/ld: > > /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a- > > m_main.o): relocation R_X86_64_32S against undefined symbol > > `vgPlain_interim_stack' can not be used when making a PIE object; recompile > > with -fPIC > > /usr/bin/ld: > > /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a- > > m_trampoline.o): relocation R_X86_64_32 against `.text' can not be used when > > making a PIE object; recompile with -fPIC > > /usr/bin/ld: > > /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a- > > dispatch-amd64-linux.o): relocation R_X86_64_32S against symbol > > `vgPlain_stats__n_xindirs_32' can not be used when making a PIE object; > > recompile with -fPIC > > /usr/bin/ld: final link failed: nonrepresentable section on output > > collect2: error: ld returned 1 exit status > > is this with autotools build, I guess? Could you let me know what configure > line you use? It looks like ir3_compiler is enabled by default for > autotools build, which seems to more or less work except for this error > (which looks different from what you see): > > /usr/bin/ld: cannot find -lcoregrind-amd64-linux > /usr/bin/ld: cannot find -lvex-amd64-linux > > (I'm not entirely sure what the issue in either case is, although given that > I use meson for development these days, I'd be ok with the option of just > removing ir3_compiler from autotools build) I can reproduce the build error with "./autogen.sh --with-dri-drivers= --with-gallium-drivers=freedreno". The above linking errors are resolved by installing the package valgrind-tools-devel. Not linking ir3_compiler with valgrind libraries fixes the build for me. diff --git a/src/gallium/drivers/freedreno/Makefile.am b/src/gallium/drivers/freedreno/Makefile.am index 2024a2da232d..637a4281c82e 100644 --- a/src/gallium/drivers/freedreno/Makefile.am +++ b/src/gallium/drivers/freedreno/Makefile.am @@ -47,7 +47,6 @@ ir3_compiler_LDADD = \ $(top_builddir)/src/util/libmesautil.la \ $(top_builddir)/src/mesa/libmesagallium.la \ $(GALLIUM_COMMON_LIB_DEPS) \ - $(LIBDRM_LIBS) \ - $(VALGRIND_LIBS) + $(LIBDRM_LIBS) EXTRA_DIST += meson.build (In reply to Vinson Lee from comment #4) > Not linking ir3_compiler with valgrind libraries fixes the build for me. > > diff --git a/src/gallium/drivers/freedreno/Makefile.am > b/src/gallium/drivers/freedreno/Makefile.am > index 2024a2da232d..637a4281c82e 100644 > --- a/src/gallium/drivers/freedreno/Makefile.am > +++ b/src/gallium/drivers/freedreno/Makefile.am > @@ -47,7 +47,6 @@ ir3_compiler_LDADD = \ > $(top_builddir)/src/util/libmesautil.la \ > $(top_builddir)/src/mesa/libmesagallium.la \ > $(GALLIUM_COMMON_LIB_DEPS) \ > - $(LIBDRM_LIBS) \ > - $(VALGRIND_LIBS) > + $(LIBDRM_LIBS) > > EXTRA_DIST += meson.build that approach works for me, you can add my Reviewed-by: Rob Clark <robdclark@gmail.com> commit 802ae533ab3487f324a701364b06ad82e6601c69 Author: Vinson Lee <vlee@freedesktop.org> Date: Wed Oct 31 11:50:48 2018 -0700 freedreno: Do not link ir3_compiler with valgrind libraries. This patch fixes this freedreno autotools build error. CXXLD ir3_compiler /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_main.o): In function `_start': (.text+0x0): multiple definition of `_start' /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o:(.text+0x0): first defined here /usr/bin/ld: /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_main.o): relocation R_X86_64_32S against undefined symbol `vgPlain_interim_stack' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_trampoline.o): relocation R_X86_64_32 against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: /usr/lib/valgrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-dispatch-amd64-linux.o): relocation R_X86_64_32S against symbol `vgPlain_stats__n_xindirs_32' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status Fixes: f3cc0d274756 ("freedreno: import libdrm_freedreno + redesign submit") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108595 Signed-off-by: Vinson Lee <vlee@freedesktop.org> Reviewed-by: Rob Clark <robdclark@gmail.com> thanks! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.