All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Jones <jajones@nvidia.com>
To: Simon Ser <contact@emersion.fr>, Pekka Paalanen <ppaalanen@gmail.com>
Cc: Robert Beckett <bob.beckett@collabora.com>,
	Daniel Stone <daniels@collabora.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] doc: gpu: Add document describing buffer exchange
Date: Mon, 8 Nov 2021 16:21:04 -0800	[thread overview]
Message-ID: <84e4620c-7a37-b5ff-2c1d-45e73a01fea9@nvidia.com> (raw)
In-Reply-To: <a_9frwKbA7AcZbDet-XMAADdlHbhTczh-d1o5rP2HQkkLXvor5XWt51MDaHvpgo_Sox1e3tt7xmfHlMyAI7Na6wcqcgQIPrbtqAblnM8mQ0=@emersion.fr>

On 9/8/21 2:44 AM, Simon Ser wrote:
>> stride
>> 	????
> 
> I think what's clear is:
> 
> - Per-plane property
> - In bytes
> - Offset between two consecutive rows
> 
> How that applies to weird YUV formats is the tricky question…
> 
>> Btw. there was a fun argument whether the same modifier value could
>> mean different things on different devices. There were also arguments
>> that a certain modifier could reference additional implicit memory on
>> the device - memory that can only be accessed by very specific devices.
>>
>> I think AMLOGIC_FBC_LAYOUT_SCATTER was one of those.
> 
> A recent exmaple of this is [1].
> 
> [1]: https://patchwork.freedesktop.org/patch/452461/

What was the resolution to that argument?  It took some fiddling to get 
the NV format modifiers to be robust enough that they actually do 
differentiate "identical" layouts that actually mismatch between devices 
(E.g., some of our SoC GPUs interpret layouts differently than our 
discrete GPUs, so that's reflected in the format modifier-building macro 
and hence applications can properly deduce that they can *not* share 
images directly between these devices, but can share between two similar 
discrete GPUs), so I hope the modifier definition allows that. 
Cross-device sharing using tiled formats in machines with multiple 
similar NV GPUs was an important use case for modifiers on our side.

Thanks,
-James

  reply	other threads:[~2021-11-09  0:21 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-05 12:27 [PATCH] doc: gpu: Add document describing buffer exchange Daniel Stone
2021-09-06 12:28 ` Simon Ser
2021-11-09  0:18   ` James Jones
2021-11-09  9:13     ` Daniel Vetter
2021-11-09  9:22       ` Simon Ser
2023-08-03 15:46       ` Daniel Stone
2023-08-03 15:46         ` Daniel Stone
2021-09-06 17:13 ` Robert Beckett
2021-09-08  9:34 ` Pekka Paalanen
2021-09-08  9:44   ` Simon Ser
2021-11-09  0:21     ` James Jones [this message]
2021-11-09  9:12       ` Daniel Vetter
2021-09-08 18:16 ` Daniel Vetter
2023-08-03 15:47 ` [PATCH v2 0/2] doc: uapi: Document dma-buf interop design & semantics Daniel Stone
2023-08-03 19:47   ` James Jones
2023-08-03 20:30   ` Sebastian Wick
2023-08-03 20:30     ` Sebastian Wick
2023-08-29 13:30   ` [Linaro-mm-sig] " Christian König
2023-08-03 15:47 ` [PATCH v2 1/2] doc: dma-buf: Rewrite intro section a little Daniel Stone
2023-08-03 15:47 ` [PATCH v2 2/2] doc: uapi: Add document describing dma-buf semantics Daniel Stone
2023-08-18 15:37   ` [v2,2/2] " suijingfeng
2023-08-21 13:33   ` [PATCH v2 2/2] " Daniel Vetter
2023-08-21 17:17     ` Simon Ser

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=84e4620c-7a37-b5ff-2c1d-45e73a01fea9@nvidia.com \
    --to=jajones@nvidia.com \
    --cc=bob.beckett@collabora.com \
    --cc=contact@emersion.fr \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ppaalanen@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.