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

Non integer coordinates in image transforms

Tue Jan 22, 2013 12:45 pm

Thanks a bunch!

I found this discussion that could be related to the non integer coordinate problem:
http://lists.cairographics.org/archives ... 15093.html
I may as well be totally wrong...

So I will have a look at this xrender benchmark - not before weekend that is...
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 24, 2013 7:59 am

rdesktop and xfreerdp seems to work and shows some performance improvements but also shows some ugly corruptions. You may try that out.

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

Re: Accelerated X driver testing

Thu Jan 24, 2013 10:10 pm

I just gave the render_bench a shot:

The zip contains results for the Raspi named crumb running render_bench with the display either at crumb or on kriecher.

kriecher is a fast PC running Xming. Despite the fact that Xming renders in software (afaik) it is twice as fast - on a i7-2600 that is...

Would it make sense to generate results with the "accelerated" driver?
Attachments
render_bench_results.zip
bench results
(5.65 KiB) Downloaded 158 times
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

Fri Jan 25, 2013 9:07 am

diereinegier wrote:I just gave the render_bench a shot:

The zip contains results for the Raspi named crumb running render_bench with the display either at crumb or on kriecher.

kriecher is a fast PC running Xming. Despite the fact that Xming renders in software (afaik) it is twice as fast - on a i7-2600 that is...

Would it make sense to generate results with the "accelerated" driver?
Hi, I think for the moment the point would be, did it do all the rendering correctly, without any distortions or artifacts and without falling over? We know that there is lots of debug in Simons driver, so it's not going to be running optimally as far as speed is concerned. 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

Fri Jan 25, 2013 8:20 pm

I ran the benchmark on the accelerated driver and as far as I can
tell the visual results seem similar enough.

During the run the Xorg server printed some warnings:
(EE) FBDEV_RPI(0): FBIOBLANK: Operation not permitted

Program received signal SIGUSR1, User defined signal 1.

Program received signal SIGUSR1, User defined signal 1.
(EE) FBDEV_RPI(0): FBIOBLANK: Operation not permitted
(WW) FBDEV_RPI(0): composite would have overread in Y by 13 pixels
(WW) FBDEV_RPI(0): composite would have overread in Y by 13 pixels
(WW) FBDEV_RPI(0): composite would have overread in Y by 13 pixels
(WW) FBDEV_RPI(0): composite would have overread in Y by 43 pixels
(WW) FBDEV_RPI(0): composite would have overread in Y by 43 pixels
(WW) FBDEV_RPI(0): composite would have overread in Y by 21 pixels
(WW) FBDEV_RPI(0): composite would have overread in Y by 21 pixels
(WW) FBDEV_RPI(0): composite would have overread in Y by 43 pixels
(WW) FBDEV_RPI(0): composite would have overread in Y by 13 pixels
(WW) FBDEV_RPI(0): composite would have overread in Y by 13 pixels
(WW) FBDEV_RPI(0): composite would have overread in Y by 13 pixels

I did a rerun to find out which test exactly triggered the warnings.
But unfortunately I could not reproduce it.

During the test the screen went black and came back without any
recognizable pattern or beeing triggered by mouse or keyboard
interaction.

These events were entirely uncorrelated with the occasional
(EE) FBDEV_RPI(0): FBIOBLANK: Operation not permitted
messages printed.
Attachments
accel.accel.result.txt.zip
accel results
(546 Bytes) Downloaded 140 times
Download my repositories at https://github.com/GeorgBisseling

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

Re: Accelerated X driver testing

Fri Jan 25, 2013 8:44 pm

Using
XFixed point3 = XDoubleToFixed(0.3);
XFixed point5 = XDoubleToFixed(0.5);
XFixed point7 = XDoubleToFixed(0.7);

in the XTransform [0][2] and [1][2] passed to XRenderSetPictureTransform to control XRenderComposite lead to no visual flaws.
Download my repositories at https://github.com/GeorgBisseling

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

