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

Re: Accelerated X driver testing

Thu Jan 10, 2013 11:22 am

It depends. Can I try it out and see what it does?
Some browsers (eg Chromium) use rendering options that I can't accelerate. If you can get an operation which fits what the VPU can accelerate you should see an improvement. And some do it completely client-side in which case I have no chance at getting in there at all.

User avatar
bleep42
Posts: 156
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: Accelerated X driver testing

Sat Jan 12, 2013 2:50 pm

Hi Simon,
As it's raining I'm getting a good chance to test :-)
Apart from the known features I have got a new message in gdb, but I'm assuming it's probably ok, as there don't seem to be any side effects.

Code: Select all

(II) FBDEV_RPI(0): max composite ops - flushing now
(II) FBDEV_RPI(0): max composite ops - flushing now
(II) FBDEV_RPI(0): max composite ops - flushing now
I later went to this site.
http://digitalfantastico.blogspot.co.uk ... aving.html
and got these outputs. If I scrolled the page it was painfully slow and would freeze everything for seconds at a time.
I stopped Midori, and tried again, got the same thing, but no more debug output. If I just killed off the tab this page was in, everything was back to normal again, loaded a different page, all normal.

Code: Select all

[mi] EQ overflowing.  Additional events will be discarded until existing events are processed.

Backtrace:

[mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack.
[mi] mieq is *NOT* the cause.  It is a victim.
[mi] EQ overflow continuing.  100 events have been dropped.

Backtrace:

[mi] Increasing EQ size to 512 to prevent dropped events.
[mi] EQ processing has resumed after 147 dropped events.
[mi] This may be caused my a misbehaving driver monopolizing the server's resources.
[mi] EQ overflowing.  Additional events will be discarded until existing events are processed.

Backtrace:

[mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack.
[mi] mieq is *NOT* the cause.  It is a victim.
[mi] Increasing EQ size to 1024 to prevent dropped events.
[mi] EQ processing has resumed after 37 dropped events.
[mi] This may be caused my a misbehaving driver monopolizing the server's resources.
[mi] EQ overflowing.  Additional events will be discarded until existing events are processed.

Backtrace:

[mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack.
[mi] mieq is *NOT* the cause.  It is a victim.
[mi] EQ overflow continuing.  100 events have been dropped.

Backtrace:

[mi] EQ overflow continuing.  200 events have been dropped.

Backtrace:

[mi] EQ overflow continuing.  300 events have been dropped.

Backtrace:

[mi] Increasing EQ size to 2048 to prevent dropped events.
[mi] EQ processing has resumed after 339 dropped events.
[mi] This may be caused my a misbehaving driver monopolizing the server's resources.
(II) FBDEV_RPI(0): max composite ops - flushing now
(WW) FBDEV_RPI(0): composite would have overread in X by 1108 pixels
(WW) FBDEV_RPI(0): composite would have overread in X by 1108 pixels
There were no messages to the kernel.log.
Otherwise I've it's been running continuously now for at least 5 hours, with no other problems.
I am using the latest bleeding edge kernel. I only had Midori and Task Manager running.
PS. I've just tried the same page under the same conditions but on a standard Raspbian install and it's almost as bad, I would have to say it is better, but still slow, it's obviously a very poorly designed page.
Regards, Kevin.

User avatar
bleep42
Posts: 156
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: Accelerated X driver testing

Sat Jan 12, 2013 5:06 pm

Hi Simon,
Just found a problem viewing a .jpg image in Netsurf.
It was a image 2304x1854, when I dragged the slider to move the image sideways, I got a rectangular chunk, or chunks, of the image, about the size of a large postage stamp, sometimes bigger, being displayed above where they should be; where they came from, the image was correct and complete. If I drag the vertical slider up and down, I don't get any corruption.
Regards, Kevin.

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

Re: Accelerated X driver testing

Sat Jan 12, 2013 5:13 pm

Coolio thanks for the report. I have no idea about the MI stuff (MI="machine independent"...the complete opposite of what I've been writing ;)) but I'll give it a debug.
It's interesting about the page slowing to a crawl on both the stock driver and my driver. Could you turn on the VerboseReporting option and see what it looks like on the debugger output? It sounds like the browser is sending an abnormal amount of draw calls to the driver. We've not seen that with Midori but have with Netsurf.
Finally the scroll in the large image problem. Can you give any more detail? Is there a URL? Do you have VPU composition turned on? How can I reproduce this? VPU composite is officially bugged!

User avatar
bleep42
Posts: 156
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: Accelerated X driver testing

Sat Jan 12, 2013 6:24 pm

Hi Simon,
The image is just a large jpg in my /home/pi/ directory, being viewed in Netsurf, I've tried several and it's always the same, so I'd imagine any large jpg should do it. If I set "VpuOffload" "false" I still get the corruption, if I also set "SelfManagedOffscreen" "false" it doesn't do it any more, if I set "VpuOffload" back to "true" it also doesn't do it, so it seems to be related to SelfManagedOffscreen.

I've enabled VerboseReporting but it's spewing out so much I can't capture it in the window, can it be sent to a file from inside gdb? I have tried that web page http://digitalfantastico.blogspot.co.uk ... aving.html from Chromium using your driver and although it's slow to load, it's usable and will scroll up and down ok.
Regards, Kevin.

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

Re: Accelerated X driver testing

Sat Jan 12, 2013 7:56 pm

bleep42 wrote:Hi Simon,
The image is just a large jpg in my /home/pi/ directory, being viewed in Netsurf, I've tried several and it's always the same, so I'd imagine any large jpg should do it. If I set "VpuOffload" "false" I still get the corruption, if I also set "SelfManagedOffscreen" "false" it doesn't do it any more, if I set "VpuOffload" back to "true" it also doesn't do it, so it seems to be related to SelfManagedOffscreen.
Excellent - can you try some images which are significantly smaller? Sounds like it is running out of memory that it can work with if it's that big. That image when uncompressed is 16 MB! This mode is very new, and I'm unsure of what the behaviour (within the rest of X, not the driver) is when it runs out of memory. Looks like you've found it!
I've enabled VerboseReporting but it's spewing out so much I can't capture it in the window, can it be sent to a file from inside gdb?
Nope, that's all I need to know :) That text-based display should refresh reasonably slowly. How often would you estimate that the text on the console repaints itself? Every second? Or much faster than this?

User avatar
bleep42
Posts: 156
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: Accelerated X driver testing

Sat Jan 12, 2013 11:36 pm

Hi Simon,
With all options at default, I've tried images down to 800x600 and I still get the same corruption.
I've put a photo on Picasa; in the NetSurf window, top left you can see a rectangle of carpet, which is from directly below it, bottom left.
https://picasaweb.google.com/knmoore/Pi ... 3939100514

If I enable verbose and go to that web page, the debug window scrolls in bursts, it'll do nothing for say 10 seconds, then go ballistic, then freeze then ballistic, after a while, presumably once the page has finished doing whatever it's doing it returns to updating about every 6 seconds.
Regards, Kevin.

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

Re: Accelerated X driver testing

Sun Jan 13, 2013 12:00 am

Thanks, I'll check it out.
I've spent all week trying to find bugs in the VPU code. After a lot of false positives, there appears to be nothing wrong with it. Err... I'm running CPU versus VPU and diffing them, with random numbers going in and lots of different image widths, heights, strides, pixel formats etc. Nothing.

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

Re: Accelerated X driver testing

Sun Jan 13, 2013 12:54 am

Ok, the mega slowdown you've found in Midori on that page: for some reason some large part of the page is being rendered like normal (with my driver) and then the rendered output is being rendered *with a 3D transformation* back in to the browser. I reject all operations that have an embedded transformation and fall back to the generic pixman library where it is done for me. It is then rendered there in software, and drawn to the screen. This pixman rendering step is incredibly slow - it takes several seconds per image in my test.

I can see why it would be slow with the stock driver too - that driver just directs everything at pixman. In that sense the stock driver will be marginally faster than mine.

This several seconds per render step is why the machine appears to lock up - pixman is hanging the X server for seconds at a time. Short of writing a system to target the 3D hardware there's nothing I can do in the short term with this particular problem!

Code: Select all

(gdb) print /x *pSrc->transform
$62 = {matrix = {{0x10000, 0x0, 0xff438000}, {0x0, 0x10000, 0xf8b30000}, {0x0, 0x0, 0x10000}}}
(gdb) bt
#0  0xb6e6ade8 in pixman_image_composite32 () from /usr/lib/arm-linux-gnueabihf/libpixman-1.so.0
#1  0xb6985b54 in fbComposite (op=<optimized out>, pSrc=0x2a4dd300, pMask=0x0, pDst=0x2a4bec38, xSrc=-177, ySrc=-1736,
    xMask=10, yMask=133, xDst=10, yDst=133, width=727, height=403) at ../../fb/fbpict.c:62
#2  0xb696363c in ExaCheckComposite (op=<optimized out>, pSrc=0x2a4dd300, pMask=0x0, pDst=0x2a4bec38, xSrc=-177,
    ySrc=-1736, xMask=10, yMask=133, xDst=10, yDst=133, width=727, height=403) at ../../exa/exa_unaccel.c:638
#3  0xb6960688 in exaComposite (op=<optimized out>, pSrc=0x2a4dd300, pMask=0x0, pDst=0x2a4bec38, xSrc=-177, ySrc=-1736,
    xMask=10, yMask=133, xDst=133, yDst=403, width=727, height=403) at ../../exa/exa_render.c:1039
#4  0x2a102abc in damageComposite (op=<optimized out>, pSrc=0x193, pMask=0x3, pDst=0x2a4bec38, xSrc=-177, ySrc=-1736,
    xMask=10, yMask=133, xDst=10, yDst=133, width=727, height=403) at ../../../miext/damage/damage.c:562
