lkml.org 
[lkml]   [2024]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Safety of opening up /dev/dma_heap/* to physically present users (udev uaccess tag) ?
From
Date
Le jeudi 16 mai 2024 à 14:20 +0300, Laurent Pinchart a écrit :
> On Thu, May 16, 2024 at 07:00:31AM +0000, Simon Ser wrote:
> > On Tuesday, May 14th, 2024 at 22:42, Laurent Pinchart wrote:
> >
> > > My experience on Arm platforms is that the KMS drivers offer allocation
> > > for scanout buffers, not render buffers, and mostly using the dumb
> > > allocator API. If the KMS device can scan out YUV natively, YUV buffer
> > > allocation should be supported. Am I missing something here ?
> >
> > Note that dumb buffers are only intended for simple software-rendering
> > use-cases. Anything more complicated (e.g. involving GPU rendering)
> > should use another mechanism.
>
> Sure. Even if dumb buffers may work for GPU rendering in some cases,
> there's no guarantee they will, so they shouldn't be used.
>
> My comment was related to scanout buffers, as I was puzzled by Nicolas
> mentioning how "KMS drivers only offer allocation for render buffers".
> On Arm platforms the render buffers are allocated on the GPU's DRM
> device as far as I understand, while the KMS drivers allocate scanout
> buffers using the dumb buffers API.
>

The message is getting distorted. I'm saying that not all supported formats have
an allocation API in DRM/KMS drivers. Most YUV formats needed for media handling
(GPU or scannout) are not supported.

Nicolas

p.s. I feel like commenters thinks its evident for userspace application to know
if they are doing scanout or GPU ... while in reality, they offload their
allocated buffer to a compositor which will have to dynamically juggle between
these two with its own heuristic.


\
 
 \ /
  Last update: 2024-05-22 15:02    [W:0.238 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site