On Mon, Jan 16, 2017 at 11:54:14PM +0100, Marek Olšák wrote:
> Thanks for all the feedback. Things are much clearer now.
>
> Yeah, we can use the BO modifiers for simple 2D images / planes if
> that's the general direction. I think we can even stuff the
> compression data buffer offset into those
Thanks for all the feedback. Things are much clearer now.
Yeah, we can use the BO modifiers for simple 2D images / planes if
that's the general direction. I think we can even stuff the
compression data buffer offset into those 64 bits, considering it's
not very large (e.g. below 4GB and low bits
Am 04.01.2017 um 17:16 schrieb Rob Clark:
> On Wed, Jan 4, 2017 at 11:02 AM, Christian König
> wrote:
>> Am 04.01.2017 um 16:47 schrieb Rob Clark:
>>> On Wed, Jan 4, 2017 at 9:54 AM, Daniel Vetter wrote:
On Wed, Jan 04, 2017 at 08:06:24AM -0500, Rob Clark wrote:
> On Wed, Jan 4, 2017
Am 04.01.2017 um 16:47 schrieb Rob Clark:
> On Wed, Jan 4, 2017 at 9:54 AM, Daniel Vetter wrote:
>> On Wed, Jan 04, 2017 at 08:06:24AM -0500, Rob Clark wrote:
>>> On Wed, Jan 4, 2017 at 7:03 AM, Daniel Stone
>>> wrote:
> Speaking of compression for display, especially the separate
>
Hi Christian,
On 4 January 2017 at 16:02, Christian König wrote:
> Am 04.01.2017 um 16:47 schrieb Rob Clark:
>> If the position of the different parts of the buffer are somewhere
>> required to be a function of w/h/bpp/etc then I'm not sure if there is
>> a strong advantage to treating them as
On Wed, Jan 04, 2017 at 08:06:24AM -0500, Rob Clark wrote:
> On Wed, Jan 4, 2017 at 7:03 AM, Daniel Stone wrote:
> >> Speaking of compression for display, especially the separate
> >> compression buffer: That should be fully contained in the main DMABUF
> >> and described by the per-BO metadata.
Hi Marek,
On 3 January 2017 at 23:38, Marek Olšák wrote:
> I've been thinking about it, and it looks like we're gonna continue
> using immutable per-BO metadata (buffer layout, tiling description,
> compression flags). The reasons are that everything else is less
> economical, and the current
On Wed, Jan 4, 2017 at 11:02 AM, Christian König
wrote:
> Am 04.01.2017 um 16:47 schrieb Rob Clark:
>>
>> On Wed, Jan 4, 2017 at 9:54 AM, Daniel Vetter wrote:
>>>
>>> On Wed, Jan 04, 2017 at 08:06:24AM -0500, Rob Clark wrote:
On Wed, Jan 4, 2017 at 7:03 AM, Daniel Stone
wrote:
On Wed, Jan 4, 2017 at 9:54 AM, Daniel Vetter wrote:
> On Wed, Jan 04, 2017 at 08:06:24AM -0500, Rob Clark wrote:
>> On Wed, Jan 4, 2017 at 7:03 AM, Daniel Stone wrote:
>> >> Speaking of compression for display, especially the separate
>> >> compression buffer: That should be fully contained in
On Wed, Jan 4, 2017 at 7:03 AM, Daniel Stone wrote:
>> Speaking of compression for display, especially the separate
>> compression buffer: That should be fully contained in the main DMABUF
>> and described by the per-BO metadata. Some other drivers want to use a
>> separate DMABUF for the
On Wed, Jan 4, 2017 at 12:43 AM, James Jones wrote:
> On 01/03/2017 03:38 PM, Marek Olšák wrote:
>>
>> On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter wrote:
>>>
>>> On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák wrote:
>>
>> We've had per buffer metadata in Radeon since KMS, which I
On Tue, Jan 3, 2017 at 3:38 PM, Marek Olšák wrote:
> On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter wrote:
>> On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák wrote:
> We've had per buffer metadata in Radeon since KMS, which I believe first
> appeared in 2009. It's 4 bytes large and is
On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter wrote:
> On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák wrote:
We've had per buffer metadata in Radeon since KMS, which I believe first
appeared in 2009. It's 4 bytes large and is used to communicate tiling
flags between Mesa, DDX,
On 01/03/2017 04:06 PM, Marek Olšák wrote:
> On Wed, Jan 4, 2017 at 12:43 AM, James Jones wrote:
>> On 01/03/2017 03:38 PM, Marek Olšák wrote:
>>>
>>> On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter wrote:
On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák wrote:
>>>
>>> We've
On 01/03/2017 03:38 PM, Marek Olšák wrote:
> On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter wrote:
>> On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák wrote:
> We've had per buffer metadata in Radeon since KMS, which I believe first
> appeared in 2009. It's 4 bytes large and is used to
On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák wrote:
>>> We've had per buffer metadata in Radeon since KMS, which I believe first
>>> appeared in 2009. It's 4 bytes large and is used to communicate tiling
>>> flags between Mesa, DDX, and the kernel display code. It was a widely
>>> accepted
On Wed, Oct 19, 2016 at 4:10 PM, Daniel Vetter wrote:
> On Wed, Oct 19, 2016 at 03:15:08PM +0200, Marek Olšák wrote:
>> On Oct 19, 2016 8:24 AM, "Daniel Vetter" wrote:
>> > On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák wrote:
>> > > - The producer-consumer interop API doesn't know about the
On Wed, Oct 19, 2016 at 03:15:08PM +0200, Marek Olšák wrote:
> On Oct 19, 2016 8:24 AM, "Daniel Vetter" wrote:
> > On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák wrote:
> > > - The producer-consumer interop API doesn't know about the metadata.
> > > All you need to pass around is a buffer
On 19/10/16 08:40 AM, Marek Olšák wrote:
>
> 1) DRI (producer: application; consumer: X server)
> - The producer receives these flags: READ, EXPLICIT_FLUSH. The X
> server will treat the shared "texture" as read-only.
FWIW, no, the X server doesn't treat buffers shared with clients via DRI
as
On Oct 19, 2016 2:33 PM, "Nicolai Hähnle" wrote:
>
> On 19.10.2016 01:40, Marek Olšák wrote:
>>
>> * We can build upon this idea. I think the worst thing to do would
>> be to add metadata handling to driver-agnostic userspace APIs. Really,
>> driver-agnostic APIs shouldn't know about that,
On Oct 19, 2016 8:24 AM, "Daniel Vetter" wrote:
>
> On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák wrote:
> > - The producer-consumer interop API doesn't know about the metadata.
> > All you need to pass around is a buffer handle. (KMS, DMABUF, etc.)
> > * There was a note during the talk that
On 19.10.2016 01:40, Marek Olšák wrote:
> * We can build upon this idea. I think the worst thing to do would
> be to add metadata handling to driver-agnostic userspace APIs. Really,
> driver-agnostic APIs shouldn't know about that, because they can't
> understand all the hw-specific
Am 19.10.2016 um 08:23 schrieb Daniel Vetter:
> On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák wrote:
>> - The producer-consumer interop API doesn't know about the metadata.
>> All you need to pass around is a buffer handle. (KMS, DMABUF, etc.)
>>* There was a note during the talk that DMABUF
On Wed, Oct 19, 2016 at 2:08 AM, James Jones wrote:
>> * We can build upon this idea. I think the worst thing to do would
>> be to add metadata handling to driver-agnostic userspace APIs. Really,
>> driver-agnostic APIs shouldn't know about that, because they can't
>> understand all the
On Wed, Oct 19, 2016 at 1:40 AM, Marek Olšák wrote:
> - The producer-consumer interop API doesn't know about the metadata.
> All you need to pass around is a buffer handle. (KMS, DMABUF, etc.)
> * There was a note during the talk that DMABUF doesn't have any
> metadata. Well, I just told you
Hi,
The text below describes how open source AMDGPU buffer sharing works.
I hope you'll find some useful bits in it.
Producer = allocates a buffer (or texture), and exports its handle
(DMABUF, etc.), and can use the buffer in various ways
Consumer = imports the handle, and can use the buffer
Thanks for the detailed writeup, and it was good to meet you at XDC. Below:
On 10/18/2016 04:40 PM, Marek Olšák wrote:
> Hi,
>
> The text below describes how open source AMDGPU buffer sharing works.
> I hope you'll find some useful bits in it.
>
>
> Producer = allocates a buffer (or texture),
Hi,
Do you already have in mind a list of targeted driver/backend/plugin ?
How do you expect to enumerate devices capabilities ? by adding a new
generic ioctl or a configuration file in userland ?
Maybe it is to early for those questions but anyway I'm interested by
this memory allocation
This would be a purely userspace interface (in that user just
interacts w/ a userspace shared lib, the driver specific backend may
do it's own ioctls to query whatever is needed from the hw)..
So might be something like, for each device in the sharing use-case, call:
allocator_dev_t
Hello everyone,
As many are aware, we took up the issue of surface/memory allocation at
XDC this year. The outcome of that discussion was the beginnings of a
design proposal for a library that would server as a cross-device,
cross-process surface allocator. In the past week I've started to
30 matches
Mail list logo