#5  0x2a0f5b60 in CompositePicture (op=<optimized out>, pSrc=0x2a4dd300, pMask=0x0, pDst=0x2a4bec38, xSrc=-177, ySrc=-1736,
    xMask=10, yMask=133, xDst=10, yDst=133, width=727, height=403) at ../../render/picture.c:1578
#6  0x2a0faf94 in ProcRenderComposite (client=0x2a4a51f8) at ../../render/render.c:707
#7  0x2a0f647c in ProcRenderDispatch (client=<optimized out>) at ../../render/render.c:1988
#8  0x2a0394c0 in Dispatch () at ../../dix/dispatch.c:428
#9  0x2a029294 in main (argc=4, argv=0x2a029294, envp=<optimized out>) at ../../dix/main.c:288
(gdb)

User avatar
bleep42
Posts: 156
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: Accelerated X driver testing

Sun Jan 13, 2013 11:57 am

Hi Simon,
So basically a very badly coded page then, there is absolutely no reason for the pictures to need to have a 3D Transform. :-( I wonder what Chromium is managing to do to avoid the problem, maybe it's just ignoring the 3D transforms? I've tried it again, using your drivers and it's reasonable, uses a lot of CPU for 10seconds as it's loading it up, then scrolling the page is fine, a bit slow but usable, no lock ups.
From what I have discovered, I think that all the problems, I have found (apart from the web page mentioned above) go away if I set 'SelfManagedOffscreen' to 'false' so I think I'll keep going with that setting for the moment, until you release your next update, unless there is something you want me to particularly test. :)
Regards, Kevin.

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

Re: Accelerated X driver testing

Sun Jan 13, 2013 10:52 pm

Cheers Kevin - again the help is much appreciated!
I'm still having trouble repro-ing the thing with the partially corrupt image. Is there a set of minimum steps to do? Can I find out which version of Netsurf (?) you are using, and what exactly your Xorg driver config file looks like? Also, are you using the CMA or fixed-split memory option? Finally what screen resolution are you using?

User avatar
bleep42
Posts: 156
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: Accelerated X driver testing

Mon Jan 14, 2013 9:39 am

teh_orph wrote:Cheers Kevin - again the help is much appreciated!
I'm still having trouble repro-ing the thing with the partially corrupt image. Is there a set of minimum steps to do? Can I find out which version of Netsurf (?) you are using, and what exactly your Xorg driver config file looks like? Also, are you using the CMA or fixed-split memory option? Finally what screen resolution are you using?
Hi Simon,
I’m at work @ the moment, so can’t give a definitive reply, but I can give you most of the info you want.
Screen resolution, and other stuff.

Code: Select all

mode "1920x1200"
    geometry 1920 1200 1920 1200 32
    timings 0 0 0 0 0 0 0
    rgba 8/0,8/8,8/16,8/24
endmode
The version of Netsurf will be whatever came with the latest Raspian image, apart from adding Chromium I have not made any changes from the standard image.
Last week I did a rpi-update to get the latest bleeding edge kernel, as of the 9th Jan. I think, this was so I got the bcm_mailbox_property function update.
Xorg driver config file is exactly as installed from your zip files. I have subsequently changed 'SelfManagedOffscreen' to 'false' because it cures the problem, but completely standard to get the corruption.
I have gpu_mem=96 in config.txt, I haven't got any cma_ options set, so these will presumably be default. I am using a 512Mb Pi, driving the screen with HDMI.
To get the corruption, after starting up, load a reasonably large jpg file, I simply double click on a jpg, which happens to be on a USB memory stick and it loads into Netsurf by default. Make sure the image is significantly bigger than the Netsurf window, say double in both X & Y, then use the mouse to grab the slider bar and slide the window left and right, it seems to be easier with bigger images, first or second slide with a big image, but as you can see an 800x600 did it as well after a bit of waggling, it doesn’t do it for up and down.
I should be able to give you the exact Netsurf version tonight. Any other questions let me know. :)
Regards, Kevin.

