On 06/09/2014 01:23 PM, Daniel Stone wrote:
> Hi,
>
> On 9 June 2014 12:06, Pekka Paalanen <pekka.paalanen(a)collabora.co.uk
> <mailto:pekka.paalanen@collabora.co.uk>> wrote:
>
> On Mon, 9 Jun 2014 11:00:04 +0200
> Benjamin Gaignard <benjamin.gaignard(a)linaro.org
> <mailto:benjamin.gaignard@linaro.org>> wrote:
> > One of the main comment on the latest patches was that wl_dmabuf use
> > DRM for buffer allocation.
> > This appear to be an issue since wayland doesn't want to rely on one
> > specific framework (DRM, or V4L2) for buffer allocation, so we have
> > start working on a "central dmabuf allocation" on kernel side. The
> > goal is provide some as generic as possible to make it acceptable by
> > wayland.
>
> Why would Wayland need a central allocator for dmabuf?
>
>
> I think you've just answered your own question further below:
>
>
> > On my hardware the patches you have (+ this one on gstwaylandsink
> > https://bugzilla.gnome.org/show_bug.cgi?id=711155
> <https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.gnome.org/show_…>)
> allow me to do zero
> > copy between the hardware video decoder and the display engine. I
> > don't have implemented GPU yet because my hardware is able to do
> > compose few video overlays planes and it was enough for my tests.
>
> Right.
>
> What I have been thinking is, that the compositor must be able to use
> the new wl_buffer and we need to guarantee that before-hand. If the
> compositor fails to use a wl_buffer when the client has already
> attached it to a wl_surface and it is time to repaint, it is too late
> and the user will see a glitch. Recovering from that requires asking
> the client to provide a new wl_buffer of a different kind, which might
> take time. Or a very rude compositor would just send a protocol error,
> and then we'd get bug reports like "the video player just disappears
> when I try to play (and ps. I have an old kernel that doesn't support
> importing whatever)".
>
> I believe we must allow the compositor to test the wl_buffer before it
> is usable for the client. That is the reason for the roundtrippy
> design
> of the below proposal.
>
>
> A central allocator would solve these issues, by having everyone agree
> on the restrictions upfront, instead of working out which of the media
> decode engine, camera, GPU, or display controller is the lowest common
> denominator, and forcing all allocations through there.
>
> One such solution was discussed a while back WRT ION:
> https://lwn.net/Articles/565469/
> <https://urldefense.proofpoint.com/v1/url?u=https://lwn.net/Articles/565469/…>
>
> See the 'possible solutions' part for a way for people to agree on
> restrictions wrt tiling, stride, contiguousness, etc.
Hi!
I think before deciding on something like this, one needs also to
account for the virtual drivers like vmwgfx.
Here, a dma-buf internally holds an opaque handle to an object on the
host / hypervisor, and the actual memory buffer is only temporarily
allocated for dma-buf operations that strictly need it. Not to hold the
data while transferring it between devices or applications.
Let's say you'd want to use a USB display controller in a virtual
machine with the vmwgfx exported prime objects, for example. There's no
common denominator. The vmwgfx driver would need to read the dma-buf
data from the host object at sg-table export (dma-buf map) time.
Whereas if you just want to share data between a wayland server and
client, no pages are ever allocated and the only thing passed
around is in effect the opaque handle to the host / hypervisor object.
I'm currently having trouble seeing how a central allocator would be
able to deal with this?
/Thomas
>
> Cheers,
> Daniel
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel(a)lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mai…
Hi Marek,
The patches for "CMA and get_user_pages" seems to be year old as per the
mailing list link
http://lists.linaro.org/pipermail/linaro-mm-sig/2013-March/003090.html
Is there any latest patch-set for this feature and any updates whether
these patches are to be pushed into main stream kernel sooner.
Thanks!!!
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
The following series implements small updates to the fence api.
I've found them useful when implementing the fence API in ttm and i915.
The last patch enables RCU on top of the api. I've found this less
useful, but it was the condition on which Thomas Hellstrom was ok
with converting TTM to fence, so I had to keep it in.
If nobody objects I'll probably merge that patch through drm, because
some care is needed in ttm before it can flip the switch on rcu.
---
Maarten Lankhorst (2):
reservation: update api and add some helpers
[RFC] reservation: add suppport for read-only access using rcu
On Wed, 14 May 2014 10:15:38 +0100, "Jon Medhurst (Tixy)" <tixy(a)linaro.org> wrote:
> On Sun, 2014-03-02 at 13:40 +0800, Grant Likely wrote:
> > On Fri, 28 Feb 2014 14:42:50 +0100, Marek Szyprowski <m.szyprowski(a)samsung.com> wrote:
> > > This patch adds code for automated assignment of reserved memory regions
> > > to struct device. reserved_mem->ops->device_init()/device_cleanup()
> > > callbacks are called to perform reserved memory driver specific
> > > initialization and cleanup
> > >
> > > Based on previous code provided by Josh Cartwright <joshc(a)codeaurora.org>
> > >
> > > Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
> >
> > Hi Marek,
> >
> > I've not applied this one yet, only because there is still the open
> > issue of whether or not these functions should be called from drivers or
> > from core code. I don't actually have any problems with the content of
> > this patch. Once the user is sorted out I'll merge it.
>
> Has anything more come of these patches? I see some of the series is now
> in Linux 3.15, but the actual patches to let people use the feature
> aren't there yet, namely patches 5 though 8.
>
> My personal immediate interest in these is as a mechanism on arm64 to
> limit CMA to a region of memory that is actually DMA-able devices (e.g.
> below 4GB for 32-bit devices without an iommu).
>
> For reference, the mail archives for this series is at
> http://lkml.org/lkml/2014/2/28/237
IIRC, the issue I have with patch 5-8 is that I don't like the driver core
going off and doing automagical things to attach regions to devices.
I've not seen any more discussion on this topic since I merged the
patches I was okay with, but I may have missed something.
g.