I updated my Raspbian Wheezy minimal image, raspbian_wheezy_20130926.img.7z is available here:
http://www.linuxsystems.it/raspbian-wheezy-armhf-raspberry-pi-minimal-image/
– New kernel.
– New firmware.
– Works with Raspberry Pi model B+
|
||||||
I updated my Raspbian Wheezy minimal image, raspbian_wheezy_20130926.img.7z is available here: – New kernel. I updated my Raspbian Wheezy minimal image, raspbian_wheezy_20130923.img.7z is available here: – New kernel. If a big team like CD Projekt RED thinks that using a wrapper layer like eON by Virtual Prgramming is a suitable solution for a AAA game port like The Witcher 2, who am I to ditch wine (which performs even better than eON)? I might even speak about benchmarking a native linux 3DMark version according to CD Projekt RED standards… Anyway, I wanted to becnhmark something different and in particular to test wine’s D3D command stream patches, so I decided to try the famous 3DMarks: 3D Mark 2001, 3D Mark 2005 and 3DMark 2006. I did not test 3DMark 2003 because of this regression. I’m using default 3DMark settings and my video card is an AMD Radeon HD 7950. For radeonsi I’m using kernel 3.15-rc5 + PTE patches (VRAM page table entry compression) + hyperz (R600_DEBUG=hyperz). I’m also using libdrm git, xf86-video-ati git, llvm 3.5 git with a rebased Tom Stellard’s si-spill-fixes-v4 branch, mesa git (OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0-devel (git-57730d6)) and Keith Packard’s xorg-server glamor-server branch (1.16.0 RC 2). Catalyst version is 14.4 (kernel 3.14.3, xorg-server 1.15.1 because of compatibility issues). Wine version is 1.7.18 + Stefan Dösinger’s D3D command stream patches. What about you? Please share your 3DMark results and tell me which card/driver/wine version you are using. In my previous post someone asked about my radeonsi ebuilds, so I decided to create a new overlay. Here you can find the new radeonsi overlay: http://www.linuxsystems.it/overlay/ As I said in my previous post radeonsi is becoming faster than Catalyst in several scenarios. Some peoples on phoronix didn’t think it was actually possible and blamed “old games”. So I decided to benchmark Steam games, in particular Half-Life 2: Lost Coast, Team Fortress 2 and Portal. Unfortunately these are the only Steam games with a phoronix-test-suite profile available and they all use the Source engine. Hopefully the Phoronix Test Suite’s author Michael Larabel will provide us more profiles in the future, games with different engines. AMD Radeon HD 7950 using kernel 3.15-rc4 + PTE patches (VRAM page table entry compression) + hyperz (R600_DEBUG=hyperz). I’m also using libdrm git, xf86-video-ati git, llvm 3.5 git, mesa git (OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0-devel (git-cf93f86)) and Keith Packard’s xorg-server glamor-server branch (1.16.0 RC 2). Catalyst version is 14.4 (kernel 3.14.3, xorg-server 1.15.1). Radeonsi is 21% faster than Catalyst with Half-Life 2: Lost Coast. Radeonsi is 3% faster than Catalyst with Team Fortress 2. Radeonsi runs at 81% of Catalyst with Portal. Here is the link on openbenchmarking: http://openbenchmarking.org/result/1405092-SO-1405097SO80 Edit: see also Radeonsi is faster than Catalyst with Steam games. I did some benchmarks of my AMD Radeon HD 7950 using kernel 3.15-rc4 + PTE patches (VRAM page table entry compression) + hyperz (R600_DEBUG=hyperz). I’m also using libdrm git, xf86-video-ati git, llvm 3.5 git, mesa git (OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0-devel (git-cf93f86)) and Keith Packard’s xorg-server glamor-server branch (1.16.0 RC 2). Catalyst version is 14.4 (kernel 3.14.3, xorg-server 1.15.1). Radeonsi is 14% faster than Catalyst with Xonotic. Radeonsi is 4% faster than Catalyst with Openarena. Radeonsi runs at 76% of Catalyst with Unigine Heaven. Radeonsi runs at 62% of Catalyst with Unigine Valley. Something’s wrong with radeonsi and Unvanquished, it’s barely 30% of Catalyst. Here is the link on openbenchmarking: http://openbenchmarking.org/result/1405084-SO-1405083SO83 I also compared 2D acceleration using Keith Packard’s xorg-server glamor-server branch between radeonsi, Catalyst and Intel’s HD 4000 SNA: http://openbenchmarking.org/result/1405080-SO-1405080SO26 Intel’s HD 4000 SNA 2D acceleration is much faster in almost every test compared to both Catalyst and radeonsi, but glamor is much faster using Keith Packard’s xorg-server glamor-server branch compared to the old standalone glamor lib. New patch against 3.14 which backports drm from 3.15-rc1-pre: http://www.linuxsystems.it/linux-drm-graphic-stack-backports/ I bought the Blu-ray of “The Hobbit: An Unexpected Journey” (which is considered to be a reference for video quality) and I decided to do more codec tests. If you want to know something about my methodology please read my previous article. I ripped a scene from the Blu-ray and I cropped it to 1920×800, then I compressed it using x264 LOSSLESS compression. Except for the crop it is bit identical with the Blu-ray. I will not go in the details because I already explained everything, also I coded a new screenshot comparator which eases the job: use it to find the details about sources, codecs, etc.. like the exact command line with the parameters I used. It also allows you to download the sample videos. It took quite a while to code it, it uses XML to store data and it quickly grown to ~200 lines of code so please let me known if something’s wrong. I know, the graphic sucks but I hate web programming Just some considerations… First of all: where is VP9? There isn’t. Why? Because after a whole week it still didn’t finish encoding. Seriously, using a wooden abacus would be faster! If someone wants to waste his cpu cycles to encode it, please send me the resulting files. You can download the source video using the screenshot comparator and encode it with this command:
Also, someone ranted because of lack of PSNR/SSIM graphs. Who needs SSIM when you can use your eyes? Anyway, here is the shiny graph and here is how I created it:
Then you can use Libreoffice Calc to make the graph. Some notes about the graph: yeah this is a completely different scenario from the previous test and x265 wins hand down. But beware, this is just with a VERY low bitrate. I encoded the source with x265 using CRF 28 which resulted in a 756 kbps bitrate, then I two pass encoded using x264 and vp8 with a 756 kbps target bitrate: this is the resulting SSIM graph. If you raise the bitrate there are no such big advantages using x265 over x264 which is a pity. Link. Source vs x265. I did another encoding starting with x265 CRF 23 which resulted in a 1733 kbps bitrate. Link. Source vs x265. Finally I did two more tests with x265 16 bit variables CRF 28 and 23: 943 kbps and 1186 kbps. I used x264 hi10p to match the file size. I just discovered “16bpp” doesn’t mean high bit depth in x265, anyway it’s bugged and shouldn’t be used right now. Here is the SCREENSHOT COMPARATOR. Press F11 to switch your browser to the full screen mode. I wanted to know something about the actual x265 development state and since I didn’t find anything up to date I decided to do my own tests.
x264 –version This is my 112s / 216MB test video: Let’s encode it using x265 first:
As you can see I used ffmpeg to decode the video and then I piped the raw stream to the x265 encoder. I did a quality based encoding with the default crf (28) which gives low quality but low size output files (considering my source isn’t lossless this is exactly what I want to easily spot differences with x264). Then I generated a file of the very same size using two pass encoding with x264:
Here is the result:
As you can see prova.h264 is 46094455 bytes (~45MB) while prova.h265 is 46238768 bytes (~45MB). The video encoded with x264 is just 0.14MB smaller which is a 0.3% difference. Using the placebo presets I used the slowest settings which are supposed to give the best quality for both encoders. Here are the encoded files: Anyway we can compare DECODING speeds
BENCHMARKs: VC: 5.640s VO: 0.003s A: 0.000s Sys: 0.333s = 5.976s mplayer -benchmark -nosound -lavdopts threads=16 prova.h265 -vo null 2> /dev/null BENCHMARKs: VC: 26.936s VO: 0.003s A: 0.000s Sys: 0.360s = 27.300s As you can see the video encoded with x264 took 5.976s to decode while the x265 one took 27.300s. Let’s take some screenshots:
Finally, let’s compare them: x264 vs x265 source vs x265 Press F11 to switch your browser to the full screen mode and click on the image to switch from the x265 screenshots to source or x264. I also put some previous/next buttons (there are 10 png screenshots in total). I don’t want to be critical because x265 is still in early stages of development, but as you can see it completely washed the video: details are gone. Sometimes x265 did a better job but overall x264 definitely wins. |
||||||
Copyright © 2024 LinuxSystems - All Rights Reserved Powered by WordPress & Atahualpa |
Recent Comments