User avatar
diereinegier
Posts: 166
Joined: Sun Dec 30, 2012 5:45 pm
Location: Bonn, Germany
Contact: Website

Re: Accelerated X driver testing

Mon Jan 14, 2013 6:14 pm

I plan to do some more tests tonight. Is there an updated release of the diver?
Download my repositories at https://github.com/GeorgBisseling

User avatar
bleep42
Posts: 156
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: Accelerated X driver testing

Mon Jan 14, 2013 8:39 pm

Hi Simon,
Netsurf V2.9 Feb 27th 2012.
For comparison, I have tried the same images in the Image viewer built into Raspbian, that doesn't have a problem, but is very slow scrolling around the image.
I have also loaded a large image into Midori, that also does not have a problem, is marginally faster than the Image viewer, but nothing like as smooth or fast as Netsurf.
For good measure I have also tried the same on a bog standard Raspbian install, without your drivers, I get very similar results, apart from the corruption when using Netsurf.
For confirmation:-

Code: Select all

Linux raspberrypi 3.6.11+ #352 PREEMPT Wed Jan 9 17:16:53 GMT 2013 armv6l GNU/Linux
Jan  9 2013 17:27:35
Copyright (c) 2012 Broadcom
version 361556 (release)
mode "1920x1200"
    geometry 1920 1200 1920 1200 32
    timings 0 0 0 0 0 0 0
    rgba 8/0,8/8,8/16,8/24
endmode

Code: Select all

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
        ### <percent>: "<f>%"
        ### [arg]: arg optional
        Option      "AccelMethod" "EXA"
        Option      "FaultInImm" "false"
        Option      "BlockSize" "20971520"
        Option      "MemMode" "vc"
        Option      "VpuOffload" "true"
        Option      "MboxFile" "/home/pi/char_dev"
        Option      "VpuElf" "/usr/share/X11/vpu_offload_asm.bin"
        Option      "VerboseReporting" "false"
        Option      "SelfManagedOffscreen" "true"
        Identifier  "Card0"
        Driver      "fbdev"
EndSection

