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

[Jan Vesely]

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.
> > > > 
> > > > > 
> > > > > > 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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170531/28aea778/attachment-0001.sig>