[PATCH 6/8] drm/amdkfd: New IOCTL to allocate queue GWS

[Kuehling, Felix]

On 2019-05-31 4:53 p.m., Dave Airlie wrote:
> On Sat, 1 Jun 2019 at 06:04, Kuehling, Felix <Felix.Kuehling at amd.com> wrote:
>> On 2019-05-30 11:13 p.m., Dave Airlie wrote:
>>> On Sat, 25 May 2019 at 05:48, Kuehling, Felix <Felix.Kuehling at amd.com> wrote:
>>>> On 2019-05-23 6:41 p.m., Zeng, Oak wrote:
>>>>> Add a new kfd ioctl to allocate queue GWS. Queue
>>>>> GWS is released on queue destroy.
>>>>>
>>>>> Change-Id: I60153c26a577992ad873e4292e759e5c3d5bbd15
>>>>> Signed-off-by: Oak Zeng <Oak.Zeng at amd.com>
>>>> Reviewed-by: Felix Kuehling <Felix.Kuehling at amd.com>
>>>>
>>> btw just noticed in passing we are adding new features to kfd, is
>>> there an open source developed userspace to go along with this, there
>>> needs to a dev branch in public before new ioctls/uapi surfaces should
>>> be added to the kernel.
>>>
>>> The commits should probably have pointers to that branch.
>> Ah, a chicken and egg problem. I think this is the first time we're
>> adding a new ioctl to upstream KFD rather than upstreaming one that's
>> been developed internally first. Maybe not the right way to do it.
> There is no chicken/egg problem here. You develop kernel and userspace
> in parallel in the open, once you are happy and both sides are
> reviewed you merge kernel then userspace.

You're right. It would be straight forward if we had public code review 
for the user mode component. We're trying to convince our dev-ops team 
that we need public git repositories without losing support from our 
internal build and test infrastructure. Your comment helps provide some 
context and urgency for that request.

Thanks,
   Felix


>
> Dave.
>
>> I should be able to publish the user mode code in libhsakmt next week.
>> Then we'll work on a kfdtest to validate the firmware functionality.
>> Finally we'll use GWS further up the software stack for synchronization
>> of concurrent compute workgroups.
>>
>> Regards,
>>     Felix
>>
>>
>>> Dave.