Code: Select all

# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
current_limit_override=0x5A000020
force_turbo=1
boot_delay=1
over_voltage=4
#arm_freq=1000
#avoid_pwm_pll=1
#core_freq=450
#gpu_freq=300
#max core_freq=504
#max gpu_freq=336
#over_voltage_sdram=2
#sdram_freq=600
#init_emmc_clock=100000000
#sdhci-bcm2708.emmc_clock_freq=100000000
framebuffer_depth=32
framebuffer_ignore_alpha=1
gpu_mem=96
Regards, Kevin.

User avatar
diereinegier
Posts: 166
Joined: Sun Dec 30, 2012 5:45 pm
Location: Bonn, Germany
Contact: Website

Re: Accelerated X driver testing

Mon Jan 14, 2013 11:11 pm

I tested again with imagemagick, iceweasel, chromium and midori.

midori shows frequent horizontal-striped formed artifacts in pictures. When scrolling the pictures off the screen and scrolling them back the position of the stripes change. I can reproduce this with http://www.heise.de.

However I saw no render problems in chromium and imagemagick. The problems observed in iceweasel remain of course.

I am ready to install any new version you can come up with.

Good Night
Download my repositories at https://github.com/GeorgBisseling

kaeru
Posts: 2
Joined: Thu Jan 17, 2013 9:47 am

Re: Accelerated X driver testing

Thu Jan 17, 2013 9:55 am

Hi there,

thanks for the good work and testing.

I would like to use the RPi as thin client in accel X env. So i will try to test the current driver against xfreerdp and rdesktop (and do some browser testing ofc) and report immediately. They both should be running accelerated right?

Kaeru

dusty1000
Posts: 2
Joined: Mon Jan 14, 2013 4:58 pm

Re: Accelerated X driver testing

Thu Jan 17, 2013 4:28 pm

Hello, I'm also using RPIs as thin clients in my company.
To get the Citrix Receiver working I had to install Raspian soft float.
Is there any chance you can provide soft float binaries in the future?

yaggi
Posts: 23
Joined: Wed Dec 12, 2012 3:47 pm

Re: Accelerated X driver testing

Thu Jan 17, 2013 10:31 pm

dusty1000 wrote:Hello, I'm also using RPIs as thin clients in my company.
To get the Citrix Receiver working I had to install Raspian soft float.
Is there any chance you can provide soft float binaries in the future?
We are using the same thing at our office. Which receiver version are you using? Did you make your own image or are you using RPi-tc?

dusty1000
Posts: 2
Joined: Mon Jan 14, 2013 4:58 pm

Re: Accelerated X driver testing

Fri Jan 18, 2013 11:58 am

yaggi wrote: We are using the same thing at our office. Which receiver version are you using? Did you make your own image or are you using RPi-tc?
Receiver version is 12.1.0 build 203066.
I used the standard soft float Raspian Image and installed the Receiver manually.
Works like charm, just fast scrolling in Word-documents or web-pages is a little bit stuttering and video is not even worth a try.
Is RPi-tc the better choice ?

yaggi
Posts: 23
Joined: Wed Dec 12, 2012 3:47 pm

Re: Accelerated X driver testing

Fri Jan 18, 2013 7:49 pm

No, we found that using the most up to date receiver w/ the stock Raspbian image WAYYYYY faster then the RPi-Tc build which was slow as snails on sandpaper.

I'll PM you the rest as I don't want this thread to split from its original important topic.

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

Re: Accelerated X driver testing

Sun Jan 20, 2013 4:48 pm

Sorry for the delay guys, busy/sick/snow/work etc. I've been hunting for bugs in the VPU code but just can't find them. Some of the firmware commits may fix some of these corruption bugs, but I need to get back into things to be sure!
Also based on other reports the self managed memory does have edge cases - this was pretty experimental anyway and finding the edge cases was the point of the testing :) I've fixed the Midori scroll crash but since there only seems to be two ways to repro it and the error is quite distinctive I don't see much point in releasing that.

