Re: ARMSOC X11 plugin issues

[Maxime Ripard]

Hi,

On Sun, Jun 26, 2016 at 12:36:31AM +0300, Siarhei Siamashka wrote:
> > On 4 April 2016 at 11:45, Siarhei Siamashka  
> > wrote:
> > > 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?  
> > 
> > Getting fairly off-topic now, but the Midgard (6xx/7xx/8xx) drivers
> > are now redistributable.
> 
> Hi Daniel,
> 
> I'm not sure if this is really offtopic, because it is still related to
> the interoperability with the X server after all.
> 
> Thanks for your comment. Sorry for a late reply, but I have just noticed
> that the ARM Mali Utgard GPU User Space Drivers page now has the
> r6p0-01rel0 release with an updated EULA, which is more permissive
> compared to the previous r5p0-01rel0 release:
> 
> 
> http://malideveloper.arm.com/resources/drivers/arm-mali-utgard-gpu-user-space-drivers/
> 
> The page states that "A new and more permissive version was introduced
> in January 2016 and all Midgard user-space drivers starting with r6p0
> are now distributed under the new terms. The main changes are to allow
> redistribution of the binaries under the same EULA, commercial use and
> benchmarking. Please read the END_USER_LICENCE_AGREEMENT.txt document
> included in the packages for the exact licencing terms."
> 
> There is obviously a minor mistake in this text, because it mentions
> "Midgard" (most likely a copy-paste issue).
> 
> Anyway, it is good that the Utgard (Mali-400/450) binaries now got a
> usable license after all these years. And the weird benchmark results
> confidentiality clause has been also updated. Thanks to whoever finally
> made this happen!

Awesome news!

> Still I wonder who is going to also provide binaries for the 32-bit
> mode and for Mali-400 hardware (unless the userland binaries for
> Mali-450 are fully backwards compatible). Also the X11 binaries are
> still missing from the downloads page. Can ARM people comment on this?

I've been using at least the Mali-450 kernel driver here without any
issue, I don't know about the library though.

> Maxime, if you happen to have 32-bit redistributable userland
> Mali-400 binaries, could you please share them with the others?
> Maybe ARM people could even put them on their download page?

Unfortunately, I'm not clear on the license of the blobs I got. It's
something I need to take care of, thanks for reminding me.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Maxime Ripard]

Hi,

So I've finally solved these 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.

Applying this patch [1] from Daniel's repo works around that, and we
don't notice it anymore.

Any reason it's never been merged?

> Then, we noticed (using xfce4, on debian jessie) that the systray
> icons were not displayed for some reason.

This patch [2] from Rockchip's repo fixes that issue, somehow.

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

And this is one is interesting.

The difference was that, on that game window (and some other part of
the screen too), the alpha component was set to !0xff with
armsoc. Forcing an XRGB format (and effectively dropping the alpha
component) when ARGB was requested made everything work.

modesetting, on the the other end, doesn't seem to use alpha at all,
which explains the difference of behaviour.

On my hardware, there's not really a primary plane, there's just 4
identical planes, and one of them had to be used as primary
plane. This is nice since you can use any plane for any purpose, but
it doesn't seem to like having an alpha on the lowest plane (which is
the primary plane in our case).

Setting a background color in the display engine actually displays
that color where alpha is set, so it really seems like the display
engine tries to use alpha, and since there's only black below it,
displays black, instead of ignoring it entirely.

Setting the plane global alpha to 0xff also solves the issue.

However, I don't think it's such a good idea to use alpha on the
primary plane at all, what's your take on this?

Thanks!
Maxime

1: 
https://github.com/mripard/xf86-video-armsoc/commit/0bf713bdbbd514ea838704282a648f4d044c01e0
2: 
https://github.com/mripard/xf86-video-armsoc/commit/d8fc72b8f5b70eafd1d84e535d0be08087b7ad3a

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Siarhei Siamashka]

On Mon, 4 Apr 2016 13:24:21 +0100
Daniel Stone  wrote:

> Hi,
> 
> On 4 April 2016 at 11:45, Siarhei Siamashka  
> wrote:
> > 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?  
> 
> Getting fairly off-topic now, but the Midgard (6xx/7xx/8xx) drivers
> are now redistributable.

Hi Daniel,

I'm not sure if this is really offtopic, because it is still related to
the interoperability with the X server after all.

Thanks for your comment. Sorry for a late reply, but I have just noticed
that the ARM Mali Utgard GPU User Space Drivers page now has the
r6p0-01rel0 release with an updated EULA, which is more permissive
compared to the previous r5p0-01rel0 release:


http://malideveloper.arm.com/resources/drivers/arm-mali-utgard-gpu-user-space-drivers/

The page states that "A new and more permissive version was introduced
in January 2016 and all Midgard user-space drivers starting with r6p0
are now distributed under the new terms. The main changes are to allow
redistribution of the binaries under the same EULA, commercial use and
benchmarking. Please read the END_USER_LICENCE_AGREEMENT.txt document
included in the packages for the exact licencing terms."

There is obviously a minor mistake in this text, because it mentions
"Midgard" (most likely a copy-paste issue).

Anyway, it is good that the Utgard (Mali-400/450) binaries now got a
usable license after all these years. And the weird benchmark results
confidentiality clause has been also updated. Thanks to whoever finally
made this happen!

