On Wed, 2017-05-31 at 18:32 +0100, Emil Velikov wrote: > On 31 May 2017 at 18:18, Jan Vesely <jan.ves...@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 <mar...@gmail.com> wrote: > > > > On Wed, May 31, 2017 at 4:17 PM, Jan Vesely <jan.ves...@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 <mar...@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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
