On 11/04/2013 11:22 AM, Lucas Stach wrote:
> Hi Thomas,
>
> I inlined the patch, to discuss more easily.
>
> Am Montag, den 04.11.2013, 08:53 +0100 schrieb Thomas Hellstrom:
>> enum dma_buf_data_direction {
>> DMA_BUF_BIDIRECTIONAL,
>> DMA_BUF_TO_DEVICE,
>> DMA_BUF_FROM_D
Hi Thomas,
I inlined the patch, to discuss more easily.
Am Montag, den 04.11.2013, 08:53 +0100 schrieb Thomas Hellstrom:
> enum dma_buf_data_direction {
> DMA_BUF_BIDIRECTIONAL,
> DMA_BUF_TO_DEVICE,
> DMA_BUF_FROM_DEVICE
> };
I don't think the DMA API semantic makes much
On 11/01/2013 02:32 PM, Lucas Stach wrote:
> Am Freitag, den 01.11.2013, 09:22 -0400 schrieb Rob Clark:
>> On Fri, Nov 1, 2013 at 6:17 AM, Daniel Vetter
>> wrote:
>>> On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach
>>> wrote:
GStreamer needs _some_ way of accessing the buffer contents with th
On 11/01/2013 11:17 AM, Daniel Vetter wrote:
> On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach
> wrote:
>> GStreamer needs _some_ way of accessing the buffer contents with the
>> CPU, this doesn't necessarily have to be the dumb mmap we have right
>> now.
>> DMA-BUF support in GSt is not really fini
Am Freitag, den 01.11.2013, 09:22 -0400 schrieb Rob Clark:
> On Fri, Nov 1, 2013 at 6:17 AM, Daniel Vetter
> wrote:
> > On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach
> > wrote:
> >> GStreamer needs _some_ way of accessing the buffer contents with the
> >> CPU, this doesn't necessarily have to be
On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach wrote:
> GStreamer needs _some_ way of accessing the buffer contents with the
> CPU, this doesn't necessarily have to be the dumb mmap we have right
> now.
> DMA-BUF support in GSt is not really finished (I know we have a lot of
> patches internally to
Am Donnerstag, den 31.10.2013, 20:57 -0400 schrieb Rob Clark:
> On Thu, Oct 31, 2013 at 8:37 PM, Jakob Bornecrantz
> wrote:
> > On Fri, Nov 1, 2013 at 1:25 AM, Rob Clark wrote:
> >> On Thu, Oct 31, 2013 at 8:17 PM, Jakob Bornecrantz >> gmail.com> wrote:
> >>> On Fri, Nov 1, 2013 at 12:00 AM, Da
On Fri, Nov 1, 2013 at 6:17 AM, Daniel Vetter wrote:
> On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach
> wrote:
>> GStreamer needs _some_ way of accessing the buffer contents with the
>> CPU, this doesn't necessarily have to be the dumb mmap we have right
>> now.
>> DMA-BUF support in GSt is not re
On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom
wrote:
> On 10/31/2013 06:52 PM, Rob Clark wrote:
>>
>> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom
>> wrote:
>>>
>>> Hi!
>>>
>>> I'm just looking over what's needed to implement drm Prime / dma-buf
>>> exports
>>> + imports in the vmwgfx dr
On Fri, Nov 1, 2013 at 1:25 AM, Rob Clark wrote:
> On Thu, Oct 31, 2013 at 8:17 PM, Jakob Bornecrantz
> wrote:
>> On Fri, Nov 1, 2013 at 12:00 AM, Daniel Vetter wrote:
>>> On Thu, Oct 31, 2013 at 10:07:25PM +0100, Thomas Hellstrom wrote:
On 10/31/2013 09:48 PM, Dave Airlie wrote:
>On
On Fri, Nov 1, 2013 at 12:00 AM, Daniel Vetter wrote:
> On Thu, Oct 31, 2013 at 10:07:25PM +0100, Thomas Hellstrom wrote:
>> On 10/31/2013 09:48 PM, Dave Airlie wrote:
>> >On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom
>> >wrote:
>> >>Well, I'd be happy to avoid mmap, but then what does option
On Thu, Oct 31, 2013 at 10:07:25PM +0100, Thomas Hellstrom wrote:
> On 10/31/2013 09:48 PM, Dave Airlie wrote:
> >On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom
> >wrote:
> >>Well, I'd be happy to avoid mmap, but then what does optional mean in this
> >>context?
> >>That all generic user-space
user-space cpu access to dma-buf is needed for example in Gstreamer
pipeline when you have mix of harware element (a video decoder) and
software element (like colorspace converter).
Gstreamer already support dma-buf in a specific gstallocator:
http://cgit.freedesktop.org/gstreamer/gst-plugins-base
On 10/31/2013 10:10 PM, Rob Clark wrote:
> On Thu, Oct 31, 2013 at 4:40 PM, Thomas Hellstrom
> wrote:
>> On 10/31/2013 06:52 PM, Rob Clark wrote:
>>> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom
>>> wrote:
Hi!
I'm just looking over what's needed to implement drm Prime / dma-b
On 10/31/2013 09:48 PM, Dave Airlie wrote:
> On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom
> wrote:
>> On 10/31/2013 06:52 PM, Rob Clark wrote:
>>> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom
>>> wrote:
Hi!
I'm just looking over what's needed to implement drm Prime / dma-
On 10/31/2013 06:52 PM, Rob Clark wrote:
> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom
> wrote:
>> Hi!
>>
>> I'm just looking over what's needed to implement drm Prime / dma-buf exports
>> + imports in the vmwgfx driver. It seems like most dma-bufs ops are quite
>> straightforward to implem
On Thu, Oct 31, 2013 at 8:37 PM, Jakob Bornecrantz
wrote:
> On Fri, Nov 1, 2013 at 1:25 AM, Rob Clark wrote:
>> On Thu, Oct 31, 2013 at 8:17 PM, Jakob Bornecrantz
>> wrote:
>>> On Fri, Nov 1, 2013 at 12:00 AM, Daniel Vetter wrote:
On Thu, Oct 31, 2013 at 10:07:25PM +0100, Thomas Hellstro
On Thu, Oct 31, 2013 at 8:17 PM, Jakob Bornecrantz
wrote:
> On Fri, Nov 1, 2013 at 12:00 AM, Daniel Vetter wrote:
>> On Thu, Oct 31, 2013 at 10:07:25PM +0100, Thomas Hellstrom wrote:
>>> On 10/31/2013 09:48 PM, Dave Airlie wrote:
>>> >On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom >> >vmware.c
Hi!
I'm just looking over what's needed to implement drm Prime / dma-buf
exports + imports in the vmwgfx driver. It seems like most dma-bufs ops
are quite straightforward to implement except user-space mmap().
The reason being that vmwgfx dma-bufs will be using completely
non-coherent memory,
On Thu, Oct 31, 2013 at 4:40 PM, Thomas Hellstrom
wrote:
> On 10/31/2013 06:52 PM, Rob Clark wrote:
>>
>> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom
>> wrote:
>>>
>>> Hi!
>>>
>>> I'm just looking over what's needed to implement drm Prime / dma-buf
>>> exports
>>> + imports in the vmwgfx d
On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom
wrote:
> Hi!
>
> I'm just looking over what's needed to implement drm Prime / dma-buf exports
> + imports in the vmwgfx driver. It seems like most dma-bufs ops are quite
> straightforward to implement except user-space mmap().
>
> The reason being
21 matches
Mail list logo