Re: libdrm_amdgpu being forked and merged into Mesa

[Alex Deucher]

On Thu, Oct 24, 2024 at 8:38 AM Christian König
 wrote:
>
> Completely agree, but that's a platform decision which Alex needs to make.

+ Felix

Does buffer sharing with ROCm depend on the shared VA space?

Alex

>
> Christian.
>
> Am 24.10.24 um 14:16 schrieb Marek Olšák:
>
> I don't think we need to share VA space. APIs usually share one or two 
> buffers. That's almost nothing compared to the size of the occupied VA space. 
> They also likely map them again for themselves - APIs don't share any virtual 
> addresses as far as I know.
>
> Marek
>
> On Thu, Oct 24, 2024, 08:12 Christian König 
>  wrote:
>>
>> Am 22.10.24 um 06:06 schrieb Marek Olšák:
>> > Hi,
>> >
>> > The MR is up:
>> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756
>> >
>> > It's good to go as long as there is no functional issue.
>>
>> Finally getting rid of all the mid-layering? What about shared VA-space?
>>
>> Regards,
>> Christian.
>>
>> >
>> > libdrm_amdgpu will still be relevant for PAL, ROCm, and xf86-video-amdgpu.
>> >
>> > Marek
>>
>

Re: libdrm_amdgpu being forked and merged into Mesa

[Marek Olšák]

We don't need to share the same VMID between ROCm and Mesa. We don't
need to share the same driver FD between ROCm and Mesa either. It will
be like having 2 different processes, and that should always work.

Alex told me in person 2 weeks ago that we can put libdrm_amdgpu into Mesa.

Marek

On Thu, Oct 24, 2024 at 10:46 AM Christian König

 wrote:
>
> Yeah that would really not work.
>
> We at least need the code to unify the render node file descriptor stay
> inside libdrm and be used by Mesa.
>
> Otherwise Mesa would start using a separate render node file descriptor.
>
> Regards,
> Christian.
>
> Am 24.10.24 um 16:19 schrieb Felix Kuehling:
> > I'm not sure what this means. ROCm allocates all its virtual address
> > space with mmap. That includes address space for BOs imported with the
> > interop APIs.
> >
> > We are sharing the GPU virtual address space with Mesa since we're
> > using the same render nodes. So if Mesa's GPU virtual address space
> > management conflicts with the CPU virtual address space that ROCm
> > shares between CPU and GPU, that would be a problem.
> >
> > Regards,
> >   Felix
> >
> >
> > On 2024-10-24 09:24, Alex Deucher wrote:
> >> On Thu, Oct 24, 2024 at 8:38 AM Christian König
> >>  wrote:
> >>> Completely agree, but that's a platform decision which Alex needs to
> >>> make.
> >> + Felix
> >>
> >> Does buffer sharing with ROCm depend on the shared VA space?
> >>
> >> Alex
> >>
> >>> Christian.
> >>>
> >>> Am 24.10.24 um 14:16 schrieb Marek Olšák:
> >>>
> >>> I don't think we need to share VA space. APIs usually share one or
> >>> two buffers. That's almost nothing compared to the size of the
> >>> occupied VA space. They also likely map them again for themselves -
> >>> APIs don't share any virtual addresses as far as I know.
> >>>
> >>> Marek
> >>>
> >>> On Thu, Oct 24, 2024, 08:12 Christian König
> >>>  wrote:
>  Am 22.10.24 um 06:06 schrieb Marek Olšák:
> > Hi,
> >
> > The MR is up:
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756
> >
> > It's good to go as long as there is no functional issue.
>  Finally getting rid of all the mid-layering? What about shared
>  VA-space?
> 
>  Regards,
>  Christian.
> 
> > libdrm_amdgpu will still be relevant for PAL, ROCm, and
> > xf86-video-amdgpu.
> >
> > Marek
>

Re: libdrm_amdgpu being forked and merged into Mesa

[Michel Dänzer]

