Unix Device Memory Allocation project

Rob Clark robdclark at gmail.com
Wed Oct 5 12:19:10 UTC 2016


This would be a purely userspace interface (in that user just
interacts w/ a userspace shared lib, the driver specific backend may
do it's own ioctls to query whatever is needed from the hw)..

So might be something like, for each device in the sharing use-case, call:

  allocator_dev_t allocator_load(int fd);

where loader figures out what backend to dlopen() based on the fd.
There could probably be, for example, a generic liballocator-v4l.so
that works for all v4l devices.  And for gl drivers, this would be a
gbm sorta thing.  For some APIs which don't expose a device fd, we
might need some sort of extension within that API.  (For example
OpenMAX..  but maybe if we wait long enough that problem just goes
away.)

a bit handwavey at the moment..

BR,
-R

On Wed, Oct 5, 2016 at 4:42 AM, Benjamin Gaignard
<benjamin.gaignard at linaro.org> wrote:
> Hi,
>
> Do you already have in mind a list of targeted driver/backend/plugin ?
> How do you expect to enumerate devices capabilities ? by adding a new
> generic ioctl or a configuration file in userland ?
>
> Maybe it is to early for those questions but anyway I'm interested by
> this memory allocation thread.
>
> Regards,
> Benjamin
>
> 2016-10-05 1:47 GMT+02:00 James Jones <jajones at nvidia.com>:
>> Hello everyone,
>>
>> As many are aware, we took up the issue of surface/memory allocation at XDC
>> this year.  The outcome of that discussion was the beginnings of a design
>> proposal for a library that would server as a cross-device, cross-process
>> surface allocator.  In the past week I've started to condense some of my
>> notes from that discussion down to code & a design document.  I've posted
>> the first pieces to a github repository here:
>>
>>   https://github.com/cubanismo/allocator
>>
>> This isn't anything close to usable code yet.  Just headers and docs, and
>> incomplete ones at that.  However, feel free to check it out if you're
>> interested in discussing the design.
>>
>> Thanks,
>> -James
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Benjamin Gaignard
>
> Graphic Study Group
>
> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


More information about the dri-devel mailing list