User avatar
bleep42
Posts: 156
Joined: Wed Mar 07, 2012 12:43 pm
Location: Sussex

Re: Accelerated X driver testing

Mon Jan 21, 2013 8:43 am

teh_orph wrote:Sorry for the delay guys, busy/sick/snow/work etc. I've been hunting for bugs in the VPU code but just can't find them. Some of the firmware commits may fix some of these corruption bugs, but I need to get back into things to be sure!
Also based on other reports the self managed memory does have edge cases - this was pretty experimental anyway and finding the edge cases was the point of the testing :) I've fixed the Midori scroll crash but since there only seems to be two ways to repro it and the error is quite distinctive I don't see much point in releasing that.
Hi Simon,
Good to hear from you, hope the bug hunting improves, I know how tricky, 'simple' coding problems can be. :-) I'm still using the driver, but haven't found any further problems. Reliability seems very good, do you think a version with less debug is on the cards. ;-) Anyway hope you have some bug squashing luck.
Regards, Kevin.

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: Accelerated X driver testing

Tue Jan 22, 2013 1:43 am

teh_orph wrote:Ok, the mega slowdown you've found in Midori on that page: for some reason some large part of the page is being rendered like normal (with my driver) and then the rendered output is being rendered *with a 3D transformation* back in to the browser.
Strictly speaking, it's a 2D transformation with homogeneous coordinates:
* http://en.wikipedia.org/wiki/Transforma ... formations
* http://en.wikipedia.org/wiki/Homogeneou ... r_graphics
$62 = {matrix = {{0x10000, 0x0, 0xff438000}, {0x0, 0x10000, 0xf8b30000}, {0x0, 0x0, 0x10000}}}
This particular matrix looks like a simple translation transformation: http://en.wikipedia.org/wiki/Translation_%28geometry%29

What makes this case special is the 0xff438000 fixed point value, which is the same as -188.5 in floating point representation. Basically, we are requested to fetch the image exactly from between the pixels on the pixel grid. And in the case if BILINEAR filter is also set, then the colour of every fetched pixel is interpolated as an average of surrounding pixels. This operation is slow in pixman without special assembly optimizations for bilinear scaling, which are available for NEON, but don't exist for ARMv6 yet.

In any case, this also looks like a defect in the application. I doubt that the original intention was to get the blurry interpolated picture. More like it just tried to do panning or scrolling, but forgot to round the position to nearest integer.

User avatar
diereinegier
Posts: 166
Joined: Sun Dec 30, 2012 5:45 pm
Location: Bonn, Germany
Contact: Website

Re: Accelerated X driver testing

Tue Jan 22, 2013 12:18 pm

Transformations using homogeneous coordinates passed down to an X11 graphics driver?

Boy, my latest XLib programming experience is about 20 years old.

Could you please give me a hint at which API, library or extension the application uses to have that fancy possibilities at its hands? Is that PexLib?

For PexLib maybe we could try to detect matrices generated with the standard creation calls and massage the parameters a little to be perfomance friendly?

Knowing that would make it possible to write some decent tests for that.
Last edited by diereinegier on Tue Jan 22, 2013 12:28 pm, edited 1 time in total.
Download my repositories at https://github.com/GeorgBisseling

ssvb
Posts: 112
Joined: Sat May 19, 2012 6:15 pm

Re: Accelerated X driver testing

Tue Jan 22, 2013 12:26 pm

diereinegier wrote:Transformations using homogeneous coordinates passed down to an X11 graphics driver?

Boy, my latest XLib programming experience is about 20 years old.

Could you please give me a hint at which API, library or extension the application uses to have that fancy possibilities at its hands? Is that PexLib?
That's one of the features of XRender extension, which provides 2D acceleration on Linux desktop systems:
* http://www.x.org/releases/current/doc/r ... rproto.txt
* http://keithp.com/~keithp/talks/usenix2001/xrender/

A simple example of its usage can be, for example, found in render_bench program:
* http://comments.gmane.org/gmane.comp.xfree86.devel/2786

Return to “General discussion”