User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 10:44 am

Nah you should be good with the stock one. Try opening IDLE and then loading a text file in it. Watch the display paint from top to bottom.
From memory *so I could be wrong!*, for each line of text it,
- allocates a 1x1 pixmap as well as a pixmap that is as wide as the window but high enough for one line of text
- uploads a single colour value into this 1x1 pixmap
- clears the larger buffer by copying the 1x1 pixmap all over it (a solid fill would be nicer please)
- blends a few characters of text into the larger buffer at a time (again overkill...as we could do the clear and composite in one step with a different composite operation)
- I'm sure it then does a sync every few characters
- I'm sure it requests a full download of the larger buffer once the line is rendered
- it then blends that one line of rendered text into the full window buffer (overkill, a copy would suffice...or simply render into the correct buffer to begin with?)
- it then deallocates the 1x1 and one text line buffers
- repeat for the next line of text

charliedurrant
Posts: 35
Joined: Sun Mar 18, 2012 12:06 am

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 1:00 pm

Um....I'll start on it Monday & Tuesday evening. I have a lot to learn as I'm from a windows background so the debugging setup etc will take time.

That drawing method is slow. It's a good example of how much you can get away with nowadays due to fast processors.

charliedurrant
Posts: 35
Joined: Sun Mar 18, 2012 12:06 am

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 1:32 pm

Doh! IDLE's written in python! Not much debugging setup to do then - sorry :!:

charliedurrant
Posts: 35
Joined: Sun Mar 18, 2012 12:06 am

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 6:20 pm

Just s quick update re I.D.L.E drawing being slow:

All the 'line of text' I.D.L.E drawing code is in tkTextDisp.c noteably the function:

DisplayDLine(textPtr, dlPtr, prevPtr, pixmap)

At first glance it looks fine at the tk Level, each line is drawn using the above function and I can't see any 1x1 bitmaps being used. I'm either missing something or it's lower down in the functions - more investigation required.

Charlie

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 6:26 pm

The 1x1 looks like a roundabout way of doing a solid colour fill, if that helps at all.
EDIT: and perhaps the solid colour value is entered in as an immediate, eg 0xffffffff.

charliedurrant
Posts: 35
Joined: Sun Mar 18, 2012 12:06 am

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 7:10 pm

Seems to route right down to the X call

XFillRectangles - of which I do not yet have the source.

I'll have to get it all debugging as I'm not old school enough to trace all this via a text editor. Clocking off now.

Charlie

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 7:35 pm

Good work! That's ace, thanks for the help. Keep going :) Even eyeballing the source for DisplayDLine sort of correlates with what I'm seeing. Going by the comments alone,
/*
* First, clear the area of the line to the background color for the
* text widget.
*/
/*
* Next, draw background information for the whole line.
*/
they then loop through each character(?) and call a function pointer to do some drawing. Then,
/*
* Copy the pixmap onto the screen. <snip>
*/
This sounds very much like what I see. The memory allocation and frees are a particular PITA as they require lots of management.
Perhaps with a bit of context the code which calls this could do a better job in CPU-constrained situations.
---------------
Anyway I've now written a stack of CPU fallback code for some of these oddball cases to improve performance.

Another culprit I've been debugging is Netsurf. There's something very wrong with it's handling of engadget.com's <div class="col2_most_commented module"> block. I'm pretty sure it's this block, as when it appears on the screen I get a huge number of 1x1 pixmaps being allocated/deallocated and composited into the window. Anyone savvy with CSS/HTML/whatever who can look at this to see what it does? The display literally takes seconds to paint once this block appears.

ScottyPcGuy_03
Posts: 8
Joined: Thu Nov 01, 2012 8:34 pm
Location: VA
Contact: Website

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 7:45 pm

I'm pretty CSS+HTML savvy, so I'll take a look at it this evening. Do I need your driver to see the problem or will it show up with cpu rendering?
Scott

What do you mean I can't eat it? It's a pie, right?

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 7:57 pm

Unsure, it won't be as pronounced with the stock driver as this EXA stuff I'm using has more overhead. I think it should still be quite noticeable though.
If you look on the page for the MOST COMMENTED box with the five coloured bars underneath that's the bit I'm talking about.
If I make the window just small enough to hide that I can scroll past no problem!

The ON TWITTER section seems the have the same bar graph code and also paints hideously slow, one pixel at a time.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 8:15 pm

