On Tue, Apr 6, 2021 at 1:47 PM Vivek Kasireddy
wrote:
> If support for Blob resources is available, then dumb BOs created
> by the driver can be considered as guest Blobs.
>
> v2: Don't skip transfer and flush commands as part of plane update
> as the device may have created a shared mapping. (Ge
On Thu, Apr 8, 2021 at 2:27 AM Gerd Hoffmann wrote:
> > > +
> > > + if (vgdev->has_resource_blob) {
> > > + params.blob_mem = VIRTGPU_BLOB_MEM_GUEST;
> > > + params.blob_flags = VIRTGPU_BLOB_FLAG_USE_SHAREABLE;
> > >
> >
> > This creates some log spam with crosvm
On Fri, Apr 9, 2021 at 12:48 AM Gerd Hoffmann wrote:
> Hi,
>
> > > IIRC the VIRTGPU_BLOB_FLAG_USE_SHAREABLE flag means that the host *can*
> > > create a shared mapping (i.e. the host seeing guest-side changes
> without
> > > explicit transfer doesn't cause problems for the guest). It doesn no
ted a shared mapping. (Gerd)
>
> v3: Don't create dumb BOs as Guest blobs if Virgl is enabled. (Gurchetan)
>
I think it is a good start and advances QEMU blobs. Improvements are
always possible, but may be made at a future time.
Acked-by: Gurchetan Singh
>
> Cc: Gerd Ho
obe for feature
drm/virtio: implement context init: support init ioctl
Gurchetan Singh (10):
virtio-gpu api: multiple context types with explicit initialization
drm/virtgpu api: create context init feature
drm/virtio: implement context init: track valid capabilities in a mask
drm/virtio
11
1 23
The "Sommelier" guest Wayland proxy uses this to poll for events
from the host compositor.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
Acked-by: Nicholas Verne
---
include/uapi/drm/virtgpu_drm.h | 27
The valid capability IDs are between 1 to 63, and defined in the
virtio gpu spec. This is used for error checking the subsequent
patches. We're currently only using 2 capability IDs, so this
should be plenty for the immediate future.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng
From: Anthoine Bourgeois
Let's probe for VIRTIO_GPU_F_CONTEXT_INIT.
Create a new DRM_INFO(..) line since the current one is getting
too long.
Signed-off-by: Anthoine Bourgeois
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c
l the
host which per-context command ring (or "hardware queue", distinct
from the virtio-queue) the fence should be associated with.
The new capability sets (gfxstream, venus etc.) are only defined in
the virtio-gpu spec and not defined in the header.
Signed-off-by: Gurchetan
We don't want fences from different 3D contexts (virgl, gfxstream,
venus) to be on the same timeline. With explicit context creation,
we can specify the number of ring each context wants.
Execbuffer can specify which ring to use.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng
r GPU
commands.
As such, we'll need to specify these parameters when allocating a
dma_fence.
vgdev->fence_drv.context is the "default" fence context for 2D mode
and old userspace.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_drv.h
e_ctx. The ring_idx will
be emitted to host userspace, when emit_fence_info is true.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/
common way to receive responses with
virtgpu]. As such, there is no context specific read(..)
implementation either -- just a poll(..) implementation.
Signed-off-by: Gurchetan Singh
Acked-by: Nicholas Verne
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 43 +-
drivers/gpu/drm
f KMS events. The parameter
VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK specifies the pollable
rings.
Signed-off-by: Gurchetan Singh
Acked-by: Nicholas Verne
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 23 +--
2 files changed, 22 inser
260 to signal before 259. As such, process each fence_id
individually.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 16 ++--
drivers/gpu/drm/virtio/virtgpu_vq.c| 15 +++
2 files changed, 17 insertions(+), 14 deleti
This advertises the context init feature to userspace, along with
a mask of supported capabilities.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
From: Anthoine Bourgeois
This implements the context initialization ioctl. A list of params
is passed in by userspace, and kernel driver validates them. The
only currently supported param is VIRTGPU_CONTEXT_PARAM_CAPSET_ID.
If the context has already been initialized, -EEXIST is returned.
This
h modifiers
> when using
> > virgl commands for that. Allowing modifiers with virgl=off too makes
> sense
> > given your use case, but we should not use diverging approaches for
> virgl=on vs.
> > virgl=off. Specifically I'm
virtio_gpu typically uses the prefix virtio_gpu, but there are
a few places where the virtio prefix is used. Modify this for
consistency.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 24 ++
drivers/gpu/drm/virtio/virtgpu_fence.c | 32
hdr has padding + flags available,
so that should be easy.
This change goes in the direction specified above, by:
- looking up the virtgpu_fence given a fence_id
- signalling all prior fences in a given context
- signalling current fence
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virt
dant, and
it will not be sufficient to check the last_fence_id for multiple
synchronization timelines. Remove it.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vi
hdr has padding + flags available,
so that should be easy.
This change goes in the direction specified above, by:
- looking up the virtgpu_fence given a fence_id
- signalling all prior fences in a given context
- signalling current fence
v2: fix grammar in comment
Signed-off-by: Gurchetan Sing
virtio_gpu typically uses the prefix virtio_gpu, but there are
a few places where the virtio prefix is used. Modify this for
consistency.
v3: add r-b tags
Signed-off-by: Gurchetan Singh
Reviewed-by: Anthoine Bourgeois
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 24
dant, and
it will not be sufficient to check the last_fence_id for multiple
synchronization timelines. Remove it.
v3: add r-b tags
Signed-off-by: Gurchetan Singh
Reviewed-by: Anthoine Bourgeois
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 12
1 file changed, 4 insertions(+
-by: Anthoine Bourgeois
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_fence.c | 39 --
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/vir
resp_buf = kzalloc(sizeof(*resp_buf), GFP_KERNEL);
> - if (!resp_buf) {
> - virtio_gpu_array_put_free(objs);
> + if (!resp_buf)
> return -ENOMEM;
> - }
>
> cmd_p = virtio_gpu_alloc_cmd_resp
> (vgdev, vi
From: Anthoine Bourgeois
For coherency, all ioctls are suffixed
Signed-off-by: Anthoine Bourgeois
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl
From: Anthoine Bourgeois
Easier to find where declarations are implemented.
Signed-off-by: Anthoine Bourgeois
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.
From: Anthoine Bourgeois
This provides a description of how the kernel driver uses the
shmid to determine capabilities.
Signed-off-by: Anthoine Bourgeois
---
include/uapi/linux/virtio_gpu.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/l
To be clearer about our intentions to associate sequence numbers
and fence IDs, let's rename these variables.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
drivers/gpu/drm/virtio/virtgpu_fence.c
Currently, the fence ID, which can be used to identify a
virtgpu fence, is the same as the fence sequence number.
Let's use the fence_id name to clearly signal this.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
drivers/gpu/drm/virtio/virtgpu_fence.
l the
host which per-context command ring (or "hardware queue", distinct
from the virtio-queue) the fence should be associated with.
The new capability sets (gfxstream, venus etc.) are only defined in
the virtio-gpu spec and not defined in the header.
Signed-off-by: Gurchetan
tio: implement context init: support init ioctl
Gurchetan Singh (10):
virtio-gpu api: multiple context types with explicit initialization
drm/virtgpu api: create context init feature
drm/virtio: implement context init: track valid capabilities in a mask
drm/virtio: implement context init: tr
11
1 23
The "Sommelier" guest Wayland proxy uses this to poll for events
from the host compositor.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
Acked-by: Nicholas Verne
---
include/uapi/drm/virtgpu_drm.h | 27
The valid capability IDs are between 1 to 63, and defined in the
virtio gpu spec. This is used for error checking the subsequent
patches. We're currently only using 2 capability IDs, so this
should be plenty for the immediate future.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng
From: Anthoine Bourgeois
Let's probe for VIRTIO_GPU_F_CONTEXT_INIT.
Create a new DRM_INFO(..) line since the current one is getting
too long.
Signed-off-by: Anthoine Bourgeois
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c
e_ctx. The ring_idx will
be emitted to host userspace, when emit_fence_info is true.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/
r GPU
commands.
As such, we'll need to specify these parameters when allocating a
dma_fence.
vgdev->fence_drv.context is the "default" fence context for 2D mode
and old userspace.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_drv.h
260 to signal before 259. As such, process each fence_id
individually.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 16 ++--
drivers/gpu/drm/virtio/virtgpu_vq.c| 15 +++
2 files changed, 17 insertions(+), 14 deleti
From: Anthoine Bourgeois
This implements the context initialization ioctl. A list of params
is passed in by userspace, and kernel driver validates them. The
only currently supported param is VIRTGPU_CONTEXT_PARAM_CAPSET_ID.
If the context has already been initialized, -EEXIST is returned.
This
We don't want fences from different 3D contexts (virgl, gfxstream,
venus) to be on the same timeline. With explicit context creation,
we can specify the number of ring each context wants.
Execbuffer can specify which ring to use.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng
f KMS events. The parameter
VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK specifies the pollable
rings.
Signed-off-by: Gurchetan Singh
Acked-by: Nicholas Verne
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 22 +-
2 files changed, 22 inser
common way to receive responses with
virtgpu]. As such, there is no context specific read(..)
implementation either -- just a poll(..) implementation.
Signed-off-by: Gurchetan Singh
Acked-by: Nicholas Verne
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 43 +-
drivers/gpu/drm
This advertises the context init feature to userspace, along with
a mask of supported capabilities.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
On Fri, Sep 10, 2021 at 12:33 PM Chia-I Wu wrote:
> On Wed, Sep 8, 2021 at 6:37 PM Gurchetan Singh
> wrote:
> >
> > We don't want fences from different 3D contexts (virgl, gfxstream,
> > venus) to be on the same timeline. With explicit context creation,
> >
On Mon, Sep 13, 2021 at 11:52 AM Chia-I Wu wrote:
> .
>
> On Mon, Sep 13, 2021 at 10:48 AM Gurchetan Singh
> wrote:
> >
> >
> >
> > On Fri, Sep 10, 2021 at 12:33 PM Chia-I Wu wrote:
> >>
> >> On Wed, Sep 8, 2021 at 6:37 PM Gurchetan Sing
On Tue, Sep 14, 2021 at 10:53 AM Chia-I Wu wrote:
> ,On Mon, Sep 13, 2021 at 6:57 PM Gurchetan Singh
> wrote:
> >
> >
> >
> >
> > On Mon, Sep 13, 2021 at 11:52 AM Chia-I Wu wrote:
> >>
> >> .
> >>
> >> On Mon, Sep 13, 2021
On Tue, Sep 14, 2021 at 10:53 PM Gerd Hoffmann wrote:
> On Wed, Sep 08, 2021 at 06:37:13PM -0700, Gurchetan Singh wrote:
> > The plumbing is all here to do this. Since we always use the
> > default fence context when allocating a fence, this makes no
> > functional differe
On Wed, Sep 15, 2021 at 5:11 PM Chia-I Wu wrote:
> i
>
> On Tue, Sep 14, 2021 at 6:26 PM Gurchetan Singh
> wrote:
> >
> >
> >
> > On Tue, Sep 14, 2021 at 10:53 AM Chia-I Wu wrote:
> >>
> >> ,On Mon, Sep 13, 2021 at 6:57 PM Gurchetan Singh
eed implicit sync in patch 9 commit message.
Anthoine Bourgeois (2):
drm/virtio: implement context init: probe for feature
drm/virtio: implement context init: support init ioctl
Gurchetan Singh (10):
virtio-gpu api: multiple context types with explicit initialization
drm/virtgpu api: cre
11
1 23
The "Sommelier" guest Wayland proxy uses this to poll for events
from the host compositor.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
Acked-by: Nicholas Verne
---
include/uapi/drm/virtgpu_drm.h | 27
The valid capability IDs are between 1 to 63, and defined in the
virtio gpu spec. This is used for error checking the subsequent
patches. We're currently only using 2 capability IDs, so this
should be plenty for the immediate future.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng
l the
host which per-context command ring (or "hardware queue", distinct
from the virtio-queue) the fence should be associated with.
The new capability sets (gfxstream, venus etc.) are only defined in
the virtio-gpu spec and not defined in the header.
Signed-off-by: Gurchetan
From: Anthoine Bourgeois
Let's probe for VIRTIO_GPU_F_CONTEXT_INIT.
Create a new DRM_INFO(..) line since the current one is getting
too long.
Signed-off-by: Anthoine Bourgeois
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c
r GPU
commands.
As such, we'll need to specify these parameters when allocating a
dma_fence.
vgdev->fence_drv.context is the "default" fence context for 2D mode
and old userspace.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_drv.h
e_ctx. The ring_idx will
be emitted to host userspace, when emit_fence_info is true.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/
From: Anthoine Bourgeois
This implements the context initialization ioctl. A list of params
is passed in by userspace, and kernel driver validates them. The
only currently supported param is VIRTGPU_CONTEXT_PARAM_CAPSET_ID.
If the context has already been initialized, -EEXIST is returned.
This
f KMS events. The parameter
VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK specifies the pollable
rings.
Signed-off-by: Gurchetan Singh
Acked-by: Nicholas Verne
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 22 +-
2 files changed, 22 inser
260 to signal before 259. As such, process each fence_id
individually.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 16 ++--
drivers/gpu/drm/virtio/virtgpu_vq.c| 15 +++
2 files changed, 17 insertions(+), 14 deleti
sync
support in case a buffer object comes from a different context
type. This can be added later when the revelant context types
support multiple rings, by waiting on the reservation object
associated with the foreign context's buffer object.
Signed-off-by: Gurchetan Singh
Acked-by: Lin
common way to receive responses with
virtgpu]. As such, there is no context specific read(..)
implementation either -- just a poll(..) implementation.
Signed-off-by: Gurchetan Singh
Acked-by: Nicholas Verne
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 43 +-
drivers/gpu/drm
This advertises the context init feature to userspace, along with
a mask of supported capabilities.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
ts/cgroups/msg27867.html
[4] https://www.spinics.net/lists/linux-doc/msg97788.html
[5] https://source.android.com/devices/graphics/implement-dma-buf-gpu-mem
Gurchetan Singh (8):
tracing/gpu: modify gpu_mem_total
drm: add new tracepoint fields to drm_device and drm_file
drm: add helper functions
- Add helper functions for above tracepoints in the drm_gem.{h,c}
files
- Given more tracepoints, a drm_trace.* file may be started
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_gem.c | 49 +++
include/drm
ps://lore.kernel.org/r/20200302234840.57188-1-zzyi...@google.com/
[2] https://www.spinics.net/lists/kernel/msg4062769.html
Signed-off-by: Gurchetan Singh
---
include/trace/events/gpu_mem.h | 61 --
1 file changed, 43 insertions(+), 18 deletions(-)
diff --git a/include
Sometimes, an exported dma-buf is added to the import list.
That messes up with trace point accounting, so track real vs.
fake imports to correct this.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 5 -
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm
- drm_gem_handle_create_tail(..) increases the per instance
memory counter.
- drm_gem_object_release_handle(..) decreases the per instance
memory counter.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm
- drm_gem_prime_fd_to_handle increases the per-instance imported
memory counter
- drm_gem_remove_prime_handles decreases the per-instance imported
memory counter on non-fake imports.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 3 +++
drivers/gpu/drm/drm_prime.c | 2
ff-by: Gurchetan Singh
---
drivers/gpu/drm/drm_gem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 24a719b79400..528d7b29dccf 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -213,6 +213,7 @@
For struct drm_device, add:
- mem_total
- import_mem_total
For struct drm_file, add:
- mem_instance
- import_mem_instance
Signed-off-by: Gurchetan Singh
---
include/drm/drm_device.h | 16
include/drm/drm_file.h | 16
2 files changed, 32
import memory
counter.
* All drivers seem to use it?
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_prime.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1afcae0c4038..c2057b7a63b4 100644
--- a/drivers/gpu/drm
eed implicit sync in patch 9.
Changes since v2:
* u8 ring_idx --> __u8 ring_idx to fix buildbot issues
Anthoine Bourgeois (2):
drm/virtio: implement context init: probe for feature
drm/virtio: implement context init: support init ioctl
Gurchetan Singh (10):
virtio-gpu api: multiple c
l the
host which per-context command ring (or "hardware queue", distinct
from the virtio-queue) the fence should be associated with.
The new capability sets (gfxstream, venus etc.) are only defined in
the virtio-gpu spec and not defined in the header.
Signed-off-by: Gurchetan
11
1 23
The "Sommelier" guest Wayland proxy uses this to poll for events
from the host compositor.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
Acked-by: Nicholas Verne
---
include/uapi/drm/virtgpu_drm.h | 27
From: Anthoine Bourgeois
Let's probe for VIRTIO_GPU_F_CONTEXT_INIT.
Create a new DRM_INFO(..) line since the current one is getting
too long.
Signed-off-by: Anthoine Bourgeois
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c
The valid capability IDs are between 1 to 63, and defined in the
virtio gpu spec. This is used for error checking the subsequent
patches. We're currently only using 2 capability IDs, so this
should be plenty for the immediate future.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng
We don't want fences from different 3D contexts (virgl, gfxstream,
venus) to be on the same timeline. With explicit context creation,
we can specify the number of ring each context wants.
Execbuffer can specify which ring to use.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng
From: Anthoine Bourgeois
This implements the context initialization ioctl. A list of params
is passed in by userspace, and kernel driver validates them. The
only currently supported param is VIRTGPU_CONTEXT_PARAM_CAPSET_ID.
If the context has already been initialized, -EEXIST is returned.
This
common way to receive responses with
virtgpu]. As such, there is no context specific read(..)
implementation either -- just a poll(..) implementation.
Signed-off-by: Gurchetan Singh
Acked-by: Nicholas Verne
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 43 +-
drivers/gpu/drm
This advertises the context init feature to userspace, along with
a mask of supported capabilities.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
e_ctx. The ring_idx will
be emitted to host userspace, when emit_fence_info is true.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/
260 to signal before 259. As such, process each fence_id
individually.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 16 ++--
drivers/gpu/drm/virtio/virtgpu_vq.c| 15 +++
2 files changed, 17 insertions(+), 14 deleti
f KMS events. The parameter
VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK specifies the pollable
rings.
Signed-off-by: Gurchetan Singh
Acked-by: Nicholas Verne
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 22 +-
2 files changed, 22 inser
r GPU
commands.
As such, we'll need to specify these parameters when allocating a
dma_fence.
vgdev->fence_drv.context is the "default" fence context for 2D mode
and old userspace.
Signed-off-by: Gurchetan Singh
Acked-by: Lingfeng Yang
---
drivers/gpu/drm/virtio/virtgpu_drv.h
From: Gurchetan Singh
If vfpriv is null, we shouldn't check vfpriv->ring_idx_mask.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
b/drivers/gpu/dr
On Mon, Nov 15, 2021 at 9:58 AM Gurchetan Singh
wrote:
> From: Gurchetan Singh
>
> If vfpriv is null, we shouldn't check vfpriv->ring_idx_mask.
>
> Signed-off-by: Gurchetan Singh
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
> 1 file changed, 1 inse
#x27;s not rare for virtio to "special things" (see virtio_dma_buf_ops,
virtio_dma_ops), since they are in fake devices.
We're open to other ideas, but hopefully that answers some of your
questions.
> Thanks, Daniel
>
> >
> > Thanks,
> > Vivek
> >
On Fri, Nov 19, 2021 at 9:38 AM Rob Clark wrote:
> On Thu, Nov 18, 2021 at 12:53 AM Daniel Vetter wrote:
> >
> > On Tue, Nov 16, 2021 at 06:31:10PM -0800, Gurchetan Singh wrote:
> > > On Tue, Nov 16, 2021 at 7:43 AM Daniel Vetter wrote:
> > >
> > >
From: Gurchetan Singh
There was a desire to not have a virtgpu-specific implementation of
poll(..), but there wasn't any real event to return either.
Solution: Dummy event with just event code
Context:
https://lists.freedesktop.org/archives/dri-devel/2021-November/330950.html
User
From: Gurchetan Singh
The current virtgpu implementation of poll(..) drops events
when VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is enabled (otherwise
it's like a normal DRM driver).
This is because paravirtualized userspaces receives responses in a
buffer of type BLOB_MEM_GUEST, not by
From: Gurchetan Singh
With the use of dummy events, we can drop virtgpu specific
behavior.
Fixes: cd7f5ca33585 ("drm/virtio: implement context init: add
virtio_gpu_fence_event")
Reported-by: Daniel Vetter
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_
On Thu, Jan 7, 2021 at 1:07 PM Chia-I Wu wrote:
> The context might still be missing when DRM_IOCTL_PRIME_FD_TO_HANDLE is
> the first ioctl on the drm_file.
>
> Fixes: 72b48ae800da ("drm/virtio: enqueue virtio_gpu_create_context after
> the first 3D ioctl")
> Cc:
,
> resulting in prime export never working for vram objects.
>
> Cc: Gurchetan Singh
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Signed-off-by: Chia-I Wu
> ---
> drivers/gpu/drm/virtio/virtgpu_vram.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/dr
rtio: factor out the sg_table from
> virtio_gpu_object")
> Signed-off-by: Miaoqian Lin
>
Reviewed-by: Gurchetan Singh
> ---
> drivers/gpu/drm/virtio/virtgpu_object.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/v
On Wed, Apr 10, 2019 at 4:42 AM Gerd Hoffmann wrote:
> Add comments to the existing feature flags,
> documenting which commands belong to them.
>
> Signed-off-by: Gerd Hoffmann
>
This patch is:
Reviewed-by: Gurchetan Singh
> ---
> include/uapi/linux/virtio_gpu.h |
On Wed, Apr 10, 2019 at 4:42 AM Gerd Hoffmann wrote:
> Add new command VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 to create resources.
> It adds (a) support planar resources and (b) returns stride and size of
> the resource planes. The later will be needed in case we support
> mapping host resources into
On Wed, Apr 10, 2019 at 10:03 PM Gerd Hoffmann wrote:
>
> > > +/* VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 */
> > > +struct virtio_gpu_cmd_resource_create_v2 {
> > > + struct virtio_gpu_ctrl_hdr hdr;
> > > + __le32 resource_id;
> > > + __le32 format;
> > > + __le32 width;
> > > +
On Thu, Apr 11, 2019 at 10:49 PM Gerd Hoffmann wrote:
>
> On Thu, Apr 11, 2019 at 06:36:15PM -0700, Gurchetan Singh wrote:
> > On Wed, Apr 10, 2019 at 10:03 PM Gerd Hoffmann wrote:
> > >
> > > > > +/* VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 */
> > >
On Wed, Apr 17, 2019 at 2:57 AM Gerd Hoffmann wrote:
>
> On Fri, Apr 12, 2019 at 04:34:20PM -0700, Chia-I Wu wrote:
> > Hi,
> >
> > I am still new to virgl, and missed the last round of discussion about
> > resource_create_v2.
> >
> > From the discussion below, semantically resource_create_v2 crea
On Wed, Jan 30, 2019 at 1:43 AM Gerd Hoffmann wrote:
>
> There is no need to wait for completion here.
>
> The host will process commands in submit order, so commands can
> reference the new resource just fine even when queued up before
> completion.
Does virtio_gpu_execbuffer_ioctl also wait for
1 - 100 of 401 matches
Mail list logo
