On 2/10/23 12:50, Christian König wrote:
Am 07.02.23 um 11:50 schrieb Danilo Krummrich:
On 2/7/23 10:35, Christian König wrote:
However, I still don't see why we would want to merge over buffer
boundaries, because ultimately we'll end up splitting such a merged
mapping later on anyway on
Am 07.02.23 um 11:50 schrieb Danilo Krummrich:
On 2/7/23 10:35, Christian König wrote:
[SNIP]
Just to have it all in place, the example I gave was:
- two virtually contiguous buffers A and B
- binding 1 mapped to A with BO offset 0
- binding 2 mapped to B with BO offset length(A)
What I
On 2/7/23 10:35, Christian König wrote:
Am 06.02.23 um 19:20 schrieb Danilo Krummrich:
On 2/6/23 17:14, Christian König wrote:
Concentrating this discussion on a very big misunderstanding first.
Am 06.02.23 um 14:27 schrieb Danilo Krummrich:
[SNIP]
My understanding is that userspace is fully
Am 06.02.23 um 19:20 schrieb Danilo Krummrich:
On 2/6/23 17:14, Christian König wrote:
Concentrating this discussion on a very big misunderstanding first.
Am 06.02.23 um 14:27 schrieb Danilo Krummrich:
[SNIP]
My understanding is that userspace is fully responsible on the parts
of the GPU VA s
On 2/6/23 17:14, Christian König wrote:
Concentrating this discussion on a very big misunderstanding first.
Am 06.02.23 um 14:27 schrieb Danilo Krummrich:
[SNIP]
My understanding is that userspace is fully responsible on the parts
of the GPU VA space it owns. This means that userspace needs to
Concentrating this discussion on a very big misunderstanding first.
Am 06.02.23 um 14:27 schrieb Danilo Krummrich:
[SNIP]
My understanding is that userspace is fully responsible on the parts
of the GPU VA space it owns. This means that userspace needs to take
care to *not* ask the kernel to mo
On 2/6/23 10:48, Christian König wrote:
Am 02.02.23 um 19:31 schrieb Danilo Krummrich:
On 2/2/23 12:53, Christian König wrote:
Am 01.02.23 um 09:10 schrieb Dave Airlie:
[SNIP]
For drivers that don't intend to merge at all and (somehow) are
capable of dealing with sparse regions without knowin
Am 02.02.23 um 19:31 schrieb Danilo Krummrich:
On 2/2/23 12:53, Christian König wrote:
Am 01.02.23 um 09:10 schrieb Dave Airlie:
[SNIP]
For drivers that don't intend to merge at all and (somehow) are
capable of dealing with sparse regions without knowing the sparse
region's boundaries, it'd be
On 2/2/23 12:53, Christian König wrote:
Am 01.02.23 um 09:10 schrieb Dave Airlie:
[SNIP]
For drivers that don't intend to merge at all and (somehow) are
capable of dealing with sparse regions without knowing the sparse
region's boundaries, it'd be easy to make those gpuva_regions optional.
Yea
Am 01.02.23 um 09:10 schrieb Dave Airlie:
[SNIP]
For drivers that don't intend to merge at all and (somehow) are
capable of dealing with sparse regions without knowing the sparse
region's boundaries, it'd be easy to make those gpuva_regions optional.
Yeah, but this then defeats the approach of
On Mon, 30 Jan 2023 at 23:02, Christian König wrote:
>
> Am 29.01.23 um 19:46 schrieb Danilo Krummrich:
> > On 1/27/23 22:09, Danilo Krummrich wrote:
> >> On 1/27/23 16:17, Christian König wrote:
> >>> Am 27.01.23 um 15:44 schrieb Danilo Krummrich:
> [SNIP]
> >>>
> >>> What you want i
On 1/30/23 14:02, Christian König wrote:
Am 29.01.23 um 19:46 schrieb Danilo Krummrich:
On 1/27/23 22:09, Danilo Krummrich wrote:
On 1/27/23 16:17, Christian König wrote:
Am 27.01.23 um 15:44 schrieb Danilo Krummrich:
[SNIP]
What you want is one component for tracking the VA allocations
(d
Am 29.01.23 um 19:46 schrieb Danilo Krummrich:
On 1/27/23 22:09, Danilo Krummrich wrote:
On 1/27/23 16:17, Christian König wrote:
Am 27.01.23 um 15:44 schrieb Danilo Krummrich:
[SNIP]
What you want is one component for tracking the VA allocations
(drm_mm based) and a different component/int
Am 27.01.23 um 21:25 schrieb David Airlie:
[SNIP]
What we have inside the kernel is the information what happens if an
address X is accessed. On AMD HW this can be:
1. Route to the PCIe bus because the mapped BO is stored in system memory.
2. Route to the internal MC because the mapped BO is st
On 1/27/23 22:09, Danilo Krummrich wrote:
On 1/27/23 16:17, Christian König wrote:
Am 27.01.23 um 15:44 schrieb Danilo Krummrich:
[SNIP]
What you want is one component for tracking the VA allocations
(drm_mm based) and a different component/interface for tracking
the VA mappings (probabl
On 1/27/23 16:17, Christian König wrote:
Am 27.01.23 um 15:44 schrieb Danilo Krummrich:
[SNIP]
What you want is one component for tracking the VA allocations
(drm_mm based) and a different component/interface for tracking the
VA mappings (probably rb tree based).
That's what the GPUVA mana
On Sat, Jan 28, 2023 at 1:17 AM Christian König
wrote:
>
> Am 27.01.23 um 15:44 schrieb Danilo Krummrich:
> > [SNIP]
>
> What you want is one component for tracking the VA allocations
> (drm_mm based) and a different component/interface for tracking the
> VA mappings (probably
Am 27.01.23 um 15:44 schrieb Danilo Krummrich:
[SNIP]
What you want is one component for tracking the VA allocations
(drm_mm based) and a different component/interface for tracking the
VA mappings (probably rb tree based).
That's what the GPUVA manager is doing. There are gpuva_regions
whi
On 1/27/23 14:23, Christian König wrote:
Am 27.01.23 um 14:12 schrieb Danilo Krummrich:
On 1/27/23 08:55, Christian König wrote:
Am 27.01.23 um 02:26 schrieb Danilo Krummrich:
On 1/27/23 02:05, Matthew Brost wrote:
On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:
This comm
Am 27.01.23 um 14:12 schrieb Danilo Krummrich:
On 1/27/23 08:55, Christian König wrote:
Am 27.01.23 um 02:26 schrieb Danilo Krummrich:
On 1/27/23 02:05, Matthew Brost wrote:
On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:
This commit provides the interfaces for the new UA
On 1/27/23 08:55, Christian König wrote:
Am 27.01.23 um 02:26 schrieb Danilo Krummrich:
On 1/27/23 02:05, Matthew Brost wrote:
On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode
Am 27.01.23 um 02:26 schrieb Danilo Krummrich:
On 1/27/23 02:05, Matthew Brost wrote:
On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU v
On 1/27/23 04:21, Matthew Brost wrote:
On Fri, Jan 27, 2023 at 02:43:30AM +0100, Danilo Krummrich wrote:
On 1/27/23 02:05, Matthew Brost wrote:
On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API.
On Fri, Jan 27, 2023 at 02:43:30AM +0100, Danilo Krummrich wrote:
>
>
> On 1/27/23 02:05, Matthew Brost wrote:
> > On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:
> > > This commit provides the interfaces for the new UAPI motivated by the
> > > Vulkan API. It allows user mode dr
On 1/27/23 02:05, Matthew Brost wrote:
On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM
On 1/27/23 02:05, Matthew Brost wrote:
On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IO
On Wed, Jan 18, 2023 at 07:12:47AM +0100, Danilo Krummrich wrote:
> This commit provides the interfaces for the new UAPI motivated by the
> Vulkan API. It allows user mode drivers (UMDs) to:
>
> 1) Initialize a GPU virtual address (VA) space via the new
>DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs c
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved
VA area.
2) Bind and unbind GPU VA space ma
28 matches
Mail list logo
