[Mesa-dev] GBM and the Device Memory Allocator Proposals

[Jason Ekstrand]

On Wed, Nov 29, 2017 at 4:19 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:

> On 25.11.2017 18:46, Jason Ekstrand wrote:
>
>> I'm not quite some sure what I think about this.  I think I would like to
>> see $new_thing at least replace the guts of GBM. Whether GBM becomes a
>> wrapper around $new_thing or $new_thing implements the GBM API, I'm not
>> sure.  What I don't think I want is to see GBM development continuing on
>> it's own so we have two competing solutions.
>>
>> I *think* I like the idea of having $new_thing implement GBM as a
>> deprecated legacy API.  Whether that means we start by pulling GBM out into
>> it's own project or we start over, I don't know.  My feeling is that the
>> current dri_interface is *not* what we want which is why starting with GBM
>> makes me nervous.
>>
>
> Why not?
>
> The most basic part of the dri_interface is just a
> __driDriverGetExtensions_xxx function that returns an array of pointers to
> extension structures derived from __DRIextension.
>
> That is *perfectly fine*.
>

Fair enough.  I'm perfectly happy to re-use a well-tested API extension
mechanism.


> I completely agree if you limit your statement to saying that the current
> *set of extensions* that are exposed by this interface are full of X-isms,
> and it's a good idea to do a thorough house-cleaning in there. This can go
> all the way up to eventually phasing out the DRI_Core "extension" as far as
> I'm concerned.
>

That's more of what I was getting at.  In particular, I don't want the
design of $new_thing to be constrained by trying to cram into the current
DRI extensions nor do I want it to attempt to have exactly the same set of
functionality as the current DRI extensions (or GBM) support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171129/1e0d8087/attachment.html>