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

[Emil Velikov]

On 31 May 2017 at 21:14, 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.
>> > > >
>> > > > >
>> > > > > > 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