context fence sharing working (with the
> wait pushed down to the host), that's something the current UAPI can't do
> - Work iteratively (i.e, it's fine to merge Mesa/virglrenderer MRs as
> "experimental") and in steps, no need to figure everything out at once
>
> N
On Wed, May 3, 2023 at 10:07 AM Gurchetan Singh
wrote:
>
>
>
> On Mon, May 1, 2023 at 8:38 AM Dmitry Osipenko
> wrote:
>>
>> On 4/16/23 14:52, Dmitry Osipenko wrote:
>> > We have multiple Vulkan context types that are awaiting for the addition
>> > of the sync object DRM UAPI support to the Virt
On Thu, Mar 23, 2023 at 12:05 PM Dmitry Osipenko
wrote:
>
> Add sync object DRM UAPI support to VirtIO-GPU driver. It's required
> for enabling a full-featured Vulkan fencing by Venus and native context
> VirtIO-GPU Mesa drivers.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/virtio/
On Thu, Mar 23, 2023 at 12:05 PM Dmitry Osipenko
wrote:
>
> Move virtio_gpu_execbuffer_ioctl() into separate virtgpu_submit.c file
> and refactor the code along the way to ease addition of new features to
> the ioctl.
>
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Rob Clark
On Sun, Mar 19, 2023 at 9:11 AM Dmitry Osipenko
wrote:
>
> Move virtio_gpu_execbuffer_ioctl() into separate virtgpu_submit.c file
> and refactor the code along the way to ease addition of new features to
> the ioctl.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/virtio/Makefile
From: Rob Clark
Add a build option to disable modesetting support. This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.
As the modesetting ioctls are a big surface area for
On Wed, Mar 1, 2023 at 11:25 PM Gerd Hoffmann wrote:
>
> On Thu, Mar 02, 2023 at 12:39:33AM +0300, Dmitry Osipenko wrote:
> > On 3/1/23 21:54, Rob Clark wrote:
> > > /* virtgpu_display.c */
> > > +#if defined(CONFIG_DRM_VIRTIO_GPU_KMS)
> > > int virtio_gp
From: Rob Clark
Add a build option to disable modesetting support. This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.
As the modesetting ioctls are a big surface area for
From: Rob Clark
Add a build option to disable modesetting support. This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.
As the modesetting ioctls are a big surface area for
On Tue, Feb 28, 2023 at 4:34 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 27.02.23 um 19:15 schrieb Rob Clark:
> > On Mon, Feb 27, 2023 at 9:57 AM Dmitry Osipenko
> > wrote:
> >>
> >> On 2/27/23 20:38, Rob Clark wrote:
> >> ...
&
On Mon, Feb 27, 2023 at 9:57 AM Dmitry Osipenko
wrote:
>
> On 2/27/23 20:38, Rob Clark wrote:
> ...
> > + if (IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS)) {
> > + /* get display info */
> > + virtio_cread_le(vgdev->
From: Rob Clark
Add a build option to disable modesetting support. This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.
v2: Use more if (IS_ENABLED(...))
v3: Also permit the host
On Mon, Feb 27, 2023 at 8:16 AM Daniel Vetter wrote:
>
> On Mon, Feb 27, 2023 at 08:01:13AM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > Add a build option to disable modesetting support. This is useful in
> > cases where the guest only needs to use
From: Rob Clark
Add a build option to disable modesetting support. This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.
v2: Use more if (IS_ENABLED(...))
Signed-off-by: Rob Clark
On Sun, Feb 26, 2023 at 10:38 PM Gerd Hoffmann wrote:
>
> On Fri, Feb 24, 2023 at 10:02:24AM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > Add a build option to disable modesetting support. This is useful in
> > cases where the guest only needs to use
From: Rob Clark
Add a build option to disable modesetting support. This is useful in
cases where the guest only needs to use the GPU in a headless mode, or
(such as in the CrOS usage) window surfaces are proxied to a host
compositor.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/virtio
synchronization")
> Signed-off-by: Ryan Neph
Reviewed-by: Rob Clark
> ---
>
> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 9 ++---
> include/uapi/drm/virtgpu_drm.h | 3 +++
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/v
On Mon, Jan 9, 2023 at 3:28 PM Dmitry Osipenko
wrote:
>
> On 12/17/22 02:33, Rob Clark wrote:
> > From: Rob Clark
> >
> > Userspace can guess the handle value and try to race GEM object creation
> > with handle close, resulting in a use-after-free if we dereference
From: Rob Clark
Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference. For that reason, dropping
the handle's reference must be done *after* w
From: Rob Clark
Add a sequence # for more easily matching up cmd/resp, and the # of free
slots in the virtqueue to more easily see starvation issues.
v2: Fix handling of string fields as well
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Osipenko
---
drivers/gpu/drm/virtio/virtgpu_drv.h
From: Rob Clark
Add a sequence # for more easily matching up cmd/resp, and the # of free
slots in the virtqueue to more easily see starvation issues.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +++
drivers/gpu/drm/virtio/virtgpu_trace.h | 20
m the loop.
>
> This problem was found during shrinker/madvise IOCTL testing of
> virtio-gpu driver. The MSM driver is affected in the same way.
>
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem.c | 9 ++
On Wed, Sep 7, 2022 at 3:25 AM Dmitry Osipenko
wrote:
>
> On 8/23/22 19:47, Rob Clark wrote:
> > On Tue, Aug 23, 2022 at 3:01 AM Christian König
> > wrote:
> >>
> >> Am 22.08.22 um 19:26 schrieb Dmitry Osipenko:
> >>> On 8/16/22 22:55, Dmitry Os
iately stop this completely broken approach. We have discussed
> > this multiple times now.
>
> Yeah we need to get this stuff closed for real by tagging them all with
> VM_IO or VM_PFNMAP asap.
>
> It seems ot be a recurring amount of fun that people try to mmap dma-buf
> and
On Tue, Aug 23, 2022 at 3:01 AM Christian König
wrote:
>
> Am 22.08.22 um 19:26 schrieb Dmitry Osipenko:
> > On 8/16/22 22:55, Dmitry Osipenko wrote:
> >> On 8/16/22 15:03, Christian König wrote:
> >>> Am 16.08.22 um 13:44 schrieb Dmitry Osipenko:
> [SNIP]
> > The other complication I not
On Tue, Aug 16, 2022 at 4:45 AM Dmitry Osipenko
wrote:
>
> On 8/12/22 18:01, Rob Clark wrote:
> > On Fri, Aug 12, 2022 at 7:57 AM Rob Clark wrote:
> >>
> >> On Fri, Aug 12, 2022 at 4:26 AM Dmitry Osipenko
> >> wrote:
> >>>
> >>> On
From: Rob Clark
When VIRTGPU_EXECBUF_RING_IDX is used, we should be considering the
timeline that the EB if running on rather than the global driver fence
context.
Fixes: 85c83ea915ed ("drm/virtio: implement context init: allocate an array of
fence contexts")
Signed-off-by:
On Fri, Aug 12, 2022 at 7:57 AM Rob Clark wrote:
>
> On Fri, Aug 12, 2022 at 4:26 AM Dmitry Osipenko
> wrote:
> >
> > On 8/11/22 02:19, Rob Clark wrote:
> > > On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osipenko
> > > wrote:
> > >>
> > >
On Fri, Aug 12, 2022 at 4:26 AM Dmitry Osipenko
wrote:
>
> On 8/11/22 02:19, Rob Clark wrote:
> > On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osipenko
> > wrote:
> >>
> >> On 8/11/22 01:03, Rob Clark wrote:
> >>> On Wed, Aug 10, 2022 at 12:26 PM Dmitry
On Wed, Aug 10, 2022 at 3:23 PM Dmitry Osipenko
wrote:
>
> On 8/11/22 01:03, Rob Clark wrote:
> > On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko
> > wrote:
> >>
> >> On 8/10/22 18:08, Rob Clark wrote:
> >>> On Wed, Aug 10, 2022 at 4:47 AM Da
On Wed, Aug 10, 2022 at 12:26 PM Dmitry Osipenko
wrote:
>
> On 8/10/22 18:08, Rob Clark wrote:
> > On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote:
> >>
> >> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote:
> >>> On 7/6/22 00:48, Rob
On Wed, Aug 10, 2022 at 4:47 AM Daniel Vetter wrote:
>
> On Wed, Jul 06, 2022 at 10:02:07AM +0300, Dmitry Osipenko wrote:
> > On 7/6/22 00:48, Rob Clark wrote:
> > > On Tue, Jul 5, 2022 at 4:51 AM Christian König
> > > wrote:
> > >>
> >
On Tue, Jul 5, 2022 at 4:51 AM Christian König wrote:
>
> Am 01.07.22 um 11:02 schrieb Dmitry Osipenko:
> > Drivers that use drm_gem_mmap() and drm_gem_mmap_obj() helpers don't
> > handle imported dma-bufs properly, which results in mapping of something
> > else than the imported dma-buf. On NVIDI
On Tue, Jul 5, 2022 at 10:02 AM Dmitry Osipenko
wrote:
>
> On 7/5/22 18:45, Gerd Hoffmann wrote:
> > Hi,
> >
> >>> Also note that pci is not the only virtio transport we have.
> >>
> >> The VirtIO indeed has other transports, but only PCI is really supported
> >> in case of the VirtIO-GPU in ker
On Tue, Jun 28, 2022 at 5:51 AM Dmitry Osipenko
wrote:
>
> On 6/28/22 15:31, Robin Murphy wrote:
> > ->8-
> > [ 68.295951] ==
> > [ 68.295956] WARNING: possible circular locking dependency detected
> > [ 68.295963] 5.19.0-rc3+ #400
()
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker
On Mon, Jun 20, 2022 at 7:09 AM Dmitry Osipenko
wrote:
>
> On 6/19/22 20:53, Rob Clark wrote:
> ...
> >> +static unsigned long
> >> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> >> +struct shrink_cont
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker driv
ages_use_count=1 means the pages are allowed to
> be evicted and purged if shrinker is enabled. Then the further
> drm_gem_shmem_pin/vmap() calls will bump the pages_use_count,
> disallowing the eviction and purging, like you're suggesting, and we
> won't need the explicit counts.
On Sun, Jun 5, 2022 at 9:47 AM Daniel Vetter wrote:
>
> On Fri, 27 May 2022 at 01:55, Dmitry Osipenko
> wrote:
> >
> > Introduce a common DRM SHMEM shrinker framework that allows to reduce
> > code duplication among DRM drivers by replacing theirs custom shrinker
> > implementations with the gene
On Tue, Apr 5, 2022 at 10:57 AM Chia-I Wu wrote:
>
> On Tue, Apr 5, 2022 at 10:38 AM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > It would have been cleaner to have a flag to *request* the fence event.
> > But that ship has sailed. So add a flag so t
From: Rob Clark
It would have been cleaner to have a flag to *request* the fence event.
But that ship has sailed. So add a flag so that userspace which doesn't
care about the events can opt-out.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8 +---
include
On Wed, Mar 16, 2022 at 5:13 PM Dmitry Osipenko
wrote:
>
> On 3/16/22 23:00, Rob Clark wrote:
> > On Mon, Mar 14, 2022 at 3:44 PM Dmitry Osipenko
> > wrote:
> >>
> >> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> >> duplication a
On Mon, Mar 14, 2022 at 3:44 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> duplication among DRM drivers, it also handles complicated lockings
> for the drivers. This is initial version of the shrinker that covers
> basic needs of GPU drivers.
>
>
On Wed, Mar 9, 2022 at 12:06 PM Dmitry Osipenko
wrote:
>
> On 3/9/22 03:56, Rob Clark wrote:
> >> If we really can't track madvise state in the guest for dealing with
> >> host memory pressure, I think the better option is to introduce
> >> MADV:WILLNEED_R
On Tue, Mar 8, 2022 at 5:17 AM Dmitry Osipenko
wrote:
>
> Add memory shrinker and new madvise IOCTL to the VirtIO-GPU driver.
> Userspace (BO cache manager of Mesa driver) will mark BOs as "don't need"
> using the new IOCTL to let shrinker purge the marked BOs on OOM, thus
> shrinker will lower me
On Tue, Mar 8, 2022 at 3:36 PM Dmitry Osipenko
wrote:
>
> On 3/9/22 01:24, Rob Clark wrote:
> > On Tue, Mar 8, 2022 at 11:28 AM Dmitry Osipenko
> > wrote:
> >>
> >> On 3/8/22 19:29, Rob Clark wrote:
> >>> On Tue, Mar 8, 2022 at 5:17 AM D
On Tue, Mar 8, 2022 at 11:28 AM Dmitry Osipenko
wrote:
>
> On 3/8/22 19:29, Rob Clark wrote:
> > On Tue, Mar 8, 2022 at 5:17 AM Dmitry Osipenko
> > wrote:
> >>
> >> Hello,
> >>
> >> This patchset introduces memory shrinker for the VirtIO-GPU
On Tue, Mar 8, 2022 at 5:17 AM Dmitry Osipenko
wrote:
>
> Hello,
>
> This patchset introduces memory shrinker for the VirtIO-GPU DRM driver.
> During OOM, the shrinker will release BOs that are marked as "not needed"
> by userspace using the new madvise IOCTL. The userspace in this case is
> the M
From: Rob Clark
With native userspace drivers in guest, a lot of GEM objects need to be
neither shared nor mappable. And in fact making everything mappable
and/or sharable results in unreasonably high fd usage in host VMM.
Signed-off-by: Rob Clark
---
This is for a thing I'm working on,
On Fri, Feb 18, 2022 at 8:42 AM Chia-I Wu wrote:
>
> On Fri, Feb 18, 2022 at 7:57 AM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > With native userspace drivers in guest, a lot of GEM objects need to be
> > neither shared nor mappable. And in fact m
From: Rob Clark
With native userspace drivers in guest, a lot of GEM objects need to be
neither shared nor mappable. And in fact making everything mappable
and/or sharable results in unreasonably high fd usage in host VMM.
Signed-off-by: Rob Clark
---
This is for a thing I'm working on,
From: Rob Clark
The UABI was already defined for pointer to 64b value, and all the
userspace users of this ioctl that I could find are already using a
uint64_t (but zeroing it out to work around kernel only copying 32b).
Unfortunately this ioctl doesn't have a length field, so out of paran
On Thu, Mar 4, 2021 at 7:48 AM Robin Murphy wrote:
>
> On 2021-03-01 08:42, Christoph Hellwig wrote:
> > Signed-off-by: Christoph Hellwig
>
> Moreso than the previous patch, where the feature is at least relatively
> generic (note that there's a bunch of in-flight development around
> DOMAIN_ATTR
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
v3: rebased on drm-tip
drivers/gpu/drm/drm_gem.c | 8
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c | 4
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 10 ++
drivers/gpu/drm/drm_gem_vram_helper.c | 6 --
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/etnaviv
56 matches
Mail list logo