Looking at the CSS (god bless chrome's developer tools), my guess would be the rendering for non-transparent background_color attributes, possibly when combined with overlaid transparent objects.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 10:24 pm

Ah...it doesn't happen in Netsurf 2.8, but it does in 2.9! And the page rendering looks the same in that region in both.

ScottyPcGuy_03
Posts: 8
Joined: Thu Nov 01, 2012 8:34 pm
Location: VA
Contact: Website

Re: Simon's accelerated X development thread

Sun Nov 18, 2012 10:29 pm

teh_orph wrote:Ah...it doesn't happen in Netsurf 2.8, but it does in 2.9! And the page rendering looks the same in that region in both.
Interesting! So somebody decided to change the render algo? I wonder why.

EDIT: Found something in the 2.9 Changelog

Framebuffer-specific
--------------------

* Reduced excessive logging.
* Implemented RAM surfaces, instead of direct blitting.
* Fixed VNC surface.
* Enabled thumbnailing in local history view.

Also included are many smaller bug fixes, improvements and
documentation enhancements.
Scott

What do you mean I can't eat it? It's a pie, right?

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Mon Nov 19, 2012 10:11 am

Having had a look through Netsurf's wiki I have a feeling that 'framebuffer' is when it is running without X? Just a guess. Either way I will submit this as a bug to them if I can find some time.

Anyway I'm thinking now that I might release the current driver publicly for those who care to test, as a way to get more bugs out before making bigger changes that will win performance.
The only real impediment is that it needs a kernel module, and I'm going to have to do some investigation to see if users can compile this with just the kernel headers and modules.symvers, rather than the full kernel source. Some PC distros allow you to do this I'm sure, but it needs to be tested with Raspbian of course.

Anyone tried this on the rpi before?

User avatar
peba
Posts: 56
Joined: Tue Jun 12, 2012 8:16 pm
Location: Austria Korneuburg
Contact: Website

Re: Simon's accelerated X development thread

Mon Nov 19, 2012 12:39 pm

Hi,
Would it be possible to have an application specific filter (or blacklist) for applications
which behaves badly with x acceleration ? So badly behaving applications like IDLE would
continue to render with CPU code and all other applications would use the GPU.
Regards,
Peter
teh_orph wrote:Well I could talk for ages about rendering extensions etc, but here's a short list of things off the top of my head:
- currently at the top of my hit list would be the IDLE text editor that lives on the desktop, written in Python. I haven't yet found where the rendering code lives so I can inspect it, but I know it uses Tcl/Tk (?) so the rendering problems could be due to some side-effect within those libraries. Gedit works much better by comparison.
- the Python game demos on the desktop do not use the XRender extension, so currently I offer no acceleration for them (to be fair they're not 'slow' though!)
- some window managers are much better than others. I would currently avoid anything with a 'compositing' mode. Window Maker is my #1 "can't recommend highly enough" for the rpi!
- the huge rpi logo on the LXDE desktop saps far more performance than you would imagine. I appreciate it's part of the branding but if you want a higher refresh rate when dragging a window over it then - with a non-compositing window manager - change to a solid colour
- but saying that, leave the anti-aliased fonts turned on :)

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Mon Nov 19, 2012 3:09 pm

Yeah I thought about that and think it could be a good idea for the few problem cases.
However I think X would need to support this itself at a low level, and I'm not familiar enough or where to put that. I doubt I could put that in my driver.

Anyway the IDLE thing is just a bit crap under both drivers :)

ScottyPcGuy_03
Posts: 8
Joined: Thu Nov 01, 2012 8:34 pm
Location: VA
Contact: Website

Re: Simon's accelerated X development thread

Mon Nov 19, 2012 3:41 pm

teh_orph wrote:Anyway the IDLE thing is just a bit crap under both drivers
IDLE doesn't seem to be that slow to me, though I can still see it draw (albeit rapidly) on loading a text file. On the other hand, I found Netsurf 2.9 is just as slow on my Pi as on yours when it hits that DIV, so the problem is inherently cpu-bound.
Scott

What do you mean I can't eat it? It's a pie, right?

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Simon's accelerated X development thread

Mon Nov 19, 2012 5:07 pm

If you're seeing text rendering draw, no matter how fast, there's a massive problem.

Hell, the last time I saw that behaviour was on the Atari ST, and even that required hard scrolling to trigger it. The pi is 'only' 50+ times faster than an ST, of course, but non-accelerated x didn't crawl to that extent even on my powerbook g3.

