ARMSOC X11 plugin issues

[David Garbett]

The main difference between modesetting and armsoc is that armsoc
supports DRI2, and modesetting doesn't. This is what allows the GLES
driver to render to X buffers.

DRI2 enables any application to pass any X pixmap into the GLES/EGL
driver, so all buffers need to be allocated from shareable memory.
That's not the case with modesetting - other than the main framebuffer,
other allocations (for pixmaps and windows) can just be local to the X
server, so don't allocate from the DRM driver.

I've not looked at your DRM driver proposal so I can't really say why it
can't cope with the additional allocations. Though I do notice in your
armsoc patch that you don't handle scanout buffers any differently. In
many systems scanout buffers are a more scarce resource (perhaps they
need to be contiguous, or meet certain alignment restrictions).

David

> -----Original Message-----
> From: Maxime Ripard [mailto:maxime.ripard at free-electrons.com]
> Sent: 31 March 2016 09:55
> To: David Garbett; Marico Xu
> Cc: xorg-devel at lists.freedesktop.org; Boris Brezillon; Alexander Kaplan;
> Hans de Goede
> Subject: Re: ARMSOC X11 plugin issues
>
> On Wed, Mar 23, 2016 at 10:17:05PM +0100, Maxime Ripard wrote:
> > Hi David, Marico,
> >
> > I've been developping a DRM/KMS driver for the Allwinner SoCs[1],
> with
> > an additional patch to allocate GPU buffers [2]. Since those SoCs also
> > use a Mali GPU, using the armsoc X11 plugin seemed like a logical
> choice.
> >
> > I added support for the driver based on the 1.4 plugin [3], and
> > started using it, which turned out pretty well, we get something
> > displayed, GLES works, good.
> >
> > However, after testing it for a while, the first thing we noticed was
> > that some (large) buffer allocations would start to fail. Indeed, the
> > plugin seems to do a lot of rather small (and for most temporary ?)
> > buffer allocations, which eventually depletes the reserved memory
> > pool. The allocation then fails, and the application crashes.
> >
> > Then, we noticed (using xfce4, on debian jessie) that the systray
> > icons were not displayed for some reason. There's also some game
> > (alex4 [4]), that starts, runs, but the window content remains black
> > (but it remains interactive, audio plays and if we take a screenshot,
> > the content is on the image, but the screen remains black).
> >
> > The weird thing about it is that when using the X generic modesetting
> > plugin, everything starts to work. It seems to be allocating only one
> > buffer per plane, so we never have the memory allocation failures.
> > Which raises my first question: why is the armsoc plugin behaving
> > differently there?
> >
> > Then the graphics issues we were seeing are not there anymore, which
> > seems to indicate that it's related to the plugin. I'm a bit oblivious
> > to how X works exactly, and how applications interacts with it, but on
> > the ioctl side, nothing really stands out. Let me know if you need any
> > more tests or logs or anything.
>
> Anyone ?
>
> Thanks,
> Maxime
>
>
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-
> electrons.com
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.