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.