ScottyPcGuy_03
Posts: 8
Joined: Thu Nov 01, 2012 8:34 pm
Location: VA
Contact: Website

Re: Simon's accelerated X development thread

Mon Nov 19, 2012 5:16 pm

tufty wrote:If you're seeing text rendering draw, no matter how fast, there's a massive problem.

Hell, the last time I saw that behaviour was on the Atari ST, and even that required hard scrolling to trigger it. The pi is 'only' 50+ times faster than an ST, of course, but non-accelerated x didn't crawl to that extent even on my powerbook g3.
I probably should have been clearer: I can tell the text is rendered one line at a time, however, scrolling is still fairly smooth. I can't see words or letters appearing individually, that WOULD be dog-slow!
Scott

What do you mean I can't eat it? It's a pie, right?

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Mon Nov 19, 2012 5:36 pm

I'm quite keen on looking at an EXA driver for a big fat PC video card, to see what they do in cases like this. Here I'm barely leaving the CPU in order to do acceleration (and have the option to fall back and just do it on CPU fine) but wonder what happens when you must always offload your processing, else your renderer is not coherent etc. Going back across PCIe for a few pixels at a time must be bad...
Surely these driver writers have a system to deal with this sort of issue?

KenT
Posts: 758
Joined: Tue Jan 24, 2012 9:30 am
Location: Hertfordshire, UK
Contact: Website

Re: Simon's accelerated X development thread

Mon Nov 19, 2012 5:45 pm

[edit] Should have asked whether the great work that Simon has already done will automatically speed up Geany or whether special application level treatment will be required.

Can I be so bold as to head the long list of people wanting their favourite application to be speeded up.

I personally found Idle to be fast enough but have moved to Geany as many other will once their programs get larger or they move from Python. Geany is quite slow especially when editing text. You can see the delays when deleting characters. The Geany website says its written in C and C++ with the GTK+ toolkit.
Pi Presents - A toolkit to produce multi-media interactive display applications for museums, visitor centres, and more
Download from http://pipresents.wordpress.com

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Mon Nov 19, 2012 8:53 pm

I've just had a quick go with Geany for you and it is a bit sluggish. I haven't yet gone in to see the workload it's sending. However something which immediately rings alarm bells is that watching 'top' (across the network) whilst I'm just typing, it's spending a good 50% of the CPU in the program itself and 15% in Xorg. When scrolling, there's a high CPU load in X - like I'd expect. But typing taking half of a 700 MHz CPU...err?!

thradtke
Posts: 492
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL

Re: Simon's accelerated X development thread

Mon Nov 19, 2012 8:55 pm

KenT wrote:You can see the delays when deleting characters.
I would be very surprised if an accelerated server speeds this up. I guess handling vector fonts and reconsidering the layout or checking syntax is what slows things down.

Emacs is quite fast ;-P.
Rocket Scientist.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: Simon's accelerated X development thread

Tue Nov 20, 2012 12:22 am

Wowza, *their code looks like mine*. Seriously similar! Even the functions are named and structured the same way!
http://cgit.freedesktop.org/xorg/driver ... r600_exa.c
http://cgit.freedesktop.org/nouveau/xf8 ... nvc0_exa.c

I have one of the R600-esque cards lying around (HD3870) so I may have a debug just to see how they handle these oddball cases. Neither driver appears to have a low-latency fallback in the case where the user application sends silly data to the driver. I'm actually amazed. There are lots of things I've had to guess at when writing my driver - I can now just look at see what their solutions are!

charliedurrant
Posts: 35
Joined: Sun Mar 18, 2012 12:06 am

Re: Simon's accelerated X development thread

Tue Nov 20, 2012 1:54 am

Simon,

When I say I new to this I don't think I could be any more shiny. I've used linux for a few weeks in 15 years but I now have my debian VM running (should have gone with ubuntu) and tk is compiling ready for debugging. Even if I don't succeed I'm learning.

Charlie

User avatar
Mequa
Posts: 172
Joined: Sun Sep 09, 2012 9:54 pm
Location: England
Contact: Website

Re: Simon's accelerated X development thread

Tue Nov 20, 2012 3:08 am

Hi, have the open-sourced Broadcom drivers proved useful for this project?

I would love to see a hardware-accelerated Raspbian LXDE environment one day with faster graphics rendering, it would make the Raspberry Pi much more usable overall. Any progress on this project?

Return to “General discussion”