From: Eric Anholt <eric@anholt.net>
To: "Noralf Trønnes" <noralf@tronnes.org>, dri-devel@lists.freedesktop.org
Subject: Re: drm: Why shmem?
Date: Mon, 28 Aug 2017 13:40:41 -0700 [thread overview]
Message-ID: <87wp5n5sty.fsf@anholt.net> (raw)
In-Reply-To: <febc4082-8080-c25f-edf9-343c526d8915@tronnes.org>
[-- Attachment #1.1: Type: text/plain, Size: 778 bytes --]
Noralf Trønnes <noralf@tronnes.org> writes:
> Hi,
>
> Currently I'm using the cma library with tinydrm because it was so
> simple to use even though I have to work around the fact that reads are
> uncached. A bigger problem that I have become aware of, is that it
> restricts the dma buffers it can import since they have to be continous.
>
> So I looked to udl and it uses shmem. Fine, let's make a shmem gem
> library similar to the cma library.
>
> Now I have done so and have started to think about the DOC: section,
> explaining what the library does. And I'm stuck, what's the benefit of
> using shmem compared to just using alloc_page()?
Using shmem means that, when the buffer isn't pinned for DMA usage by
the device, the pages can be swapped out.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-08-28 20:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-28 18:44 drm: Why shmem? Noralf Trønnes
2017-08-28 20:40 ` Eric Anholt [this message]
2017-08-28 20:45 ` Daniel Vetter
2017-08-29 17:40 ` Eric Anholt
2017-08-30 7:40 ` Daniel Vetter
2017-09-14 23:40 ` Noralf Trønnes
2017-09-15 0:45 ` Eric Anholt
2017-09-15 14:38 ` Noralf Trønnes
2017-09-16 22:10 ` 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=87wp5n5sty.fsf@anholt.net \
--to=eric@anholt.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=noralf@tronnes.org \
/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.