[Xf86-video-armsoc] ARMSOC X11 plugin issues

[Maxime Ripard]

Hello David,

Thanks for your answer.

On Fri, Apr 01, 2016 at 06:57:07AM +0000, David Garbett wrote:
> 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.

Yes, that's what I figured.

> 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).

We do agree on that. However, it looks like the arm soc driver does
way much more allocations, and usually smaller ones, than modesetting
that basically just allocates a buffer for its framebuffers and that's
it.

If I was to guess, I'd say that it allocates buffers for applications
(and possibly part of the applications window), that eventually
depletes the CMA pool, even though the GPU is not used.

I'd expect the DRI buffers to be allocated from this pool, because of
the reasons you pointed out, but I would also expect that the
applications do not hit that pool, precisely because it's a scarce
resource.

I'm possibly missing something though, or have broken expectations :)

In our case, we don't really have any restrictions on the memory
resource locations, and I'm not aware of any particular weird
alignment constraints either.

> > > 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).

That's what concerns me the most though. We can always work around the
memory allocations by playing cat and mouse and allocating a bigger
pool (even though I'd really like to avoid that).

However, those glitches are kind of weird, and not really convenient :/

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.x.org/archives/xf86-video-armsoc/attachments/20160402/1617d5ff/attachment.sig>