[Xf86-video-armsoc] ARMSOC X11 plugin issues

[Siarhei Siamashka]

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

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.

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.

> > > > 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/

This really must be something new, because I don't remember anything
like this when skimming through the EULA back in 2013. Making the EULA
even more restrictive seems to contradict with the promise of Jem
Davies to provide legally redistributable mali binary drivers that
we had in 2014:

    http://anandtech.com/comments/8226/ask-the-experts-arm-fellow-jem-davies-answers-your-gpu-questions/409101

Can anyone from ARM provide an update on this?

-- 
Best regards,
Siarhei Siamashka