[PATCH 14/25] drm/amdkfd: Populate DRM render device minor

[Felix Kuehling]

On 2018-02-14 02:01 PM, Felix Kuehling wrote:
> On 2018-02-14 01:33 PM, Christian König wrote:
>> Am 14.02.2018 um 19:24 schrieb Felix Kuehling:
>>> On 2018-02-14 01:15 PM, Christian König wrote:
>>>
>>>> As I said that concept is incompatible with the requirements on A+A
>>>> systems, so we need to find another solution to provide the
>>>> functionality.
>>> Do you mean you need to find another solution for A+A buffer sharing
>>> specifically? Or is this a more general statement that includes the
>>> mapping of BOs to multiple VMs on different devices?
>> A more general statement. We need to find a solution which works for
>> everybody and not just works like this in the KFD but breaks A+A
>> buffer sharing and so needs to be disabled there.
> Well, KFD sharing system memory BOs between GPUs doesn't break A+A.
> Implementing a solution for A+A that involves DMABufs will not affect
> KFD. And KFD isn't actually broken as far as I know. Once you have a
> solution for A+A, maybe it will help me understand the problem and I can
> evaluate whether the solution is applicable to KFD and worth adopting.
> But for now I have neither a good understanding of the problem, no
> evidence that there is a problem affecting KFD, and no way towards a
> solution.

Let me add, I'm definitely interested in your solution for P2P, because
we want to enable that for KFD for large-BAR systems. For now I'm not
upstreaming any P2P support, because I know that our current hack is
going to be superseded by the solution you're working on.

Thanks,
  Felix

>
>>>> What's on my TODO list anyway is to extend DMA-buf to not require
>>>> pinning and to be able to deal with P2P.
>>> Sounds good. That said, KFD is not using DMABufs here.
>>>
>>>> The former is actually rather easy and already mostly done by sharing
>>>> the reservation object between exporter and importer.
>>>>
>>>> The later is a bit more tricky because I need to create the necessary
>>>> P2P infrastructure, but even that is doable in the mid term.
>>> The sooner you can share your plans, the better. Right now I'm in a bit
>>> of limbo. I feel you're blocking KFD upstreaming based on AMDGPU plans
>>> and changes that no one has seen yet.
>> Well as far as I understand it that is not blocking for the current
>> upstreaming because you didn't planned to upstream this use case
>> anyway, didn't you?
> Which use case? The current patch series enables multi-GPU buffer
> sharing of system memory BOs. If it is actually broken, I can reduce the
> scope to single-GPU support. But I have no evidence that multi-GPU is
> actually broken.
>
> Regards,
>   Felix
>
>> Regards,
>> Christian.
>>
>>> Thanks,
>>>    Felix
>>>
>>>> Regards,
>>>> Christian.