On Wed, Aug 3, 2011 at 17:12, Jordan Crouse <jcro...@codeaurora.org> wrote:
> On 08/03/2011 03:33 AM, Tom Cooksey wrote:
>> Passing buffer meta-data around was also discussed yesterday. Again, the
>> general consensus seemed to be that this data should be kept out of the
>> kernel. The userspace application should know what the buffer format
>> etc. is and can provide that information to the relevant device APIs
>> when is passes in the buffer.
>
> True, but APIs change slowly. Some APIs *cough* OpenMAX *cough* are damn
> near immutable over the life time of a average software release. A blob of
> data attached to a buffer can evolve far more rapidly and be far more
> extensible and much more vendor specific. This isn't an new idea, I think
> the DRM/GEM guys have tossed it around too.
Erh, no. For sharing gem buffers between process (i.e. between direct
rendering clients and the compositor, whatever that is) we just hand
around the gem id in the kernel. Some more stuff gets passed around in
userspace in a generic way (e.g. DRI2 passes the buffer type (depth,
stencil, color, ...) and the stride), but that's it.
Everything else is driver specific and mostly not even passed around
explicitly and just agreed upon implicitly. E.g. running the wrong
XvMC decoder lib for your Xorg Intel driver will result in garbage on
the screen. There's a bit more leeway between Mesa and the Xorg driver
because they're released independantly, but it's very ad-hoc (i.e.
oops, that buffer doesn't fit the requirements of the new code, must
be an old Xorg driver, so switch to the compat paths in Mesa).
But my main fear with the "blob attached to the buffer" idea is that
sooner or later it'll be part of the kernel/userspace interface of the
buffer sharing api ("hey, it's there, why not use it?"). And the
timeframe for deprecating the kernel abi is 5-10 years and yes I've
tried to dodge that and got shot at. Imo a better approach is to spec
(_after_ the kernel buffer sharing works) a low-level userspace api
that drivers need to implement (like the EGL Mesa extensions used to
make Wayland work on gem drivers).
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
