On 31 May 2017 at 21:14, Jan Vesely <jan.ves...@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.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. > Try to build r300 and/or r600, without radeonsi. If you remove libdrm_amdgpu's amdgpu.h you'll see a compilation issue, or a link one otherwise. Do that as you enable/disable clover.
-Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
