[Mesa-dev] [PATCH v2 2/5] r600: remove custom and incomplete OpenCL code paths

Wed May 31 21:20:13 UTC 2017

On Wed, May 31, 2017 at 3:14 PM, Jan Vesely <jan.vesely at rutgers.edu> wrote:

> On Wed, 2017-05-31 at 18:32 +0100, Emil Velikov wrote:
> > On 31 May 2017 at 18:18, Jan Vesely <jan.vesely at rutgers.edu> wrote:
> > > On Wed, 2017-05-31 at 17:48 +0100, Emil Velikov wrote:
> > > > On 31 May 2017 at 16:32, Marek Olšák <maraeo at gmail.com> wrote:
> > > > > On Wed, May 31, 2017 at 4:17 PM, Jan Vesely <
> jan.vesely at rutgers.edu> wrote:
> > > > > > On Wed, 2017-05-31 at 13:33 +0100, Emil Velikov wrote:
> > > > > > > On 29 May 2017 at 16:33, Marek Olšák <maraeo at gmail.com> wrote:
> > > > > > > > The "ac" functions could also be forked and put into r600 if
> people
> > > > > > > > want to preserve the OpenCL support. That would remove the
> dependency
> > > > > > > > on "ac".
> > > > > > > >
> > > > > >
> > > > > > I thought amdgpu.a was supposed to be shared by both, is there a
> way to
> > > > > >  split off the GCN parts and still have reuse shared code?
> > > > > > I won't hide it, my intention is to rely on shared code as much
> as
> > > > > > possible and force others to care (same strategy with LLVM, but
> mesa
> > > > > > does not have a nice regression test suite).
> > > > >
> > > > > This shared code doesn't change. You won't gain anything by sharing
> > > > > it.
> > > >
> > > > This one here. Jan/others can you look into Marek's suggestion, as
> you
> > > > have time?
> > > >
> > > > > And with ROCm OpenCL being out there, the fate of RadeonSI OpenCL
> > > > > is also uncertain and it's definitely unmaintained.
>

I'd say that as long as ROCm only supports PCIe Gen 3+ and later-generation
discrete GCN chips (and APUs), there's still a future that clover can carve
out for itself.

For reference, the systems I'm doing testing/dev of libclc on, in my
limited spare time, are:
Phenom II x6 w/ Radeon 6850 (BARTS)
Ryzen R7 1700 w/ Radeon 7850 (PITCAIRN)

> > > > >
> > > > > >
> > > > > > > Any objections if we defer this to the person working on
> r600+OpenCL,
> > > > > > > or is that a must for the series?
> > > > > > > I'm slightly worried that a "fix the build" is going into
> "refactor
> > > > > > > driver X" :-\
> > > > > >
> > > > > > what's wrong with adding an r600g+opencl on radeonsi dependency?
> if
> > > > > > it's "not used" enough to be removed, then it should be "not
> used"
> > > > > > enough to have non-standard dependency.
> > > > >
> > > > > Yeah we can add that dependency.
> > > > >
> > > > > There is technically no production quality OpenCL Mesa driver, so
> the
> > > > > importance of building OpenCL successfully is kinda moot. Maybe we
> can
> > > > > just let it be in the current state with all its build bugs.
> > > > >
> > > >
> > > > If I understood you correctly -> selecting r600+opencl would also
> > > > build radeonsi?
> > > > This sounds like a very nasty hack/workaround :-(
> > > >
> > > > Marek, what's your final call?
> > > > Fwiw I'm still behind "drop this code and let anyone interested do a
> r600 copy".
> > >
> > > I don't understand the delete fervor. The code is rarely touched (this
> > > is the case for most old drivers), because most of the work needed is
> > > on the LLVM side. Since there is no full time dev interested, it's a
> > > very slow process.
> > >
> >
> > If things did not fail to build I would not come near, let alone
> > remove any code.
> >
> > I have zero knowledge of the code in question and HW/time to make it
> > work I correctly. Since nobody else have come forward with tackling
> > this properly, I opted for this route.
> > Yes it's far from perfect, but it's what we currently have :-\
>
> can you describe the problem a bit? I'll try to find few cycles if it's
> as simple as copying parts of shared code to a new file.
>

I believe the issue is that r600g will currently not build WITHOUT also
building radeonsi with enabled (which pulls in the AC dependency, which
r600 uses for clover's llvm code).

In v2 of patch 2, it seems pretty clear that the ac_binary.h include,
invocation of radeon_shader_binary_clean, and the "struct ac_shader_binary
binary;" member of r600_pipe_compute are missing
guards of #ifdef HAVE_OPENCL.

There are probably some other fix-ups required to the build system as well
in patches 3-5, but I haven't gotten to those yet.

I'd say that the state I'd like to end up in: Allow r600g to depend on the
amd/common code IF --enable-opencl is present. This would require us to
also have r600 properly depend on the amd/common library instead of just
hoping that radeonsi is being built as well. Smells like something in the
dependency tree is missing/wrong.

--Aaron

>
> I can't replicate the build failure. My setup:
>
> $ git clean -fxd
> $ ./autogen.sh
> $ PKG_CONFIG_PATH=~/.local/lib/pkgconfig/ ./configure --
> prefix=/home/vesely/.local/ --enable-texture-float --enable-opencl --
> enable-opencl_icd --enable-gles2 --enable-xvmc --enable-vdpau --enable-
> egl --enable-debug --enable-gbm --enable-llvm --enable-dri3 --enable-va
> --with-gallium-drivers=r600 --with-dri-drivers=i965 --with-egl-
> platforms=x11,drm --enable-llvm-shared-libs --with-llvm-
> prefix=/home/vesely/.local/ CFLAGS="-O3 -Wall -Wextra -march=native
> -Wno-unused-parameter -Wno-missing-field-initializers" CXXFLAGS="-O3
> -Wall -Wextra -march=native -Wno-unused-parameter"
> $ make -j8
>
> builds successfully
> Jan
>
>
> >
> > -Emil
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170531/f857b461/attachment.html>