[Freedreno] Freedreno: EXA acceleration?

[Rob Clark]

On Sat, Jan 25, 2014 at 4:23 PM, Pallai Roland <pallair at magex.hu> wrote:
> 2014/1/24 Rob Clark <robdclark at gmail.com>:
>> On Thu, Jan 23, 2014 at 9:05 PM, Pallai Roland <pallair at magex.hu> wrote:
>>
>> Currently all EXA falls back to software.  But it is enough for dri2
>> to work (so 3d stuff, including gl compositing window managers will be
>> accelerated.
>> [...]
>> Last time I had XA working, it didn't seem like a huge performance
>> win.  Although I suppose it should benefit from at least some of the
>> improvements in freedreno gallium since then.  But a tiler gpu in
>> particular is not really terribly ideal for lots of small EXA
>> composite ops (font rendering, etc).  At least we can bypass tiling
>> for solid fills and blits (so it will at least be good for
>> presentation blits for windowed 3d apps).
>> [...]
>>> My hobby project is a portable thin client mainly for ssh/spice
>>> sessions with fast and fluent window management on multiple
>>> workspaces. Seems like EXA is an important thing for that, now
>>> scrolling and anti-aliased font rendering in the terminal is pretty
>>> slow.
>> Probably adding support for cached GEM buffers might help out some
>> cases.  For small composite ops (like font rendering), I don't think
>> the GPU will outperform the CPU.
>
> My problem with slow 2D rendering came from text rendering over
> XRender. I did some measuring with Qperf and found Qt text rendering
> on client side 10 times faster than XRender (measured with
> QT_GRAPHICSSYSTEM={native,raster}). I disabled XRender in Firefox,
> changed Gnome-terminal to Konsole and the experience is much better
> now.

yeah, client side rendering for stuff like font rendering is probably
the best option

> I agree, seems like EXA in a modern desktop environment is not so
> critical. Qt does not use XRender/EXA from 4.8 by default, Qt5 even
> dropped the support. I'm running Kwin (KDE) in OpenGL 1.2
> compatibility mode, my desktop works like a charm!
> It's interesting that moving of the windows much faster in Kwin than
> in Gnome3 - maybe the javascript is slow there..?

Could be.. I don't really expect the javascript to make much
difference once things are up and running, but probably the first time
you run gnome session, that might be triggering some sort of indexing
to go on.  Fire up top/htop and see if something like that is what is
slowing things down.

I'm not sure, but I wonder if the lack of battery backed RTC might be
making things worse by confusing things into thinking things need
re-indexing.  (My board usually manages to get correct time from an
ntp server before gdm starts, but it is something to watch out for.)

> I've one more question about your HDMI resolutions for you since I've
> seen your 1024x768 support patch;
> I'd like to drive my monitor in native resolution 1280x1024p60
> (108Mhz) but the documentation isn't too chatty on programming of HDMI
> PLL registers, do you have some extra info?
> I've opened a ticket at inforcecomputing, but no reply, yet.
>

I got the PLL settings for 1024x768 from one of qcom's display driver
guys that I met at LPC.  The bitfields for the PLL registers are
unknown (at least to me, since I can't download the TRM due to EULA
which would prevent me from working on the gallium stuff.

BR,
-R

>
> Thanks for your help!