On 2024-10-25 12:18, Bas Nieuwenhuizen wrote:
> On Fri, Oct 25, 2024 at 11:21 AM Michel Dänzer  > wrote:
> 
> On 2024-10-24 17:08, Marek Olšák wrote:
> > We don't need to share the same VMID between ROCm and Mesa. We don't
> > need to share the same driver FD between ROCm and Mesa either. It will
> > be like having 2 different processes, and that should always work.
> 
> Per 
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756#note_2626236 
> ,
>  does anything prevent the application from passing the same DRM file 
> description (doesn't need to be the same *descriptor*) to separate drivers? 
> (Not sure it can even pass a DRM fd to ROCm, surely can e.g. to radeonsi & 
> AMDVLK though)
> 
> 
> In RADV the app has no way to pass in a drm fd, there is only a way to query 
> the major/minor from the fd 
> (https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap55.html#VK_EXT_physical_device_drm
>  
> ).

Hmm. So Wayland compositors which use Vulkan have to share BOs from Vulkan into 
their DRM file description for KMS via dma-buf?


How about ROCm, no way to pass in / retrieve a DRM file descriptor there either?


> (not to mention that it would mean that any users would need to use 
> libdrm_amdgpu. Given that the most likely combination of GBM with shared 
> fd/handle stuff is kernel modesetting and nobody uses libdrm_amdgpu with 
> that, having a shared libdrm_amdgpu would not help there)

Not sure what you mean here, Wayland compositors use radeonsi with KMS.


-- 
Earthling Michel Dänzer   \GNOME / Xwayland / Mesa developer
https://redhat.com \   Libre software enthusiast

Re: libdrm_amdgpu being forked and merged into Mesa

[Michel Dänzer]

On 2024-10-24 17:08, Marek Olšák wrote:
> We don't need to share the same VMID between ROCm and Mesa. We don't
> need to share the same driver FD between ROCm and Mesa either. It will
> be like having 2 different processes, and that should always work.

Per 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756#note_2626236, 
does anything prevent the application from passing the same DRM file 
description (doesn't need to be the same *descriptor*) to separate drivers? 
(Not sure it can even pass a DRM fd to ROCm, surely can e.g. to radeonsi & 
AMDVLK though)

I guess one way to avoid this issue would be for Mesa to always use a different 
DRM file description internally, then it would have to share buffers with the 
DRM file description passed in by the application as needed though.


-- 
Earthling Michel Dänzer   \GNOME / Xwayland / Mesa developer
https://redhat.com \   Libre software enthusiast

Unable to create a project in gitlab.freedesktop.org

[Manuel Dun]

Hello

I want to do a merge request but I am unable to create any project,
The gitlab page gives me this message: "You cannot create projects in
your personal namespace. Contact your GitLab administrator."

Also the fork button is not enabled (it is greyed out).

Can you help me?

Thanks

Re: libdrm_amdgpu being forked and merged into Mesa

[Bas Nieuwenhuizen]

On Fri, Oct 25, 2024 at 4:36 PM Michel Dänzer 
wrote:

> On 2024-10-25 12:18, Bas Nieuwenhuizen wrote:
> > On Fri, Oct 25, 2024 at 11:21 AM Michel Dänzer <
> michel.daen...@mailbox.org > wrote:
> >
> > On 2024-10-24 17:08, Marek Olšák wrote:
> > > We don't need to share the same VMID between ROCm and Mesa. We
> don't
> > > need to share the same driver FD between ROCm and Mesa either. It
> will
> > > be like having 2 different processes, and that should always work.
> >
> > Per
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756#note_2626236
> <
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756#note_2626236>,
> does anything prevent the application from passing the same DRM file
> description (doesn't need to be the same *descriptor*) to separate drivers?
> (Not sure it can even pass a DRM fd to ROCm, surely can e.g. to radeonsi &
> AMDVLK though)
> >
> >
> > In RADV the app has no way to pass in a drm fd, there is only a way to
> query the major/minor from the fd (
> https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap55.html#VK_EXT_physical_device_drm
> <
> https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap55.html#VK_EXT_physical_device_drm
> >).
>
> Hmm. So Wayland compositors which use Vulkan have to share BOs from Vulkan
> into their DRM file description for KMS via dma-buf?
>
>
> How about ROCm, no way to pass in / retrieve a DRM file descriptor there
> either?
>
>
> > (not to mention that it would mean that any users would need to use
> libdrm_amdgpu. Given that the most likely combination of GBM with shared
> fd/handle stuff is kernel modesetting and nobody uses libdrm_amdgpu with
> that, having a shared libdrm_amdgpu would not help there)
>
> Not sure what you mean here, Wayland compositors use radeonsi with KMS.
>
> That is what I mean, since they use KMS directly, anything that radeonsi
does wrt using or not using libdrm_amdgpu doesn't impact them.

(note that some compositors, like gamescope do the actual dmabuf dance)

>
> --
> Earthling Michel Dänzer   \GNOME / Xwayland / Mesa developer
> https://redhat.com \   Libre software enthusiast
>

Re: libdrm_amdgpu being forked and merged into Mesa

[Michel Dänzer]

On 2024-10-25 17:57, Bas Nieuwenhuizen wrote:
> On Fri, Oct 25, 2024 at 4:36 PM Michel Dänzer  > wrote:
> On 2024-10-25 12:18, Bas Nieuwenhuizen wrote:
> 
> > (not to mention that it would mean that any users would need to use 
> libdrm_amdgpu. Given that the most likely combination of GBM with shared 
> fd/handle stuff is kernel modesetting and nobody uses libdrm_amdgpu with 
> that, having a shared libdrm_amdgpu would not help there)
> 
> Not sure what you mean here, Wayland compositors use radeonsi with KMS.
> 
> That is what I mean, since they use KMS directly, anything that radeonsi does 
> wrt using or not using libdrm_amdgpu doesn't impact them.

Still not following. Wayland compositors generally use the same DRM file 
description for radeonsi (via the EGL GBM platform) and KMS.


> (note that some compositors, like gamescope do the actual dmabuf dance

AFAIK gamescope uses Vulkan, not GL.


-- 
Earthling Michel Dänzer   \GNOME / Xwayland / Mesa developer
https://redhat.com \   Libre software enthusiast

Re: libdrm_amdgpu being forked and merged into Mesa

[Bas Nieuwenhuizen]

On Fri, Oct 25, 2024 at 6:57 PM Michel Dänzer 
wrote:

> On 2024-10-25 17:57, Bas Nieuwenhuizen wrote:
> > On Fri, Oct 25, 2024 at 4:36 PM Michel Dänzer <
> michel.daen...@mailbox.org > wrote:
> > On 2024-10-25 12:18, Bas Nieuwenhuizen wrote:
> >
> > > (not to mention that it would mean that any users would need to
> use libdrm_amdgpu. Given that the most likely combination of GBM with
> shared fd/handle stuff is kernel modesetting and nobody uses libdrm_amdgpu
> with that, having a shared libdrm_amdgpu would not help there)
> >
> > Not sure what you mean here, Wayland compositors use radeonsi with
> KMS.
> >
> > That is what I mean, since they use KMS directly, anything that radeonsi
> does wrt using or not using libdrm_amdgpu doesn't impact them.
>
> Still not following. Wayland compositors generally use the same DRM file
> description for radeonsi (via the EGL GBM platform) and KMS.
>

And they will after this change, i.e. this is not a problem wrt this
change.

>
>
> > (note that some compositors, like gamescope do the actual dmabuf dance
>
> AFAIK gamescope uses Vulkan, not GL.
>
>
> --
> Earthling Michel Dänzer   \GNOME / Xwayland / Mesa developer
> https://redhat.com \   Libre software enthusiast
>

Re: libdrm_amdgpu being forked and merged into Mesa

[Felix Kuehling]

I'm not sure what this means. ROCm allocates all its virtual address 
space with mmap. That includes address space for BOs imported with the 
interop APIs.


We are sharing the GPU virtual address space with Mesa since we're using 
the same render nodes. So if Mesa's GPU virtual address space management 
conflicts with the CPU virtual address space that ROCm shares between 
CPU and GPU, that would be a problem.


Regards,
  Felix


On 2024-10-24 09:24, Alex Deucher wrote:

On Thu, Oct 24, 2024 at 8:38 AM Christian König
 wrote:

Completely agree, but that's a platform decision which Alex needs to make.

+ Felix

Does buffer sharing with ROCm depend on the shared VA space?

Alex


Christian.

Am 24.10.24 um 14:16 schrieb Marek Olšák:

I don't think we need to share VA space. APIs usually share one or two buffers. 
That's almost nothing compared to the size of the occupied VA space. They also 
likely map them again for themselves - APIs don't share any virtual addresses 
as far as I know.

Marek

On Thu, Oct 24, 2024, 08:12 Christian König  
wrote:

Am 22.10.24 um 06:06 schrieb Marek Olšák:

Hi,

The MR is up:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756

It's good to go as long as there is no functional issue.

Finally getting rid of all the mid-layering? What about shared VA-space?

Regards,
Christian.


libdrm_amdgpu will still be relevant for PAL, ROCm, and xf86-video-amdgpu.

Marek

Re: libdrm_amdgpu being forked and merged into Mesa

[Bas Nieuwenhuizen]

On Fri, Oct 25, 2024 at 11:21 AM Michel Dänzer 
wrote:

> On 2024-10-24 17:08, Marek Olšák wrote:
> > We don't need to share the same VMID between ROCm and Mesa. We don't
> > need to share the same driver FD between ROCm and Mesa either. It will
> > be like having 2 different processes, and that should always work.
>
> Per
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31756#note_2626236,
> does anything prevent the application from passing the same DRM file
> description (doesn't need to be the same *descriptor*) to separate drivers?
> (Not sure it can even pass a DRM fd to ROCm, surely can e.g. to radeonsi &
> AMDVLK though)
>

In RADV the app has no way to pass in a drm fd, there is only a way to
query the major/minor from the fd (
https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap55.html#VK_EXT_physical_device_drm).
Surely AMDVLK has no way to pass in fds either?

Even if you can for radeonsi through e.g. gbm (can you?), I believe most
vendors in mesa do not do this deduping, so why would we need to be the one
vendor that actually protects against this (not to mention that it would
mean that any users would need to use libdrm_amdgpu. Given that the most
likely combination of GBM with shared fd/handle stuff is kernel modesetting
and nobody uses libdrm_amdgpu with that, having a shared libdrm_amdgpu
would not help there)

>
> I guess one way to avoid this issue would be for Mesa to always use a
> different DRM file description internally, then it would have to share
> buffers with the DRM file description passed in by the application as
> needed though.
>
>
> --
> Earthling Michel Dänzer   \GNOME / Xwayland / Mesa developer
> https://redhat.com \   Libre software enthusiast
>