Still I wonder who is going to also provide binaries for the 32-bit
mode and for Mali-400 hardware (unless the userland binaries for
Mali-450 are fully backwards compatible). Also the X11 binaries are
still missing from the downloads page. Can ARM people comment on this?

Maxime, if you happen to have 32-bit redistributable userland
Mali-400 binaries, could you please share them with the others?
Maybe ARM people could even put them on their download page?

-- 
Best regards,
Siarhei Siamashka
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Siarhei Siamashka]

On Tue, 5 Apr 2016 11:12:00 -0700
Maxime Ripard  wrote:

> On Mon, Apr 04, 2016 at 02:46:19PM +0900, Michel Dänzer wrote:
> > On 01.04.2016 15:57, David Garbett wrote:  
> > > The main difference between modesetting and armsoc is that armsoc
> > > supports DRI2, and modesetting doesn't.  
> > 
> > The modesetting driver itself supports DRI2 as well. If it's not working
> > on this platform, it's probably because
> > hw/xfree86/dri2/dri2.c:dri2_probe_driver_name() doesn't know yet which
> > DRI client driver name to use for it.  
> 
> My understanding was that the modesetting driver was supporting DRI2
> through mesa, which we aren't using unfortunately (but instead the
> proprietary ARM OpenGL ES implementation)

Yes, the DRI2 spec does not define the exact interpretation of the
DRI2BUFFER data fields and leaves a lot up to the implementations.

This works fine as long as the DDX (or "plugin" as you call it)
and the client side GL library are interpreting DRI2BUFFER in
the same way and understand each other. But different DRI2
implementations are generally incompatible with each other.

-- 
Best regards,
Siarhei Siamashka
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Maxime Ripard]

On Mon, Apr 04, 2016 at 02:46:19PM +0900, Michel Dänzer wrote:
> On 01.04.2016 15:57, David Garbett wrote:
> > The main difference between modesetting and armsoc is that armsoc
> > supports DRI2, and modesetting doesn't.
> 
> The modesetting driver itself supports DRI2 as well. If it's not working
> on this platform, it's probably because
> hw/xfree86/dri2/dri2.c:dri2_probe_driver_name() doesn't know yet which
> DRI client driver name to use for it.

My understanding was that the modesetting driver was supporting DRI2
through mesa, which we aren't using unfortunately (but instead the
proprietary ARM OpenGL ES implementation)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Maxime Ripard]

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  wrote:
> 
> > Hello David,
> > 
> > Thanks for your answer.
> > 
> > On Fri, Apr 01, 2016 at 06:57:07AM +, 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:
> 
> 
> 

Re: ARMSOC X11 plugin issues

[Daniel Stone]

Hi,

On 4 April 2016 at 11:45, Siarhei Siamashka  wrote:
> 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?

Getting fairly off-topic now, but the Midgard (6xx/7xx/8xx) drivers
are now redistributable.

Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Daniel Drake]

On Mon, Apr 4, 2016 at 4:45 AM, Siarhei Siamashka
 wrote:
>> 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.

Yes, I have another approach:
https://github.com/endlessm/xf86-video-armsoc/commit/d7855656a82513d2e81d05bb690ecddabb2db1ca
(and then several follow up commits for corner cases)

Unfortunately it's all part of a significant fork based on an old
version of armsoc. Newer versions have some more fundamental problems.
I did send some patches and tried to start corresponding discussions
almost 2 years ago, but those emails are still unanswered.

Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Siarhei Siamashka]

Hello Maxime,

On Sat, 2 Apr 2016 15:58:37 +0200
Maxime Ripard  wrote:

> Hello David,
> 
> Thanks for your answer.
> 
> On Fri, Apr 01, 2016 at 06:57:07AM +, 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
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Michel Dänzer]

On 01.04.2016 15:57, David Garbett wrote:
> The main difference between modesetting and armsoc is that armsoc
> supports DRI2, and modesetting doesn't.

The modesetting driver itself supports DRI2 as well. If it's not working
on this platform, it's probably because
hw/xfree86/dri2/dri2.c:dri2_probe_driver_name() doesn't know yet which
DRI client driver name to use for it.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Maxime Ripard]

On Thu, Mar 31, 2016 at 04:37:15PM -0700, Jasper St. Pierre wrote:
> ARMSOC isn't a well-written driver, basically. Is there a reason
> you're not using modesetting if it works better for you?

It doesn't do DRI, as far as I know.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Maxime Ripard]

Hello David,

Thanks for your answer.

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


signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

RE: 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.rip...@free-electrons.com]
> Sent: 31 March 2016 09:55
> To: David Garbett; Marico Xu
> Cc: xorg-de...@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.

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Jasper St. Pierre]

ARMSOC isn't a well-written driver, basically. Is there a reason
you're not using modesetting if it works better for you?

On Thu, Mar 31, 2016 at 1:54 AM, Maxime Ripard
 wrote:
> 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
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: ARMSOC X11 plugin issues

[Maxime Ripard]

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


signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

ARMSOC X11 plugin issues

[Maxime Ripard]

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.

Thanks!
Maxime

1: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/417295.html
2: 
https://github.com/NextThingCo/CHIP-linux/commit/e37722eb32713611ff6800283a72c6d4784edf6a
3: 
https://github.com/mripard/xf86-video-armsoc/commit/37d1ed1d1e53e3b9e0c064913b7e3c40a4b071a9
4: https://sourceforge.net/p/allegator/alex4/ci/master/tree/

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel