About xf86-video-armsoc integration

[Michal Suchanek]

On 22 May 2015 at 10:15, Xinliang Liu <xinliang.liu at linaro.org> wrote:
>
>
> On 13 May 2015 at 18:16, Michal Suchanek <hramrach at gmail.com> wrote:
> Hi Michal,
> Thank you very much for your reply. It does make much sense:-)
> I fix the "DMA: Out of SW-IOMMU space"  issue by adding a "dma-coherent;"
> property to both display drm and gpu driver dts node.
>
> There are two dma_map_ops implementations of swiotlb for arm64, that are:
> noncoherent_swiotlb_dma_ops and coherent_swiotlb_dma_ops.
> By default,device driver use the noncoherent one. In our case, the buffers,
> which allocated in display drm driver, are coherent.
> So we need to add a "dma-coherent;" property to both display drm and gpu
> driver dts node to make sure our drm and gpu driver use the coherent one.
> Now i can run OpenGL ES application now, such as es2gears.
>
>> On 12 May 2015 at 15:03, Guillaume Tucker <guillaume.tucker at arm.com>
>> wrote:
>> >> Then i run  startx, i can see the desktop on the monitor.
>> >> But i found that the X process doesn't load any EGL and GLES libs by
>> >> seeing the info of /proc/X process ID/task/*/smaps file.
>> >
>> > Most X11 desktop environments use OpenGL, not OpenGL ES.  Then like most
>> > embedded GPUs, Mali-450 only supports OpenGL ES so the X11 desktop is
>> > not hardware-accelerated.
>>
>> This is somewhat unrelated to the issue of the armsoc driver being a
>> bug pile that makes your system crash.
>>
>> However, both GNOME and KDE can use OpenGL ES for desktop acceleration.
>>
> Do you know if Debian desktop can use  OpenGL ES for acceleration? And how?

Kind of.

Last time I tried running gnome-shell it turned out there is some
helper which tries to initialize OpenGL and if it fails it tells gnome
to not use acceleration. If you symlink that helper to the true binary
gnome-shell happily runs on top of OpenGL ES and potentially exposes
numerous bugs in the Mali libraries.

ln -sf /bin/true /usr/lib/gnome-session/gnome-session-check-accelerated

For example, libMali initializes threads behind libX11's back so
whenever a thread-aware function in libX11 is called it crashes.

To counter this issue I moved gnome-shell to
/usr/local/bin/gnome-shell.distrib and replaced it with this script:

#!/bin/sh
gdb -ex 'break main' -ex  'r' -ex 'call XInitThreads()' -ex 'c' -ex
'bt full' -ex 'quit' --args /usr/local/bin/gnome-shell.distrib "$@"

Which initializes threads in LibX11 before calling into libMali and
conveniently also prints out a stack trace if your gnome shell happens
to crash. There is a possibility to patch the libMali binary to do the
same and some later revisions of the library may even initialize
threads properly.

Last time I looked at KDE there was a special version of KWin for
OpenGL ES as a separate kwin_gles package in Ubuntu but none in
Debian.

>> There is a shim library to translate OpenGL calls to OpenGL ES calls
>> so you can run desktop OpenGL applications that use OpenGL features
>> for which the translation was already added.
>> I don't remember the exact library name, unfortunately.
>
> I have searched for it on the internet, but i can find it. If you remember
> the lib name please tell me.

At least one such library is called glshim.

Thanks

Michal