linux-kernel - Re: [RFC] drm/fourcc: Add a modifier for contiguous memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 29 Nov 2022 18:57:27 +0800
From:   Hsia-Jun Li <Randy.Li@...aptics.com>
To:     Daniel Stone <daniel@...ishbar.org>
Cc:     dri-devel@...ts.freedesktop.org, ayaka@...lik.info,
        linux-kernel@...r.kernel.org, nicolas@...fresne.ca,
        hverkuil@...all.nl, tzimmermann@...e.de, tfiga@...omium.org,
        linux-media@...r.kernel.org, ppaalanen@...il.com
Subject: Re: [RFC] drm/fourcc: Add a modifier for contiguous memory



On 11/29/22 18:42, Daniel Stone wrote:
> CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Hi Randy,
> 
> On Tue, 29 Nov 2022 at 10:11, Hsia-Jun Li <randy.li@...aptics.com> wrote:
>> Currently, we assume all the pixel formats are multiple planes, devices
>> could support each component has its own memory plane.
>> But that may not apply for any device in the world. We could have a
>> device without IOMMU then this is not impossible.
>>
>> Besides, when we export an handle through the PRIME, the upstream
>> device(likes a capture card or camera) may not support non-contiguous
>> memory. It would be better to allocate the handle in contiguous memory
>> at the first time.
>>
>> We may think the memory allocation is done in user space, we could do
>> the trick there. But the dumb_create() sometimes is not the right API
>> for that.
>>
>> "Note that userspace is not allowed to use such objects for render
>> acceleration - drivers must create their own private ioctls for such a
>> use case."
>> "Note that dumb objects may not be used for gpu acceleration, as has
>> been attempted on some ARM embedded platforms. Such drivers really must
>> have a hardware-specific ioctl to allocate suitable buffer objects."
>>
>> We need to relay on those device custom APIs then. It would be helpful
>> for their library to calculate the right size for contiguous memory. It
>> would be useful for the driver supports rendering dumb buffer as well.
> 
> As a buffer can only have a single modifier, this isn't practical.
Usually only those legacy or low cost devices would request this 
modifier. Unlikely they would support tile format(or we would add 
support for them).

But yes, we would be better not set a trap for us.
> Contiguous needs to be negotiated separately and out of band. See e.g.
> dma-heaps for this.
I don't really like the Android way here. If we are in a world of no 
hot-plug. That would be fine.

V4L2 has had a way to negotiate the memory layout it could support. 
Android gralloc would use the fixed platform sentences to decide the 
memory layout and buffer size. That is not flexible.

So would it be better that I add a common property(a list be the same 
length of the formats property) in drm_plane ?
> 
> Cheers,
> Daniel

-- 
Hsia-Jun(Randy) Li