Nouveau - Jan 2025 - [PATCH v2 25/25] drm/xlnx: Compute dumb-buffer sizes with drm_mode_size_dumb()

On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart
wrote:
> On Wed, Jan 15, 2025 at 02:34:26PM +0000, Daniel Stone wrote:
> > On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
> > > No disagreement there, we need CREATE_DUMB2.
> > >
> > > My point is that we have the current UAPI, and we have userspace
using
> > > it, but we don't have clear rules what the ioctl does with
specific
> > > parameters, and we don't document how it has to be used.
> > >
> > > Perhaps the situation is bad, and all we can really say is that
> > > CREATE_DUMB only works for use with simple RGB formats, and the
behavior
> > > for all other formats is platform specific. But I think even that
would
> > > be valuable in the UAPI docs.
> > 
> > Yeah, CREATE_DUMB only works for use with simple RGB formats in a
> > linear layout. Not monochrome or YUV or tiled or displayed rotated or
> > whatever.
> > 
> > If it happens to accidentally work for other uses, that's fine,
but
> > it's not generically reliable for anything other than simple
linear
> > RGB. It's intended to let you do splash screens, consoles,
recovery
> > password entries, and software-rendered compositors if you really
> > want. Anything more than that isn't 'dumb'.
> 
> We have lots of software out there that rely on CREATE_DUMB supporting
> YUV linear formats, and lots of drivers (mostly on Arm I suppose) that
> implement YUV support in CREATE_DUMB. I'm fine replacing it with
> something better, but I think we need a standard ioctl that can create
> linear YUV buffers. I've been told many times that DRM doesn't want
to
> standardize buffer allocation further than what CREATE_DUMB is made for.
> Can we reconsider this rule then ?
Actually... Instead of adding a CREATE_DUMB2, it would be best on trying
to leverage DMA heaps and deprecate allocating from the KMS device.

-- 
Regards,

Laurent Pinchart

Hi,

On 16/01/2025 11:38, Laurent Pinchart wrote:
> On Thu, Jan 16, 2025 at 10:43:40AM +0200, Laurent Pinchart wrote:
>> On Wed, Jan 15, 2025 at 02:34:26PM +0000, Daniel Stone wrote:
>>> On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen wrote:
>>>> No disagreement there, we need CREATE_DUMB2.
>>>>
>>>> My point is that we have the current UAPI, and we have
userspace using
>>>> it, but we don't have clear rules what the ioctl does with
specific
>>>> parameters, and we don't document how it has to be used.
>>>>
>>>> Perhaps the situation is bad, and all we can really say is that
>>>> CREATE_DUMB only works for use with simple RGB formats, and the
behavior
>>>> for all other formats is platform specific. But I think even
that would
>>>> be valuable in the UAPI docs.
>>>
>>> Yeah, CREATE_DUMB only works for use with simple RGB formats in a
>>> linear layout. Not monochrome or YUV or tiled or displayed rotated
or
>>> whatever.
>>>
>>> If it happens to accidentally work for other uses, that's fine,
but
>>> it's not generically reliable for anything other than simple
linear
>>> RGB. It's intended to let you do splash screens, consoles,
recovery
>>> password entries, and software-rendered compositors if you really
>>> want. Anything more than that isn't 'dumb'.
>>
>> We have lots of software out there that rely on CREATE_DUMB supporting
>> YUV linear formats, and lots of drivers (mostly on Arm I suppose) that
>> implement YUV support in CREATE_DUMB. I'm fine replacing it with
>> something better, but I think we need a standard ioctl that can create
>> linear YUV buffers. I've been told many times that DRM doesn't
want to
>> standardize buffer allocation further than what CREATE_DUMB is made
for.
>> Can we reconsider this rule then ?
> 
> Actually... Instead of adding a CREATE_DUMB2, it would be best on trying
> to leverage DMA heaps and deprecate allocating from the KMS device.
If we allocate from DMA heaps, I think we then need a DRM ioctl which 
will tell you how big buffer(s) you need, based on the size and format.

  Tomi