On 4 October 2016 at 15:57, Rob Herring <r...@kernel.org> wrote: > On Tue, Oct 4, 2016 at 5:26 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> On 4 October 2016 at 02:05, Rob Clark <robdcl...@gmail.com> wrote: >>> On Thu, Sep 29, 2016 at 10:56 AM, Emil Velikov <emil.l.veli...@gmail.com> >>> wrote: >>>> On 28 September 2016 at 19:53, Marek Olšák <mar...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
