高版本号的内核是否已经集成 amd 显示卡驱动
4月 最新发布的 amd 官方驱动仍然无法在新内核上工作,有一点感觉,就是新内核不需要另外安装驱动似乎已经有 amd 官方驱动的一些特性,安装了官方驱动反而显示变得非常慢。 我的C-50小本上现在各个系统里的内核分别有3.1,3.2和3.3的。反正我是早已完全试用开源驱动了。而去年的时候,不装官方驱动还根本没法用。随着内核不断升级,也能感受到显示性能的提升,不知道其他A卡的情况。 内核里面的驱动是字符界面下的帧缓冲驱动,图形界面的驱动是单独的。 好深奥。radeon和mesa跟内核版本没有关系么? 原帖由 绿色圣光 于 2012-4-27 15:16 发表 http://forum.linuxfans.org/images/common/back.gif好深奥。radeon和mesa跟内核版本没有关系么?
有些关系的。 原帖由 绿色圣光 于 2012-4-27 03:16 PM 发表 http://forum.linuxfans.org/images/common/back.gif
好深奥。radeon和mesa跟内核版本没有关系么?
一点点关系,内核里面的 drm(还是dri忘了) 驱动模块用于显卡硬件的接口通讯,但主要的功能实现在显卡驱动上,mesa是opengl库,xf86-driver-ati 才是真实的 X 驱动本体。
实现 3D ,这三个东西缺一不可。 正确的说应该是:
kernel-drm-3.1.10-1mgc25.i686
xorg-x11-drv-ati-6.14.3-10.20120206git36c190671mgc25.i686
mesa-libGLU-7.11.2-1mgc25.i686
mesa-libOSMesa-7.11.2-1mgc25.i686
mesa-libGLU-devel-7.11.2-1mgc25.i686
mesa-dri-filesystem-7.11.2-1mgc25.i686
mesa-dri-drivers-dri1-7.11.2-1mgc25.i686
mesa-libGL-7.11.2-1mgc25.i686
mesa-libGL-devel-7.11.2-1mgc25.i686
mesa-libEGL-7.11.2-1mgc25.i686
mesa-libEGL-devel-7.11.2-1mgc25.i686
mesa-dri-drivers-7.11.2-1mgc25.i686
mesa-libGLES-7.11.2-1mgc25.i686
mesa-libGLES-devel-7.11.2-1mgc25.i686
mesa-libOSMesa-devel-7.11.2-1mgc25.i686
闭源驱动使用自带的 opengl 库,并不使用 mesa,某些 Linux 游戏也是不认 mesa 的。
mesa 和 xorg-x11-drv-ati 相比起来 mesa 可能更重要一些,mesa 直接编译了对 amd 及其它显卡的硬件加速支持,并不是 xorg-x11-drv-ati 的作用,xorg-x11-drv-ati 只是提供了图形卡驱动。
现在的驱动不能用于新内核,很可能相应要变动挺多东西。我编译过几次内核,完全可以排除是内核补丁、编译环境的影响,的确是内核实现有了变动。在旧版内核启动系统时 splash 动画是显示器最高分辩率,是不会切换到适合运行的分辩率的,但新内核或者旧内核安装完闭源驱动时会。
所以我怀疑新内核里面已经包含了一些开放的 AMD 驱动,同时也导致不能安装官方驱动。
AMD 显卡的 3D 支持 kernel mesa xorg 都有影响。 我记得闭源驱动某些不支持的gl扩展可以用mesa的库进行支持,也就是同时使用两个库。 原来如此 启动的 splash 是帧缓冲的。和图形界面的没关系。
而且我记得之前的帧缓冲一直没有用显卡专用的帧缓冲驱动,而是统一使用了vesa通用驱动,也就是vesafb。我之前也没有特别研究如果实现多种显卡的自动进入对应帧缓冲驱动的效果。我当时弄fbsplash时,mgc很多用户还在汇报CRT显示器刷新率的问题呢(帧缓冲驱动会进入显示器支持的最高分辨率模式,CRT 上面最高分辨率的刷新率会很低)。现在全都是液晶了,应该可以考虑自动进入适合分辨率的功能,也就是可以启用显卡自己的帧缓冲功能了。
图形界面和字符界面分辨率一样的情况下,如果你是用的radeonfb这个帧缓冲驱动,配合xorg-driver-ati可以实现不切换分辨率的启动图形界面。启动过程的显示感受很好。
逻辑上来说,内核里面的 drm 驱动应该是 mod 方式而不能直接编译进入内核。因为这个东西会和官方驱动的内核模块相冲突。不过具体会不会冲突我没试过。
貌似没有进入图形界面时,只要不载入drm的ati部分模块就不会引起fglrx的问题。如果图形界面是ati驱动,貌似会自动载入不需要特别进行载入。
进入帧缓冲驱动的一个问题就是 splash 不能针对固定的某个分辨率进行设计了。这个问题没有美工很难搞。而且启动脚本也要有考虑。
splash的问题还是先等sejishikong搞定3.0基础环境后再说吧。 splash 没问题,3.0 的 32 位基础环境已经出来了,只是我机器上 VBOX 没法安装。
应该和 drm 无关吧,相同参数一个内核可以而另一个内核不可以说得过去么? kernel里的是kms,就是把原来x的一些东西移到了kernel,可以加速显示及在启动阶段支持更多的分辨率,坏处是可能对x的驱动有影响。 kms 是同时需要字符界面和图形界面的驱动配合的。用官方驱动进入图形界面还是需要 setmode 一下的。 言下之意就是去掉 kms 支持就可以解决官方驱动更慢的毛病? 逻辑上这两个东西似乎确实差不多应该是有冲突。
但问题是你如果去掉那么似乎可能大概差不多应该会让一部分人用不了图形界面。
这东西开源驱动需要,但官方驱动不需要。
页:
[1]
2