本站搜索
页面
分类
最新评论
- Lancer 发表于《写在KDE 4.5发布之后》
- liangsuilong 发表于《写在KDE 4.5发布之后》
- Lancer 发表于《写在KDE 4.5发布之后》
- liangsuilong 发表于《写在KDE 4.5发布之后》
- Lancer 发表于《写在KDE 4.5发布之后》
Linux
朋友们的blog
- A Thousand Mile
- apt-blog.net IT民工养成计划 PT博客
- Blinux
- CoffeeCat
- DCY--IT路上……
- DY Feng's Blog 叶毅锋的博客
- Felix's Blog
- HeliumCity The future, in the freedom.
- I’m TualatriX
- Jia Pad
- K.I.S.S. – 简单哲学
- Knowledge == Language
- sychopx
- Yayi's Word
- 七星庐
- 写真と嵐とヒマワリの旅人
- 小杰的博客
- 心之所在的日志
- 歪歪灰主流
- 毛毛's Blog
- 稳 – 不信未作牺牲竟先可拥有 只相信是靠双手找到我欲求
- 读书写字看风景
- 追梦
- 阳光灿烂的日子
-
最新日志
Tag Cloud
按标签归档:Debian
手动制作Debian的linux-kbuild包
之前的牢骚文发了,我也已经等待很久了,Debian的linux-kbuild-2.6.33还是不愿意出来,倒是linux-kbuild-2.6.34则在和内核一起发布。看样子2.6.33内核会被Debian放弃了。所以还是要自己动手,丰衣足食,自己打个linux-kbuild-2.6.33的deb包出来用。具体的做法我是参考这篇文章的:http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage 首先到Debian的SVN抓取一份源代码: svn co svn://svn.debian.org/kernel/dists/trunk/linux-kbuild-2.6 下载一份完整的内核源代码包,注意不要下载2.6.x.y版本,而是下载2.6.x的版本,比如2.6.33内核: wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.tar.bz2 进入linux-kbuild-2.6目录,然后生成一份经过debian化linux-kbuild的源代码(补充:生成orig吧之前,需要到debian/changelog查看其版本号,如果生成的linux-kbuild比changelog上的版本要旧,则需要把前面版本的changelog删除掉,然后添加上现有版本的changelog。直接加在最新版本前的话就会后面会引起错误,虽然不影响打包。如果比changelog的要新,则自行加上即可。): ./debian/bin/genorig.py ../linux-2.6.33.tar.bz2 cd .. 解压orig源码包: tar xzf orig/linux-kbuild-2.6_2.6.33.orig.tar.gz 进入解压后的目录,把linux-kbuild-2.6目录内的所有东西复制到linux-kbuild-2.6-2.6.33 cd linux-kbuild-2.6-2.6.33/ cp -a ../linux-kbuild-2.6/* ./ 生成control文件,然后编译,如果需要的话当然要修改一下: ./debian/bin/gencontrol.py dch -i 清理目录,检查编译依赖以后,就可以生成deb: make -f debian/rules clean dpkg-checkbuilddeps dpkg-buildpackage -us -uc 最后返回到上层目录安装linux-kbuild-2.6.33的deb包即可。安装结束后,也就可以安装linux-headers,随后就可以在新内核上编译第三方内核模块。
linux-kbuild:Debian你该放手了吧!
一直以来,Debian的Sid分支和Experimental分支均以大胆著称。因为社区庞大,很多软件源代码一发布Sid或者Experimental。因为Sid分支是源源不断地更新和开发的,软件库内的软件基本都是最新的。Experimental还会存放着技术预览版的软件,基本能够满足版本控的需求了。 但是在2.6.33内核上,Debian似乎有点迟疑了。虽然linux-image-2.6.33和linux-header-2.6.33很早就出来放在experimental仓库了。linux-image也很容易安装,但是linux-header则是无法安装,因为linux-kbuild-2.6.33还没有出来。这种情况已经有好几个月了,也有maintainer在埋怨,可是一直没有进展。 看了linux-kbuild的简介,这个软件包的用处在于为kbuild框架提供内核的头文件支持。作为内核头文件的一部分,我一直觉得这个软件包大可以并入到linux-header里面。虽然这样可能增加linux-header维护者的负担,但是对于其他依赖内核头文件编译内核模块的软件包而言,则少了很多测试时间。 对比大部分基于Debian的Linux发行版,它们大部分都已经没有linux-kbuild这个软件包了,或许是并入了linux-header,或许是被更名了。总而言之,linux-header也不再依赖其他软件包,仅仅依赖于linux-image。因此Debian也可以借鉴这种做法。 也许是为Squeeze冻结的需要,Debian的内核和Xserver都好像被冻结了一样,内核长期固定在2.6.32,而Xserver一直在1.7的分支上更新,现在最新的版本是1.7.7。Xserver和内核不一样,现在无论是Sid和Experimental还是难觅Xserver 1.8的踪影。看来Squeeze的冻结已经开始,今年内应该会面世了。 无独有偶,RHEL 6、Ubuntu 10.04 LTS和Debian 6一道共同使用2.6.32内核和Xserver 1.7,是天作之合还是偶然默契,真是令人难以捉摸! 在Debian官方用户论坛发过帖子:http://forums.debian.net/viewtopic.php?f=19&t=52019,似乎也是没有什么回应哦!看来应该发去邮件列表实际一点。
VirtualBox的2D视频加速测试
VirtualBox在3.1.0的版本引入了一项新特性,2D视频加速。这项特性的目的是让虚拟机内的视频提速起来,即使高清影片,播放起来也会十分流畅。 要说起这个VirtualBox 2D视频加速用的是什么原理,和Mike在推特上讨论了好一阵子它的原理,。我一直以为VirtualBox可以调用实体显卡进行硬件解码,从而可以减轻虚拟CPU的运算负担。其实不然,VirtualBox只是把视频播放中的画面渲染这个步骤,通过特殊的通道把GLX指令转发到实体机系统上进行渲染。这种办法的好处在于不再需要担心虚拟机羸弱的虚拟显卡性能,即使性能不足,也可以流畅地在虚拟机内播放视频。然而视频音频的解码依然需要由虚拟CPU完成。如果虚拟CPU性能不足,在播放高清影片的时候依然会导致掉帧卡机的情况。实际上这也没有办法之中的好办法,起码不会因为虚拟显卡的性能不足而导致画面渲染不连续。 先来测试效果,还是用着学校的老电脑:AMD 4200+,4GB RAM,8600GT显卡,1TB硬盘。实体机的操作系统是Fedora 12 x86_64。而虚拟机配置是双核心虚拟CPU,1GB RAM,128MB显卡。虚拟机系统为Windows XP。播放器是splayer,测试片源为北京奥运开幕式NBC的720P H.264版本。VirtualBox是3.1.6。 在虚拟机内,有着双核的带动,软解压720P的影片似乎不甚吃力,CPU使用率一般都在40%附近。进行其他操作很容易让CPU使用率突然飙升,这在虚拟机倒是十分平常的事情。即使全屏播放,也十分流畅。最大最小化和全屏之间的切换也十分平滑,没有拖泥带水。 不过当时因为时间仓促没有测试关闭2D视频加速的效果,回到家里的Debian Unstable,却是打开不了这个选项。回去再看看Fedora 13,则是可以启用2D视频加速。试试在Debian里编译mesa-7.9,更新以后,也可以了。或许是这项特性需要的是OpenGL 2.0或者以上的支持吧。因为HD3650在mesa-7.7.1还只有OpenGL 1.5,而OpenGL 2.0则是要到mesa-7.8以后的版本。 在家里电脑的测试中,虚拟机内存还是1GB,同样的片源在开启2D视频加速还算流畅,CPU使用率比学校的电脑高了不少,这应该和OpenGL的性能有关,毕竟mesa驱动的性能和NVIDIA专有驱动要慢不少。另外还有一个原因就是家里的E2160是没有VT的,只能在虚拟机内使用一个内核,这也是制约解码性能的一个重要因素。 至于关闭了2D视频加速的情况则有点惨不忍睹了,视频播放感觉不流畅,而且CPU长期处于90%的状态,看来软解压不怎么行了,况且虚拟CPU还需要负担图形界面加速和画面渲染的工作,有点负担不过来了。 VirtualBox的2D视频加速有点让人失望,正如前文所说到的,不能应用GPU的硬解码。而且本身虚拟显卡在安装了增强功能包以后也有一定的2D加速能力,只要虚拟CPU性能足够强劲,解码器也足够地省资源,在虚拟机内播放视频还是很流畅的。不过在播放高清视频的时候,虚拟CPU已经需要负担沉重的食品解码任务,若是再承担画面渲染和2D图形加速则会应付不来。早前听网友说如果没有这项特性的确会让虚拟机全屏和最大最小的切换中导致影片播放不流畅的情况出现。看起来,这个特性还不是一无是处的,至少能够确保视频播放不会因为画面渲染性能问题而导致的不流畅出现。从这个特性也可以说明,视频加速是通过OpenGL实现的,并非实体GPU硬解码特性实现的。在老一点的显卡上,只要有OpenGL 2.0的支持,要实现虚拟机内的视频加速,也是可以的。只是能够加速多少,则取决于实体显卡的OpenGL 2.0性能了。这在Linux里面,驱动很影响一切的。 要想在虚拟机内引入GPU硬件解码并不是一件容易的事情,因为各家GPU厂商实现GPU硬件解码的办法都不一样,要做起来会十分困难。或许Xen的一个做法可以值得考量。利用IOMMU直接访问实体显卡,从而让GPU的所有特性都能应用在虚拟机内,包括3D加速、GPU解码甚至是GPU通用运算等。当然Gallium3D也具备OpenCL通用运算特性,若是把这项特性应用到虚拟显卡中,则能够进一步让视频解码提速。 补充测试,今天回到学校,还是用回4200+的电脑,测试了一次关闭2D视频加速的情况。打开720P的视频,虽然不算卡,但是CPU使用率已经达到了60%附近了,提高了近一倍。如果把播放最大化或者全屏播放,出乎意料的是虽然CPU使用率还是60%附近,但是视频则变得异常不流畅,比一台四五年前的老电脑更卡。这样看来要有强劲的CPU进行解码还不行,或许这个视频加速还需要有显卡的OpenGL加速才足够呢。
