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

[Emil Velikov]

On 4 October 2016 at 15:57, Rob Herring <robh at kernel.org> wrote:
> 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.
>
Hi Rob,

Yes, I've pondered on the same thing a while back - (ab)using dumb
buffer might not be the best of ideas. IMHO for the time being, until
the new allocator gets into shape, I think its the smaller evil that
we can opt for. Merging the latest code, even if it only works on
X/Wayland/other is better than none, right ;-)

Emil