Re: Accelerated X driver testing

Fri Jan 25, 2013 9:55 pm

Switching from Mem vc to 4k.
render_bench still looking good.

Even the stripe-like noise in the pictures on http://www.heise.de is gone.

Maybe due to apt-get upgrade and rpi-update.

Fine.

Will switch to SelfManagedOffscreen no.
Download my repositories at https://github.com/GeorgBisseling

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

Re: Accelerated X driver testing

Fri Jan 25, 2013 10:33 pm

recap: 4k, SelfManagedOffscreen false.

BlockSize is the standard of about 20 MB.

render_bench looks good.

Starting iceweasel and havein two tabs leads to total lockup. Even the Putty's are dead.
Download my repositories at https://github.com/GeorgBisseling

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 27, 2013 4:01 pm

After being sick with yet another cold (I didn't know you could get two back-to-back) I'm debugging again...and making no progress repro-ing these problems :-(
I'm wondering if there could be some additional factor I haven't considered. There have been a number of 'interesting' bugs in the firmware+jkernel which have been recently fixed - both with the Ethernet driver and VPU interface. Could anyone confirm the corruption with the latest firmwares?
Also is anyone playing sound or has a CPU clock frequency or temperature widget on their desktop?

diereinegier could I ask which resolution you are using with Midori, and are you using the application full-screen?

NB: using the 4k memory mode turns off most of the fun features of the driver, so that in conjunction with self managed = off should be ultra-robust. I expect no troubles there...!

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

Re: Accelerated X driver testing

Sun Jan 27, 2013 9:16 pm

Hi Simon,
I did do a rpi-update on about the 12th, this was to specifically get the changes you told us about, to do with the bcm_mailbox it didn't make any obvious difference. I do have the CPU speed and temp displayed on the task bar, no sounds though, I can try turning them off, but some corruption, like the Rasperry Pi banner on this forum, is basically almost always present, so not an occasional thing, which I'm assuming it would be if there was some kind of clash in the mailbox.
I'll let you know if there is any difference with the CPU freq and temp displays removed.
I'll probably try another update to get the latest bleeding edge as well.
I also now have a TTL serial to USB dongle, if that can be of any use.
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

Sun Jan 27, 2013 9:35 pm

teh_orph wrote:
diereinegier could I ask which resolution you are using with Midori, and are you using the application full-screen?
The last time I saw corruptions in midori was before my latest rpi-upgrade. I could not reproduce these corruptions after that. When I saw them I used the browsers (midori, iceweasel, chromium) in maximized window (not fullscreen via F11) at a resolution of 1280x1024 as given by my DVI-attached LCD.

Regarding the mem modes (vc, 4k, mem). What mode should be the most "interesting" in terms of speedup and risk?

Another question: I could not see any corruptions with the render_bench, even when forcing non-integer coordinates. Could it be possible that the corruptions appear when using much more traditional down-to-earth functions like XGetImage, XPutImage? Maybe when they are not synchronized with Xrender?

Another suggestion: wouldn't it be helpful if I tried to use tcpdump or wireshark to find out what XLib drawing packets are actually used for displaying pictures and scrolling in midori? Or do you know that already from your debugging? How did you do it apart from setting breakpoints in your implementation of the Xrender functions?

I am very sorry to post that many questions, but I do not have any reproducible corruption to report, so I would like to get a little deeper into the problem.
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 28, 2013 2:29 pm

Hi Simon,
I've done an apt-get upgrade and an rpi-update.

Code: Select all

 Linux raspberrypi 3.6.11+ #362 PREEMPT Tue Jan 22 14:52:21 GMT 2013 armv6l GNU/Linux
Jan 26 2013 19:25:49
Copyright (c) 2012 Broadcom
version 365344 (release) 
I've also turned off the CPU frequency and temp display on the task bar.
Unfortunately I still get exactly the same corruption of photos displayed in netsurf 2.9 and the corruption of the Raspberry Pi banner in Midori 0.4.3.
I also have been getting a small corruption over the Scratch icon in the top left corner, I have always had this, but haven't mentioned it as it was minor, but thought you might as well know. In this instance the first image shows what appears to be part of the LXTerminal icon, possibly rotated right by a few pixels, over the Scratch icon, this was present at start up. I then clicked once on the Midori icon and the second corruption occurred, this time of the Midori icon over the Scratch icon, again apparently rotated right, it is also darker than the standard Midori icon, presumably because I had selected the Midori icon and so it had darkened. Obviously if I make the Scratch icon refresh the corruption goes away.
Link to all pictures of image corruption.
https://picasaweb.google.com/105866990983947674115/Pi
From what you say I'm assuming you cannot reproduce these problems :-( in which case is it at all possible that the zip files we installed from are in some way compromised? Alternatively is it possible that you do something very slightly different to the procedure that you gave on your http://elinux.org/RPi_Xorg_rpi_Driver#I ... the_driver because I basically copy and past all the commands each time I run up your X driver.
Hope this is helpful.
Regards, Kevin.

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

Re: Accelerated X driver testing

Mon Jan 28, 2013 3:12 pm

PS. I've just added another picture of Midori, as a new problem has appeared, again intermittently, but roughly half the time, I'm getting a random pixel pattern on half of the "Post a New Topic" button, again this happens as I scroll the page up and down.
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 28, 2013 4:11 pm

bleep42 wrote:PS. I've just added another picture of Midori, as a new problem has appeared, again intermittently, but roughly half the time, I'm getting a random pixel pattern on half of the "Post a New Topic" button, again this happens as I scroll the page up and down.
Regards, Kevin.
I saw very similar problems. Maybe it is due to the fact that we use the 512MB model and teh_orph uses the 256MB model?

BTW. could you please post the driver configuration file and the config.txt that you currently use?

Only recently did I change the default configuration.
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 28, 2013 4:24 pm

diereinegier wrote:
bleep42 wrote:PS. I've just added another picture of Midori, as a new problem has appeared, again intermittently, but roughly half the time, I'm getting a random pixel pattern on half of the "Post a New Topic" button, again this happens as I scroll the page up and down.
Regards, Kevin.
I saw very similar problems. Maybe it is due to the fact that we use the 512MB model and teh_orph uses the 256MB model?

BTW. could you please post the driver configuration file and the config.txt that you currently use?

Only recently did I change the default configuration.

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
and

Code: Select all

disable_overscan=1
#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
This is overclocked, but I've tried without and still get corruption.
As it happens, I also have a 256MB Pi, I could try that. :-)
Nope, it's the same on a 256MB Pi. :-(
Now back on 512MB Pi and I've loaded a photo into Midori and am getting the same chunky corruption that I was getting in Netsurf, I get this by dragging the slide bar left and right, slowly is best. I've added another image to the others, note also the corruption over the Scratch icon again.
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 28, 2013 8:23 pm

Yes, with "MemMode" "vc" I see all the corruptions that you see.

With SelfManagedOffscreen "true" I can open 4 tabs loaded with pictures.

Switching to "false".

Restoring session in iceweasel.

After some klicking and scrolling the machine locks up completely.

putty terminals report disconnect.

Reboot. Good that I soldered a reset jumper pin on the PCB and put a little red button on top of the case.

Switching back to true: corruptions are still gone and everything seems stable.
Download my repositories at https://github.com/GeorgBisseling

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 28, 2013 9:30 pm

When switching the font size in LXTerm from Monospace 8 to Monospace 10 I got this SEGV two times in a row:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
Op (width=<optimized out>, height=<optimized out>, source=..., dest=...,
    mask=..., coord=..., width=<optimized out>, height=<optimized out>)
    at /home/simon/Desktop/x/src/driver/xf86-video-fbdev_exa/src/./composite_ops.in    at /home/simon/Desktop/x/src/driver/xf86-video-fbdev_exa/src/./composite_ops.in    at /home/simon/Desktop/x/src/driver/xf86-video-
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

Tue Jan 29, 2013 8:54 am

diereinegier wrote:Switching back to true: corruptions are still gone and everything seems stable.
Hi Diereinegier,
Do you really mean setting "SelfManagedOffscreen" to "true" here? When I set this to "false" it removes all my screen corruptions, when I set it "true" they all come back.
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

Tue Jan 29, 2013 10:32 am

Yes, I double checked with using Midori and iceweasel.

This behavior was so unexpected and implausible that I hardly dared to post it. But so it was.

And then I did some other stuff and had the strange segfault.

Regular behavior is vc + Self=true does screen corruption, but is stable and
vc + self=false does no corruptions but I get lock ups. But in this particular case it behaved differently.
Even if a data point is embarrassing you have to have good reason to entirely ignore it.

The catch in this scenario maybe was that switching from true to false was done without a reboot. Just killed the Xorg and then restarted. I did not even unload/reload the kernel module. Maybe that made the difference? Simon?
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

Tue Jan 29, 2013 10:58 am

diereinegier wrote:The catch in this scenario maybe was that switching from true to false was done without a reboot. Just killed the Xorg and then restarted. I did not even unload/reload the kernel module. Maybe that made the difference? Simon?
Hi Diereinegier,
Yes I always do a complete stop, I even quit out of gdb to be sure, I then change the settings, then restart gdb, and X. You definately have to at least stop X, because I believe it only checks the initilisation paramaters at start, but personally I prefer to be quite sure. :-)
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

