[Mesa-dev] GBM and the Device Memory Allocator Proposals
Jason Ekstrand
jason at jlekstrand.net
Fri Nov 24 16:50:11 UTC 2017
On November 24, 2017 09:45:07 Jason Ekstrand <jason at jlekstrand.net> wrote:
> On November 23, 2017 09:00:05 Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> Hi James,
>>
>> On 21 November 2017 at 01:11, James Jones <jajones at nvidia.com> wrote:
>>
>>> -I have also heard some general comments that regardless of the relationship
>>> between GBM and the new allocator mechanisms, it might be time to move GBM
>>> out of Mesa so it can be developed as a stand-alone project. I'd be
>>> interested what others think about that, as it would be something worth
>>> coordinating with any other new development based on or inside of GBM.
>>>
>> Having a GBM frontend is one thing I've been pondering as well.
>>
>> Regardless of exact solution wrt the new allocator, having a clear
>> frontend/backend separation for GBM will be beneficial.
>> I'll be giving it a stab these days.
>
> I'm not sure what you mean by that. It currently has something that looks
> like separation but it's a joke. Unless we have a real reason to have
> anything other than a dri_interface back-end, I'd rather we just stop
> pretending and drop the extra layer of function pointer indirection entirely.
Gah! I didn't read Rob's email before writing this. It looks like there
is a use-case for this. I'm still a bit skeptical about whether or not we
really want to extend what we have our if it would be better to start over
and just require that the new thing also support the current GBM ABI.
> --Jason
>
>> Disclaimer: Mostly thinking out loud, so please take the following
>> with grain of salt.
>>
>> On the details wrt the new allocator project, I think that having a
>> new lean library would be a good idea.
>> One could borrow ideas from GBM, but by default no connection between
>> the two should be required.
>>
>> That might lead to having a the initial hurdle of porting a bit
>> harder, but it will allow for more efficient driver implementation.
>>
>> HTH
>> Emil
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
More information about the mesa-dev
mailing list