All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: Rob Clark <robdclark@gmail.com>, dri-devel@lists.freedesktop.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Rob Clark <robdclark@chromium.org>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Emil Velikov <emil.velikov@collabora.com>,
	Eric Biggers <ebiggers@google.com>,
	Deepak Sharma <deepak.sharma@amd.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/3] drm/vgem: use normal cached mmap'ings
Date: Tue, 16 Jul 2019 16:39:11 -0700	[thread overview]
Message-ID: <87lfwxh7mo.fsf@anholt.net> (raw)
In-Reply-To: <20190716213746.4670-3-robdclark@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

Rob Clark <robdclark@gmail.com> writes:

> From: Rob Clark <robdclark@chromium.org>
>
> Since there is no real device associated with VGEM, it is impossible to
> end up with appropriate dev->dma_ops, meaning that we have no way to
> invalidate the shmem pages allocated by VGEM.  So, at least on platforms
> without drm_cflush_pages(), we end up with corruption when cache lines
> from previous usage of VGEM bo pages get evicted to memory.
>
> The only sane option is to use cached mappings.

This may be an improvement, but...

pin/unpin is only on attaching/closing the dma-buf, right?  So, great,
you flushed the cached map once after exporting the vgem dma-buf to the
actual GPU device, but from then on you still have no interface for
getting coherent access through VGEM's mapping again, which still
exists.

I feel like this is papering over something that's really just broken,
and we should stop providing VGEM just because someone wants to write
dma-buf test code without driver-specific BO alloc ioctl code.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2019-07-16 23:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-16 21:37 [PATCH v3 1/3] drm/gem: don't force writecombine mmap'ing Rob Clark
2019-07-16 21:37 ` [PATCH v3 2/3] drm: plumb attaching dev thru to prime_pin/unpin Rob Clark
2019-07-16 21:37   ` Rob Clark
     [not found]   ` <20190716213746.4670-2-robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-07-17  6:59     ` Koenig, Christian
2019-07-17  6:59       ` Koenig, Christian
2019-07-17  6:59   ` Koenig, Christian
2019-07-16 21:37 ` Rob Clark
2019-07-16 21:37 ` [PATCH v3 3/3] drm/vgem: use normal cached mmap'ings Rob Clark
2019-07-16 23:39   ` Eric Anholt [this message]
2019-07-17  0:13     ` Rob Clark
2019-07-19  9:13       ` Daniel Vetter
2019-07-16 22:19 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/3] drm/gem: don't force writecombine mmap'ing Patchwork
2019-07-16 22:52 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-07-16 23:21 ` [Intel-gfx] [PATCH v3 1/3] " Eric Anholt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lfwxh7mo.fsf@anholt.net \
    --to=eric@anholt.net \
    --cc=airlied@linux.ie \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel@ffwll.ch \
    --cc=deepak.sharma@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ebiggers@google.com \
    --cc=emil.velikov@collabora.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.