Tue Jan 29, 2013 11:04 am

Quoted from the driver desgin:
DMA commands are enqueued one after the other to ensure correct results. They are constructed as a chain of DMA control blocks (CBs), and passed to the DMA controller to be kicked in one go.

For cases where the DMA set-up time would take longer than a naive CPU copy or fill, a CPU fallback is used instead.
How do you ensure that you stay in sync with the enqueued DMA requests when choosing the CPU fallback? Or do you fallback only when the queue is empty?
Download my repositories at https://github.com/GeorgBisseling

Huulivoide
Posts: 26
Joined: Fri Aug 19, 2011 8:24 pm

Re: Accelerated X driver testing

Sun Feb 03, 2013 1:11 pm

When do we get the source code? I think Archlinux has quite
a big user base as well, would be great to have this in testing
in there as well.

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

Re: Accelerated X driver testing

Mon Feb 04, 2013 5:55 am

diereinegier wrote:I just gave the render_bench a shot:

The zip contains results for the Raspi named crumb running render_bench with the display either at crumb or on kriecher.

kriecher is a fast PC running Xming. Despite the fact that Xming renders in software (afaik) it is twice as fast - on a i7-2600 that is...
The render_bench program is more like just a simple example, which demonstrates how to use XRender extension in your own code. But it does not have much value as a benchmark (despite the name), because it only tests a limited subset of operations, which are not necessarily representing what real applications are typically doing.
Would it make sense to generate results with the "accelerated" driver?
As a practically useful and relevant benchmark, I would recommend trying https://github.com/ssvb/trimmed-cairo-traces

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

Re: Accelerated X driver testing

Mon Feb 04, 2013 6:06 am

And by the way, render_bench needs the following fix to get non-bogus results with the accelerated drivers: https://github.com/ssvb/render_bench/co ... f1324d0011 :)

The same issue actually also affected cairo-perf-trace: http://lists.cairographics.org/archives ... 23984.html
Until it got fixed (the fix is already available in cairo-1.12.12): http://cgit.freedesktop.org/cairo/commi ... 1edfdbd550

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

Re: Accelerated X driver testing

Fri Feb 08, 2013 9:38 pm

Thank you Simon, yesterday I had a look at the source that you published on GitHub.

Could you point me at the location where the decision is made between VPU upload and CPU fallback?

Are you currently working on fixing the errors found so far?
Download my repositories at https://github.com/GeorgBisseling

Return to “General discussion”