Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

From: Daniel Vetter <daniel@ffwll.ch>
To: Miguel Angel Vico <mvicomoya@nvidia.com>
Cc: "Rob Clark" <rclark@redhat.com>,
	"Nicolai Hähnle" <nhaehnle@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Jason Ekstrand" <jason.ekstrand@intel.com>,
	"Kristian H. Kristensen" <hoegsberg@google.com>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	"Chad Versace" <chadversary@google.com>,
	"mesa-dev@lists.freedesktop.org" <mesa-dev@lists.freedesktop.org>,
	"Lyude Paul" <cpaul@redhat.com>
Subject: Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces
Date: Mon, 8 Jan 2018 10:35:37 +0100	[thread overview]
Message-ID: <20180108093537.GZ26573@phenom.ffwll.local> (raw)
In-Reply-To: <20171228102438.115a4e64@nvidia.com>

Just wanted to clarify this one thing here, otherwise I think Rob/krh
covered it all.

On Thu, Dec 28, 2017 at 10:24:38AM -0800, Miguel Angel Vico wrote:
> Daniel Vetter wrote:
> > I think in the interim figuring out how to expose kms capabilities
> > better (and necessarily standardizing at least some of them which
> > matter at the compositor level, like size limits of framebuffers)
> > feels like the place to push the ecosystem forward. In some way
> > Miguel's proposal looks a bit backwards, since it adds the pitch
> > capabilities to addfb, but at addfb time you've allocated everything
> > already, so way too late to fix things up. With modifiers we've added
> > a very simple per-plane property to list which modifiers can be
> > combined with which pixel formats. Tiny start, but obviously very far
> > from all that we'll need.  
> 
> Not sure whether I might be misunderstanding your statement, but one of
> the allocator main features is negotiation of nearly optimal allocation
> parameters given a set of uses on different devices/engines by the
> capability merge operation. A client should have queried what every
> device/engine is capable of for the given uses, find the optimal set of
> capabilities, and use it for allocating a buffer. At the moment these
> parameters are given to KMS, they are expected to be good. If they
> aren't, the client didn't do things right.

Your example code has a new capability for PITCH_ALIGNMENT. That looks
wrong for addfb (which should only received the the computed intersection
of all requirements, not the requirements itself). And since that was the
only thing in your example code besides the bare boilerplate to wire it
all up it looks a bit confused.

Maybe we need to distinguish capabilities into constraints on properties
(like pitch alignment, or power-of-two pitch) and properties (like pitch)
themselves.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel