bjlx.org Packages
Michael Heide
I'm using debian squeeze with Packages from
ftp://www.bjlx.org.cn/loongson2f/squeeze/
(in source.list)
Since Oct 2009 I have several xserver-xorg packages versioned 2:1.6.5-1loongson2. Now there seem to be newer packages with version 2:1.6.5-1loongson.
Because the old ones are newer than the new ones (!?), those packages won't get updated automatically.
I want to try those new xorg packages because speed is slower than with debian lenny. mplayer playing a dvd is sluggish with 50% load at mplayer and 50% load at xorg process. In my lenny install there is mplayer running fine with the same video and 30-40% idle (50$ mplayer, 10% xorg). glxgears is 30fps vs. 130fps.
How to handle this? I did "apt-get autoclean" to remove those old packages from /var/cache/apt/archive. But how to replace those obviously newer packages with the older ones?
I think I will do it manually with aptitude...
btw: maybe I used http://www.bjlx.org.cn/loongson/squeeze/ to install those. What is the difference between those two? This one is for loongson2e, right? My Loongson is a Fuloong 2F so I have to use the loongson2f one, right? Ok...
Regards
Michael
Michael Heide
On Tue, 26 Jan 2010 19:43:42 +0100 Michael Heide <michae...@student.uni-siegen.de> wrote:
> I want to try those new xorg packages because speed is slower than with debian lenny. mplayer playing a dvd is sluggish with 50% load at mplayer and 50% load at xorg process. In my lenny install there is mplayer running fine with the same video and 30-40% idle (50$ mplayer, 10% xorg). glxgears is 30fps vs. 130fps.
I have installed all loongson2f packages now.
I have a Fuloong 2F Box and 4 Linux Installations. RaysOS, Debian Lenny, Squeeze and Gentoo N32. I do not use RaysOS.
Gentoo and Debian Squeeze are slower than Debian Lenny when playing Videos im mplayer. I have a dvd vts??.vob file, 720x576 mpeg2 scaling to 1024x576 while playing. In my Lenny installation it plays fine with ~20% idle. In Gentoo and Squeeze there is 0% idle and mplayer says "Your system is to SLOW to play this!". I can even use "-nosound" with no effect. All 3 are using xv for hardware scaling as far as I can see.
Running glxgears in Lenny it has 130FPS and in Squeeze 30FPS, I have not tested Gentoo. (All three with software rendering because sis315 has no linux-3D-support).
Is there any difference in the sis GPU driver? Should not rely on a xorg.conf option because I copied the Lenny one to Squeeze.
Regards
Michael
qiaochong
Michael Heide 写道:
乔崇 qiaochong.ac.cn 龙芯技术服务中心 office:010-62600855-108 mobile:135219906142009年 11月 16日 星期一 10:31:04 CST
Michael Heide
> mplayer -vo xv
>
Yes, I know. I did that already:
> Michael Heide 写道:
> > [...] All 3 are using xv for hardware scaling as far as I can see. [...]
btw: It's not even xv which is slower. It's also the case with software rendering ala glxgears. As I said before.
Here are further Informations regarding the Debian Squeeze Installation:
#cat /etc/apt/sources.list
deb http://ftp.de.debian.org/debian squeeze main
deb http://security.debian.org/ squeeze/updates main
deb ftp://www.bjlx.org.cn/loongson2f/squeeze/ ./
In /var/log/Xorg.0.log:
(==) SIS(0): Using XAA acceleration architecture
(II) SIS(0): 2D acceleration enabled
(II) SIS(0): Using XFree86 Acceleration Architecture (XAA)
In Lenny there's also <<LoadModule: "GLcore">> which is missing here. And GLX is:
Lenny: (II) GLX: Initialized MESA-PROXY GL provider for screen 0
Squeeze: (II) GLX: Initialized DRISWRAST GL provider for screen 0
In Squeeze "(II) resource ranges after preInit" is empty while in Lenny there are many resource lines following.
Lenny is X.Org 1.4.2, Queeze is 1.6.5.
No other differences which I think are relevant.
Both are using the same resolution (1024x768) with the same bpp (32).
Maybe it's the kernel? In Squeeze it's the rt4ls-Series.
# cat /proc/version
<<<Linux version 2.6.32-lemote2f (root@2f-nas) (gcc version 4.4.2 (Debian
4.4.2-3) ) #1 PREEMPT Sat Dec 26 04:30:33 CST 2009>>>
My Kernel in Lenny I do not know. It's a 2.6.29 one.
Scaling Governor: performance
MPlayer are both from bjlx, there's chinese text output I cannot read ;-). btw: libavcodec51/2 are both original from debian.org.
Regards
Michael
qiaochong
You can try to play movie on console with
mplayer -vo fbdev
and compare the results on two os.
Michael Heide 写道:
刘世伟
Package: xserver-xorg-core
Version: 2:1.7.4-2loongson
Package: ffmpeg
Version: 4:0.5+svn20090706-5loongson
this version is enable-mmi
Michael Heide
> then maybe kernel uncached access accerlate ?
>
> You can try to play movie on console with
> mplayer -vo fbdev
> and compare the results on two os.
I don't get it to work at all. I cannot read the chinese mplayer output to see why its not working. In my lenny install I think it's not even possible because it's using standard 80x24 video. But even if Squeeze seems to use CONFIG_FB, I cannot let mplayer use it. Tried different -vf scale and crop settings... I don't get it. (Video is mpeg2, PAL, 720x576 => 1024x576 YV12)
But this doesn't matter. To compare both without accelerated xv I used "mplayer -vo x11": see attachments
Lenny is much faster.
But this is NO surprise! Also glxgears with software rendering is much faster with lenny (130FPS vs 30FPS). But both are using xserver-xorg-video-sis from debian.org. Both times xv is working because it's faster than x11 on both Systems.
Measuring CPU with nbench, Lenny:
time make: 21.9sec real, 19.5sec user, 1.2sec sys; Memory: 2.827, Integer: 4.425, Float: 2.892
Squeeze:
time make: 22.6sec real, 19.8sec user, 1.2sec sys; Memory: 2.837, Integer: 4.432, Float: 2.903
So it seems not to be CPU related.
(btw chinese mplayer output: At my fuloong the chinese symbols are not rendered. if I run "mplayer --help" connected from my ubuntu x86 machine via gnome terminal + ssh the output gets rendered correctly. both times gnome terminal (local and from the x86) are using utf-8 and monospace font. But this doesn't matter. I cannot read it either ;-) )
Regards
Michael
Michael Heide
> please update;upgrade .
Thanks. Even xv itself works I feel no difference compared to the old version.
It seems it's rendering at all which is slower in squeeze than in lenny. glxgears also is slower. nbench is both the same.
zenglanmu
glxgears,and mplayer also works poorly.I have:
xorg-server-1.7.4 (which equal 2:1.7.4-2 in debian)
ffmpeg-0.5_p20373
so the lenny did something different
On 23:34 Thu 28 Jan , zenglanmu wrote:
> MPlayer SVN-r29796-4.4.2 (C) 2000-2009 MPlayer Team
>
> 正在播放 btdownload/ドキュメント太平洋戦争/第5集.被蹂躏的南方岛屿 莱特-菲律宾.avi。
> No matching VOBSUB language found!
> 检测到 AVI 文件格式。
> [aviheader] 找到视频流，-vid 0
> [aviheader] 找到音频流，-aid 1
> VIDEO: [DX50] 720x480 24bpp 30.000 fps 999.0 kbps (121.9 kbyte/s)
> SUB: Could not determine file format
> 不能加载字幕：btdownload/ドキュメント太平洋戦争/第5集.被蹂躏的南方岛屿 莱特-菲律宾.sub
> ==========================================================================
> 打开视频解码器: [ffmpeg] FFmpeg's libavcodec codec family
> 已选视频编解码器: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
> ==========================================================================
> ==========================================================================
> 打开音频解码器: [mp3lib] MPEG layer-2, layer-3
> AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)
> 已选音频编解码器: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
> ==========================================================================
> AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
> 开始播放...
> [mpeg4 @ 0x106cfed0]Invalid and inefficient vfw-avi packed B frames detected
> 电影宽高比为 1.50:1 - 预放大到正确的电影宽高比。
> VO: [xv] 720x480 => 720x480 Planar YV12
> A: 3.1 V: 2.2 A-V: 0.948 ct: 0.000 66/ 66 99% 10% 13.7% 50 0
>
> ************************************************
> **** 你的系统运行太“慢”，播放不了! ****
> ************************************************
> 可能的原因、问题和变通的办法：
> - 最常见的原因：损坏的或有漏洞的 _audio_ 驱动
> - 试试 -ao sdl 或使用 ALSA 的 OSS 模拟方式。
> - 尝试使用不同的 -autosync 的值，不妨从 30 开始。
> - 视频输出运行慢
> - 试试 -vo 用不同的驱动（参见 -vo help 以获取驱动列表）或者试试 -framedrop！
> - CPU 运行慢
> - 不要试图在运行慢的 CPU 上播放大容量的 DVD/DivX！试试 lavdopts 中的一些选项，
> 例如：-vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all。
> - 文件损坏
> - 试试组合使用 -nobps -ni -forceidx -mc 0 这些选项。
> - 媒体读取慢（NFS/SMB 挂载、DVD、VCD 等设备）
> - 试试 -cache 8192 选项。
> - 你是否在用 -cache 选项播放一个非交错合并的 AVI 文件？
> - 试试 -nocache 选项。
>
>
> BYTEmark* Native Mode Benchmark ver. 2 (10/95)
> Index-split by Andrew D. Balsa (11/97)
> Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
>
> TEST : Iterations/sec. : Old Index : New Index
> : : Pentium 90* : AMD K6/233*
> --------------------:------------------:-------------:------------
> NUMERIC SORT : 321.48 : 8.24 : 2.71
> STRING SORT : 28.035 : 12.53 : 1.94
> BITFIELD : 4.1789e+07 : 7.17 : 1.50
> FP EMULATION : 18.461 : 8.86 : 2.04
> FOURIER : 4448.6 : 5.06 : 2.84
> ASSIGNMENT : 6.0211 : 22.91 : 5.94
> IDEA : 1419.4 : 21.71 : 6.45
> HUFFMAN : 445.29 : 12.35 : 3.94
> NEURAL NET : 6.0881 : 9.78 : 4.11
> LU DECOMPOSITION : 98 : 5.08 : 3.67
> ==========================ORIGINAL BYTEMARK RESULTS==========================
> INTEGER INDEX : 12.202
> FLOATING-POINT INDEX: 6.310
> Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
> ==============================LINUX DATA BELOW===============================
> CPU :
> L2 Cache :
> OS : Linux 2.6.31.4
> C compiler : mips64el-unknown-linux-gnu-gcc
> libc :
> MEMORY INDEX : 2.584
> INTEGER INDEX : 3.444
> FLOATING-POINT INDEX: 3.499
> Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
> * Trademarks are property of their respective holder.
ri...@happyleptic.org
> Just some compare,gentoo on my yeeloong achieve 30 fps on running
> glxgears,and mplayer also works poorly.I have:
> xorg-server-1.7.4 (which equal 2:1.7.4-2 in debian)
Same fps on my gentoo, using xorg-server 1.6.5
I also noted that the supplied "loonux" X11 was much
faster, I though it was because it used 16bpp. But as apparently
it's something different I'm becoming curious as well.
Wu Zhangjin
Perhaps loonux has the optimized decoder? any explanation from "Chen
Jie"? how can we make the decoder work on the latest debian or the other
distributions?
Regards,
Wu Zhangjin
Wu Zhangjin
> loonux has a optimized siliconmotion driver and some optimized
> decoders (shipped with mplayer)
Any documents(installation instructions) and download links please!
> 2010/1/29 Wu Zhangjin <wuzha...@gmail.com>
ri...@happyleptic.org
> I also noted that the supplied "loonux" X11 was much
> faster, I though it was because it used 16bpp. But as apparently
> it's something different I'm becoming curious as well.
Never mind, loonux uses 16bpp...
16bpp is also much faster on gentoo.
Michael Heide
> On Fri, 2010-01-29 at 11:07 +0800, Chen Jie wrote:
> > loonux has a optimized siliconmotion driver and some optimized
> > decoders (shipped with mplayer)
>
> Any documents(installation instructions) and download links please!
The SiS/XGI driver for Fuloong2F in Lenny must be optimized too... but... I'm using the one from debian.org!? (gobsmacked)
I replaced Mplayer 1.0~rc2-17.lemote.r01 with 1.0~rc2-17+lenny3 and it gets slower. At least a little. Still faster than the one in Squeeze.
Still glxgears in lenny is 130FPS while in squeeze is 30FPS, but the one in squeeze is smooth and the one in lenny stutters. So maybe it's a "glxgears is NO benchmark" thing, maybe glxgears baldly behaves different and you cannot count on it.
gtkperf is faster in Squeeze, but it seems this is because gtk is newer and faster with squeeze, because GtkDrawingArea Tests are faster in Lenny.
I also did some x11perf testing, see attachment.
Conclusion: here sometimes lenny and squeeze are on par and sometimes lenny is faster, with ShmPutImage lenny is much faster!
And remember: In both OSes, squeeze and lenny, I use the standard xorg / debian.org SiS/XGI driver.
Regards
Michael
ri...@happyleptic.org
On a stock debian lenny, siliconmotion driver version is 1.6, while
on the loonux it's 2.2. Also, on gentoo there seams to be nothing more
recent than 1.7.
So, where does this 2.2 version come from ?
BTW, I tried to compile it on gentoo (got it with apt-get source) but the
module does not work (complains about "V_BIOS").
ri...@happyleptic.org
> So, where does this 2.2 version come from ?
Hum, looks strange.
Under loonux I have :
(II) Module siliconmotion: vendor="X.Org Foundation"
compiled for 1.4.2, module version = 2.2.8
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 2.0
So 2.2.8 apparently.
Then I got and recompiled siliconmotion driver, and with it I have :
(II) Module siliconmotion: vendor="X.Org Foundation"
compiled for 1.6.5, module version = 1.6.0
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 5.0
So I abviously fetched the wrong one, although my source-list
only source line is "deb-src http://dev.lemote.com/debian testing main".
I'm puzzled :-(
ri...@happyleptic.org
(latest version there is 2.2.8).
The problem is : smi_video.c now contains many functions that have
inline assembly, for... intel MMX instruction set ! :-D
I suppose it's because Lemote in addition to paying a MIPS
license also felt the need to pay a license to Intel (last loongson
CPU are said to be x86 compatible...)
Ruan Beihong
And current chip DO have some addition instructions which are very similar to MMX and SSE. But the document is not so easy to find, and the work on it is hardly seen, even its C interface is fully supported by GCC.
--
You received this message because you are subscribed to the Google Groups "loongson-dev" group.
To post to this group, send email to loongs...@googlegroups.com.
To unsubscribe from this group, send email to loongson-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/loongson-dev?hl=en.
--
James Ruan
Zhang Le
> Ok, I finaly found siliconmotion drivers by hand on dev.lemote.com
> (latest version there is 2.2.8).
>
> The problem is : smi_video.c now contains many functions that have
> inline assembly, for... intel MMX instruction set ! :-D
Sorry I didn't read this thread the other day.
AFAIK, The loonux's siliconmotion driver and mplayer are all optimized for
loongson using pure assembly.
> I suppose it's because Lemote in addition to paying a MIPS
> license also felt the need to pay a license to Intel (last loongson
> CPU are said to be x86 compatible...)
not really.
Just binary translation, i.e. translate x86 instruction to mips instruction.
If I understand it correctly, it still has a lot of differences comparing
with x86. E.g. interrupt, MMU, tlb, cache, so on and so forth.
Zhang, Le
Chen Jie
Chen Jie
Daniel Clark
> Ok, I finaly found siliconmotion drivers by hand on dev.lemote.com
> (latest version there is 2.2.8).
When an intern for the FSF Bernie was working on this, however he is
now on an OLPC XO deployment in Peru and has not had time to finish
the work; however these notes from him and Teddy may be useful, and if
anyone else is working on getting newer xorg working well on yeeloong
he may be able to share is in-progress work with you privately (he
didn't feel it was ready for public disclosure).
Also cc:ing Erik who may be interested in hacking on this (but won't
have hardware for him until late Feb probably).
If you are working on this tell me and I can get some other email
threads regarding bernie's work that may be useful together and put
somewhere public; the current situation is very confusing.
Bernie Innocenti <ber...@codewiz.org> writes:
This would be really useful to know. On dev.lemote.com, I've seen a
driver version 2.2.8, which seems to be a fork of the 1.6.x codebase
from freedesktop.org (the fd.o driver is now at 1.7.3).
The 2.2.8 driver contains plenty of changes, but it is hard to tell what
they do without looking at the history in git.
Teddy Wang <teddy...@siliconmotion.com.cn> writes:
Version 2.2.8 driver is modified by SiliconMotion. It's based on
1.5.1 freedesktop driver. You can refer to attached release note.
[Now up at http://docs.google.com/View?id=dcf76qpd_108f4x96td9 -DC]
Danny Clark <dcl...@pobox.com> writes:
See also: http://ur1.ca/l3a7 "Query about current situation about
lemote 2F Options"
(towards the end)
> The problem is : smi_video.c now contains many functions that have
> inline assembly, for... intel MMX instruction set ! :-D
>
> I suppose it's because Lemote in addition to paying a MIPS
> license also felt the need to pay a license to Intel (last loongson
> CPU are said to be x86 compatible...)
--
Daniel JB Clark | http://pobox.com/~dclark
ri...@happyleptic.org
> Not really. The compatibility is make by qemu and the chip provides
> additional instructions to facilitate it.
> And current chip DO have some addition instructions which are very similar
> to MMX and SSE. But the document is not so easy to find, and the work on it
> is hardly seen, even its C interface is fully supported by GCC.
You are right of course !
I hadn't read my Loongson2FUserGuide.pdf until these extended instructions
aparently :-) or never noticed how similar they are to the old intel MMX ones.
This all make sense now and seams much more interresting that what I initialy
though.
So now I am left to understand why the assembler rejected them ; unfortunaly
I managed to freeze my remotely accessed 8089 after "succesfully" running
lemote's siliconmotion 2.2.8 under my gentoo's xorg-server 1.6.5 (glxgears
reported a very slow framerate, but I was using 2.2.8-rc0, the one without
the MMX helpers for XV).
So, I will have to wait until monday now :-)
Anyway, what's the policy regarding such architecture specific optimisation
in mainstream xorg repository ? Is there any hope to merge this FastXv code
upstream ? Because if I have to choose I like upstream siliconmotion driver
code better (2.2.8 code seams less clear to me).
ri...@happyleptic.org
> threads regarding bernie's work that may be useful together and put
> somewhere public; the current situation is very confusing.
Well, I'm not going to work on cleaning the situation. More probably
I will end up with an ugly patch above xorg's siliconmotion that will
bring some of the acceleration of the siliconmotion 2.2.8 version.
I'm not into X11 development I just want my xterm to scroll faster :-)
I'm confident that others will make a good job of accelerating upstream
driver The Good Way.
ri...@happyleptic.org
- Fix xserver bug in fb so that silicon-motion driver 1.7.3 using XAA
works in 16bpp (you have to change a memcpy to a memmove in fb/fb.h)
-> xterm is now very fast, much faster than the linux console in fact. EXA
mode still hangs the computer, but I don't care that much about EXA (this is
going to be slower than XAA without fast compositing acceleration anyway).
- Import from siliconmotion's 2.2.5 driver the function to copy
plannar YUV from RAM to packed YUV into VRAM
-> mplayer can now play a full screen video on good quality
- Fix another minor bug in SM 1.7.5 again from copying from SM's 2.2.5
DisplayVideo function, so that the last lines of the video display are correct
(at least on the few mpeg I've tested).
The desktop is now very useable, but these patch need to be finalized
(for now they are just ugly hacks).
Next target will probably be MESA. 40 fps in glxgears is not acceptable
giving the hardware at hand.
This little machine rocks! :-)
刘世伟
Daniel Clark
Is this stuff in version control somewhere?
BTW, awesome! :-)
--
Daniel JB Clark | Free Software Activist | http://pobox.com/~dclark
Zhang Le
This is really awesome! This is why I love free software.
BTW, is there a patch? ;)
Is this all that's required to solve the problem?
Replacing memcpy in fb/fb.h by memmove.
I will try it later.
Zhang, Le
ri...@happyleptic.org
Not yet. The problem is that it's probably not how the bug
should be fixed. For the memcpy problem, we perhaps should
change the check in btBlt to avoid using the fastpath using
memcpy when the segments overlap (since memcpy is faster
than memmove).
A patch for siliconmotion 1.7.3 is available in the bug trackers
at freedesktop.org, but a better one will be available monday.
Still, it lacks the most interresting part : the MMX pack function,
which should not be implemented there but probably either directly
in Xv or in pixman (and make Xv use pixman).
So for now the simpliest is to fix these manually.
For the impatient I attach a patch against SM 1.7.3
With it, 16bpp and AccelMethod = "XAA" works quite well.
> BTW, awesome! :-)
Just an ugly hack really.
刘世伟
loongson@yeeloong:~$ mplayer -benchmark -nosound -vo xv Flack.avi
no loongson2f patch:
BENCHMARKs: VC: 132.980s VO: 121.602s A: 0.000s Sys: 12.882s = 267.465s
BENCHMARK%: VC: 49.7188% VO: 45.4648% A: 0.0000% Sys: 4.8164% = 100.0000%
loongson2f patch:
BENCHMARKs: VC: 128.548s VO: 42.528s A: 0.000s Sys: 5.600s = 176.676s
cristian paul peñaranda rojas
Zhang Le
I have tried it. It works.
However this definitely does not qualify as a proper fix.
Further investigation need to be done.
One thing to note though:
It is xorg-server which has fb/fb.h.
So two packages to rebuild:
xorg-server and xf86-video-siliconmotion
I have make new ebuilds. However gentoo-cn.org has some problems.
I will publish them asap.
Zhang, Le
ri...@happyleptic.org
> I have tried it. It works.
> However this definitely does not qualify as a proper fix.
> Further investigation need to be done.
Aparently from the x11 mailing list, it was actually a bug since
the two regions _are_ allowed to overlap.
I've not looked closer at this issue since then, taking for granted
that the original author was about to commit a fix.
It's easy to imagine in what situations this memcopy will produce
garbage pixel colors in 16bpp, but I can't understand how this could
result in such hangs.