ARMSOC X11 plugin issues

Tue Apr 5 22:26:19 UTC 2016

Hi Siarhei,

On Mon, Apr 04, 2016 at 01:45:46PM +0300, Siarhei Siamashka wrote:
> Hello Maxime,
> 
> On Sat, 2 Apr 2016 15:58:37 +0200
> Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
> 
> > 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.
> 
> Yes, this problem can be solved by using malloc for all pixmaps, and
> only migrating them to CMA or any other special allocation method
> when needed. We encountered this back in 2013, when xf86-video-mali
> had exactly the same design issues as you see now with
> xf86-video-armsoc:
> 
>     http://ssvb.github.io/2013/02/01/new-xf86-video-sunxifb-ddx-driver.html

I know have a couple of new tabs to read to understand X a bit more,
thanks :)

> As far as I know, Daniel Drake had some fixes for xf86-video-armsoc,
> but I have no idea which of the armsoc forks is the most up to date
> right now.
> 
> There are also a few tricks to ensure that the 2D performance
> is not regressed in Xorg by integrating the mali drivers, and
> also to get zero-copy tear-free OpenGL ES rendering in windows.
> This all is now available in the xf86-video-fbturbo DDX (renamed
> from xf86-video-sunxifb) if anyone is interested.

While you're talking about it, how much of fbturbo actually depends on
fbdev? How difficult would that be to migrate the work you did to KMS ?

I think you're using UMP too, right?

> And I'm happy to know that you are working on the kernel side and
> doing the conversion of the Allwinner's custom fbdev based kernel
> interface into a more standard DRM/KMS interface. This had to be
> done by somebody and it is better late than never.

Yeah, it starts to be in a pretty good shape. The support is still
pretty limited (only a single display pipeline supported, only the RGB
and Composite output), but I'm pretty confident that it's going to be
relatively easy to extend with more features once merged.

> > > > > 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 :/
> 
> Well, the mali drivers EULA kind of warns that a problem-free experience
> is not to be expected. And they deliver what is promised :-)
> 
> The EULA now has an extra clause in the "RESTRICTIONS ON USE OF THE
> SOFTWARE" paragraph, which basically says that any benchmark results
> or reports about quality issues are not allowed to be disclosed without
> an explicit permission from ARM:
> 
>     http://malideveloper.arm.com/resources/drivers/arm-mali-utgard-gpu-user-space-drivers/

I don't think those issues are actually related to the GPU driver. It
happens whether the mali module is loaded or not, so it really seems
to me that the issue is in the armsoc DDX itself.

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/xorg-devel/attachments/20160405/71bdfc1a/attachment.sig>