[PATCH 6/8] drm/amdkfd: New IOCTL to allocate queue GWS
Felix.Kuehling at amd.com
Fri May 31 21:18:30 UTC 2019
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.
>> 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.
More information about the amd-gfx