[Mesa-dev] Mesa 12.1.0 release plan (Was Re: Next Mesa release, anyone?)

[Rob Herring]

On Tue, Oct 4, 2016 at 5:26 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 4 October 2016 at 02:05, Rob Clark <robdclark at gmail.com> wrote:
>> On Thu, Sep 29, 2016 at 10:56 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 28 September 2016 at 19:53, Marek Olšák <maraeo at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> It's been almost 4 months since the 12.0 branch was created, and soon
>>>> it will have been 3 months since Mesa 12.0 was released.
>>>>
>>>> Is there any reason we haven't created the stable branch yet?
>>>>
>>>> Ideally, we would time the release so that it's 1-2 months before fall
>>>> distribution releases.
>>>>
>>>
>>> Thanks Marek !
>>>
>>> In all honesty I was secretly hoping that we'll get Dave/Bas RADV for
>>> 12.1. With the topic of which would be 'the default' Vulkan driver for
>>> ATI/AMD hardware to be considered at a later stage.
>>
>> btw, I pushed libdrm release that I think etnaviv was waiting for..
>> not sure what else is needed before merging etnaviv gallium driver,
>> but if at all possible, it would be nice to land that before the
>> branch point too.
>>
> Thanks for the libdrm bits Rob. IIRC on the mesa side Christian
> reworked the render-only parts noticeably, yet as long as there isn't
> a crazy amount of changes outside of the etnaviv driver I think we're
> fine with getting it in.

I've been doing some work to get etnaviv working on Android. The
render-only approach is a bit broken IMO. It may work okay for X11
which expects to work on a card node, but it doesn't for Android which
already uses the render node for GL and gralloc and the KMS node for
HWC. Having the render-only driver also open the KMS node gets us into
all of the permissions issues. It seems to me we want gralloc to be
able to open both nodes (that still has some ioctl permission issues)
and allocate scanout buffers from the control node (thru GBM). Then
the etnaviv driver has to know to blit to the linear buffer when it
has an imported scanout buffer. IOW, I don't think the render-only
driver should internally allocate dumb buffers, but keep that
allocation external and the etnaviv driver needs to be able to deal
with external buffers. Maybe we just wait for the grand central
allocator to solve all this.

Rob