momo zone

调核人的blog

Monthly Archives: 十一月 2010

X remote display,XDMCP ,XFS

让X 客户端程序出现远程X 服务器端有两种方法:

1.

先在远程主机 export DISPLAY=<X SERVER IP>:1

然后在本地启动X 服务器:Xephyr -ac -screen 800×600 :1 ,其中-ac表示是允许任意X 客户端程序连接。相当于先执行了xhost +

更优越的一个方法是vi /etc/sysconfig/displaymanager 编辑:

DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN=”yes” 让X;0 可以监听X 客户端程序的请求。

最后在远程执行X 客户端程序。

2. 使用XDMCP 可以将整个远程桌面显示到本地 X Server端上,每种Display Manager 的配置都是不一样的,这里以kdm为例,步骤如下

(1)修改X访问权限 : /etc/X11/xdm/Xaccess, 修改以下(这样会让所有访问客户获得权限):

#* # any host can get a login window

去掉#:

* # any host can get a login window

openSuSE 默认已注释。

(2)vi /etc/sysconfig/displaymanager

修改如下:

DISPLAYMANAGER_REMOTE_ACCESS=”yes”

DISPLAYMANAGER_ROOT_LOGIN_REMOTE=”yes”

(3)vi /usr/share/kde4/config/kdm/kdmrc

[Xdmcp]
# Whether KDM should listen to incoming XDMCP requests.
# Default is false
Enable=false

注释掉这个。

(4)Xephyr -query 192.168.3.114 -screen 1280×1024 :1

这里启用的是查询模式,也就是向指定ip的机器问讯:是否有需要把桌面发到本地X server?

另外还有-broadcast 广播模式:

X server 大声喊一下“哪个ip的机器想把桌面发到我这里” ,远程机回复道:“我这里有” ,X server 把这个远程机的ip显示出来,并在用户选择后接受远程机的请求。

补充一下远程字体服务:

在X server启动参数中加上

-fp tcp/192.168.3.114:7100

可以调用远程xfs字体。别忘了先到/etc/X11/fs/config 注释掉 #no-listen = tcp

如果是在X:0中可以用xset fp= tcp/192.168.3.114:7100更改默认的fontpath (注意fp=后面的空格)

然后用xset q查看:

Keyboard Control:
auto repeat:  on    key click percent:  0    LED mask:  00000000
XKB indicators:
00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
03: Compose:     off    04: Kana:        off    05: Sleep:       off
06: Suspend:     off    07: Mute:        off    08: Misc:        off
09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
12: Group 2:     off    13: Mouse Keys:  off
auto repeat delay:  200    repeat rate:  25
auto repeating keys:  00ffffffdffffbbf
fadfffefffedffff
9fffffffffffffff
fff7ffffffffffff
bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
acceleration:  40/10    threshold:  4
Screen Saver:
prefer blanking:  yes    allow exposures:  yes
timeout:  0    cycle:  600
Colors:
default colormap:  0x20    BlackPixel:  0    WhitePixel:  16777215
Font Path:
tcp/192.168.3.114:7100
DPMS (Energy Star):
Standby: 1200    Suspend: 1800    Off: 0
DPMS is Enabled
Monitor is On
Font cache:
Server does not have the FontCache Extension
关于linux 字体渲染的途径有下面的一段小文章可以参考一下

一个字实际上就是一个小图,如果小图上的点非黑即白,就称为黑白点阵;
如果小图上的点可以有不同的亮度甚至颜色,则称为AA点阵。每个字,也就
是每个小图都有固定的编号,编辑器(client)可以只告诉server某个编号,
server根据该编号去找出对应的小图,这种方案就是所谓的server side
font,如FreeType,X-TrueType等backend就属此类;如果编辑器自己去找小
图,干脆把小图送给server去显示,这种方案就是所谓client side font,
Xft属这一类。
server side font
FreeType backend: 即XF86Config中的freetype模块
X-TrueType backend: 即XF86Config中的xtt模块
client side font
Xft: 设置文件是fonts.conf

还有一类,xfs,跟server side font一样,client把字编码传给server,但
server并不直接从字库中读出对应该编码的小图,而是把编码再传给另外
的所谓font server,由font server去字库找出对应的图,返回给X server
去显示,姑且将这种方式称为font server font:
font server font
xfs: 设置文件是X11/fs/config

不管是哪一类,最终都要去字库文件读出对应编码的小图,至少对TrueType
格式的字库文件而言,xtt也好,freetype也好,Xft也好,几乎都用到了
FreeType这一字库engine,虽然xtt没人继续改进,还是用FreeType 1,别人
都改用FreeType 2了。正因为大家都用FreeType字库engine,使得xtt,
freetype,Xft这些名字容易弄混,让人头大。解决的办法很简单:不要再去
管什么xtt,不要再去管什么freetype,不要再去管什么xfs:
只要弄清Xft就够了。

GT5… 终于出了

GT5 差不多快成了 永远的GT赛车 ,本月已经被偷跑,IGN给了8.5分,比NFS14 还低… 算了,分数无法衡量GT这类擬真驾驶游戏。这次GT5正式版最令人感到奇怪的是片头没有采用那首经典的moon over the castle ,而是变成了朗朗弹钢琴+摇滚,钢琴曲目是piano sonata no.6 in A major op.82 作曲家:普罗科菲耶夫 Sergei Prokofiev片头画面介绍了汽车的基本制造过程,还是很有魄力的。
http://player.youku.com/player.php/sid/XMjI1MjA1OTU2/v.swf
 

X window变革之我见

X window 及实现经历了20多年的历史了,虽然古老但仍然是unix/linux的唯一GUI系统。在基本架构不变的情况下,X window 的功能和性能发生了天翻地覆的变化,从严谨的C/S架构,点阵位图绘图方式,到GLX图形支持,再到direct rendering以及GPU渲染。从依赖多个系统(udev)获得输入输出设备到自己掌握硬件检测和配置。从服务器端字体渲染到客户端字体渲染。看起来好像X window的发展正在背离当初设计时的理念,最近关注的wayland 就是这种发展的一个新里程。

纵然由于桌面性能的贫弱,linux 不得不把改进桌面性能作为一个十分重要的任务 ,但不能把自己的一些重要特征丢失,那就是C/S架构。

在windows的平台上,虚拟化要求程序执行的环境无关化,citrix 是在这方面走的比较早的一个厂商。他的核心技术是利用MS的RDP协议将窗口独立出来,仔细想一下这不就和X Server达到的远程client显示的效果一样吗?而且X Server是原生的,windows平台下基本都是第三方方案(MS TS 除外)。X window的原生远程显示仍然十分出色,现在给人们展示这些技术也十分令人惊艳(RDP能显示视频吗?当然,X需要大量带宽和Xv支持),谁能想到这个是在1984年就实现了。

这样看一下linux平台的桌面发展道路和windows的是走的相反的,各自朝各自的反方向走。这真是有趣的情景,希望各发行版以后把wayland集成 进去的同时也保留Xorg的实现,当然也希望Xorg能一直走下去,持续改进。

linux 中断处理及软中断

LDD3 中讲解中断部分的还是太简单了,尤其是后半部的很多背景知识没有涉及,这里再说一下:

LDD3中后半部的处理使用的是tasklet和工作队列。

后半部的说法其实已经过时(2.2时代的),2.4以后成为软中断(softirq)机制,而软中断是内核线程中的一个(由ksoftirqd调度)… 扯远了…

软中断最大可以注册32个,也有多种服务类型,tasklet是其中的一个,另外还有其他用于高分辨率定时器,网络发送接受等等。

所以如果对于一般性中断处理而言过程是这样(时钟中断除外)的:

irq ==> softirq ==> tasklet ==>task queue

上图可以看出, ksoftirqd 是一个后台运行的内核线程,它会周期的遍历软中断的向量列表,如果发现哪个软中断向量被挂起了( pend ),就执行对应的处理函数,对于 tasklet 来说,此处理函数就是 tasklet_action ,这个处理函数在系统启动时初始化软中断的就挂接了。
Tasklet_action 函数,遍历一个全局的 tasklet_vec 链表(此链表对于 SMP 系统是每个 CPU 都有一个),此链表中的元素为 tasklet_struct 。此结构如下 :
struct tasklet_struct
{
struct tasklet_struct *next;
unsigned long state;
atomic_t count;
void (*func)(unsigned long);
unsigned long data;
};
每个结构一个函数指针,指向你自己定义的函数。当我们要使用 tasklet ,首先新定义一个 tasklet_struct 结构,并初始化好要执行函数指针,然后将它挂接到 task_vec 链表中,并发一个软中断就可以等着被执行了

工作队列不属于软中断,他工作在进程上下文,和软中断最大的区别是可以睡眠。

opensuse s2rom,alsa issue

1. suspend to ram 命令参数 :s2ram -f -s(HP DV5), s2ram -f -a 3(asus P5B)

2.alsa服务有个bug,启动时自动静音,用alsactl store 可以恢复默认混音器设置。

关于GLX direct和indirect rendering

今天看了一下wiki才发现之前很多理解上的错误,是否支持3D图形和direct ,indirect rendering 没有任何关系。事实上它与3D硬件加速也没有关系。

3D支持需要openGL实现 — Mesa or 厂商自己驱动。

In-direct rendering: 在dri 出现之前其实3D绘图都是in-direct。遵循经典的X server/client 模型,X server掌控实际的绘图工作,3D绘图信息在X server和client之间频繁传递,但这样也有一个好处 ,3D图形仍然可以通过网络传输。传统的GLX就是这样工作的。直到DRI的出现,引入了direct rendering。另外,如果使用indirect rendering ,glx extensions会少一些,部分也有变化。强制indirect rendering的方法是export LIBGL_ALWAYS_INDIRECT=1

direct rendering :把X server绘制图形的功能转由X client来做,Xclient 直接在screen上绘图。减少glx protocal 传输大量绘图指令带来的延迟和同步问题。

ATI-STREAM

最近好像找到买高端显卡的理由了(对我而言,PC game 没有意义)。

1,看x264 高清虽然cpu够了,但高达40%-80%的负载实在是不能干其他事情了(尽管我不会一边看视频一边工作)。这点NV有自己的全套方案(NV驱动绕过了Mesa,DRM),安装闭源驱动然后装打过vdpau补丁的mplayer就可以了,可惜效果比较差,8400MGS竟然还不如凑来的VAAPI为后端的libva+ HD4650快,我现在真的在怀疑论坛上贬ATI linux 驱动噩梦的人到底有没有用过4系或5系的闭源驱动。

2,浏览器的GPU加速开始进入实用阶段,用ie testdriver 里的程序对比了一下,感觉差距不是一般的大。这方面8400MGS 小胜 HD4650。

3,可以用来搞搞GPU编程(CUDA or ATI Stream),当然也可以用来干坏事破解密码(WPA每秒7000Key 和50000Key的差距)。两种编程模式两个风格,ATI 比较推OpenCL(有intel参与的,已成为通用计算的标准),NV 推自家的CUDA,现在也开始搞OpenCL,那么将来CUDA 会是什么下场?另外抛开开发的问题,性能的差距实在太大了,5970甩开GTX480 几条街,就算是单芯5870也超GTX480不少。
接下来谈一下GPU编程 – ati 流计算技术

引言: 随着GPU的并行处理能力的不断提升,GPU的特性被不断的应用于图形无关的应用中,并获得了非常大的速度提升。大量的应用开始工作在GPU上,而不是利用多核CPU进行加速。类似于光线跟踪,光子映射等开销很大的计算都可以在GPU上达到静实时的性能。 本文介绍了ATI流计算的一些基础知识,对于CAL,Brook+或者OpenCL有兴趣的朋友,可以看看。

正文: ATI流计算模型: ATI流计算模型包含了一套软件系统以及ATI流处理器。下图展示了ATI流处理模块之间的关系:

ATI流计算软件为客户端用户提供了一个灵活完整的接口,从而使开发人员充分利用ATI的硬件特性进行流计算。 软件主要分为下面几个模块: 编译器: 类似于Brook+的编译器,把Brook+内核的代码编译成为独立的C++文件以及IL代码。 流处理器的设备驱动: ATI流计算抽象模型(CAL)。 性能分析工具: Stream KernelAnalyzer,可以及时编译Brook+,IL代码,并且分析程序性能。 性能库: AMD核心数学库(ACML),这部分是专用于特定领域的。 在最新一代的ATI流处理器中,编程模型应用一种通用的Shader语言。可编程的流处理器可以执行用户指定的各种程序,这些程序被称为内核函数(Kernel)。这些流处理器可以以一种单指令多数据(SIMD)的形式执行一些与图形完全无关的任务。这种编程模型被称为流计算,内存中存储的大量相同类型的数据可以被分配到不同的SIMD引擎中进行处理,从而生成输出数据。 每一个在SIMD引擎中被处理的实例被称作为线程(Thread)。在每个Pass里,可以有大量的线程被映射到一个矩形区域中,这个矩形区域被称为执行区域(Domain of Execution)。 流计算处理器为每组线程都分配到一组线程处理器(Thread Processor)中,直到所有的线程都被处理。只有之前的线程完成计算之后,后面的线程才可以得到处理。下图为一个简化的ATI流计算模型:

Brook+简介: Brook+为开发者提供了一个简便快捷的流计算开发接口。用户可以通过Brook+在ATI的硬件进行流计算开发。Brook+的内核程序是由一种类C语言编写的,所有非常适合传统的C以及C++程序员。Brook+语言中两个最关键的概念:

1. 流。流就是一些类型相同的数据,他们可以被分配到不同的流处理器中进行处理。

2. 内核。内核程序其实就是GPU硬件的行为程序,它指定了硬件的行为特性。 Brook+的内核函数是被Brcc(Brook Code Compiler)编译的,编译后生成三个文件,其中两个是.h和.cpp文件,就是定义了一些和函数相关的类,还有一个最关键的就是IL代码。有了这些文件,这三个文件再和用户的其他源文件一起编译,链接,从而生成可执行性文件。Brook+的程序在运行时,是需要Brook runtime的。Brook+的内核程序也可以被CPU执行,还可以进行调试。 目前,Brook+的版本是1.4版本。已经被提交到了SourceForge上,应该是没有太多的维护了。由于Brook+还有一些限制,所以在灵活性方面并不如CUDA好。而且由于过多的封装,效率也并不很高。唯一的好处就在于用Brook+开发比较简便,程序员需要管理的事情不是特别多,因为Brook+已经把很多复杂的内容都封装起来了。对于想做一些GPGPU测试程序的朋友,这个接口还不错。但是如果开发复杂的项目,Brook+会有一定的限制。 2.0版以后的SDK已经没有了brook+ ,AMD准备用OpenCL取代之。AMD的终极目标就是让OpenCL成为通用计算的唯一标准。所以,过河拆桥吧…

CAL简介: ATI CAL(Compute Abstraction Layer)是一个硬件驱动接口,程序员通过CAL可以访问硬件所提供的几乎所有特性,可以控制硬件非常底层的东西。相对于Brook+来说,要底层一些,没有什么限制,灵活的多。事实上Brook+就是基于CAL实现的。CAL具有以下特性: 可以生成设备相关代码(ISA)。 设备管理。 资源管理。 内核的读取与执行。 多核GPU的支持。 与3D图形接口的交互(Interoperability)。(关于这种交互,我专门有介绍过:http://blog.csdn.net/codeboycjy/archive/2009/11/28/4896835.aspx

CAL可以支持用IL编写的内核函数,也同样可以接受用硬件高度相关的代码(ISA)来编写Kernel。 CAL的优点在于,它是很底层的接口,用户可以非常灵活的控制GPU的很多模块。但是CAL也有一些缺点,CAL的内核编写是非常繁琐的,因为IL是一种类似于汇编的语言,所以在开发过程中,是很难调试的。而且也不适合快速开发,对于C程序员来说,可能上手也不是特别快。但是其实如果适应了IL的开发,这些困难也可能并不很大。

OpenCL简介: 目前来说,如果想用A卡进行流计算,无非就是用Brook+,CAL或者OpenCL了。Brook+实际上没有后续支持了,所以并不是最理想的接口。而CAL虽然AMD一直都在更新,但是由于开发难度相对来说大一些,可能也不适合初学者。如果开发者不想用pixel shader进行流计算的话,就只能用OpenCL了。好在这个接口是有Khronos提出的,是一种开放的接口,可以跨平台工作,具有很大潜力。AMD还是比较重视这个接口的,早在9月份初,就已经实现了CPU的solution了。在10月中旬左右,AMD再次发布了基于GPU的OpenCL。 用户可以通过下载ATI Stream 2.0 Bate 4.0来体验一下AMD的流计算功能。当然,必须要有一块显卡支持才可以。如果有HD Radeon 5000系列最好,但是如果没有的话,4000系列也是同样支持的。 OpenCL的接口的优点在于,代码不仅可以运行在A卡上,还可以运行在N卡上,Nvidia也发布了OpenCL的solution了。而且还可以在x86架构上运行。由于接口的开放性,以后可能会有更多的处理器支持OpenCL接口。那么用户的OpenCL代码理论上来说,同样是可以跑在新的平台下的。OpenCL的内核编写也是用类C语言进行开发的,所以也非常简单易用。

Stream Kernel Analyzer: 对于用IL或者Brook+开发的内核程序,用户可以用这个软件进行性能测试。可以在这里下载到:http://developer.amd.com/gpu/ska/Pages/default.aspx。 对于用IL开发程序的朋友来说,可能这个软件就更实用一些了。因为他可以检查一些语法错误,而且报告出的性能更接近与实际的。下图就是这个软件了:

流处理器的硬件功能:

上图为ATI流处理器的简易模型。不同型号的GPU会有不同的性能参数(例如SIMD引擎的数量),但是基本都是一样的模型。 一个流处理器里面包含很多SIMD引擎。每个SIMD引擎又包含了很多Thread处理器,每个线程处理器可以对于独立的数据进行内核所规定的操作。线程处理器还不算是最小的处理单元,一个线程处理器里面还包含了一定数量的流计算核心,这些核心才是最基本的进行处理的单元,他们可以进行整数,单精度浮点数,双精度浮点数等操作。在同一时间内,一个SIMD引擎中的所有的线程处理器都执行相同的指令集,不同的SIMD引擎是可以执行不同的指令的。

一个线程处理器中可以同时最多处理五条指令。我们看到上图中,一个线程处理器中有五个Stream core。其中一个是可以计算超越函数的,剩下四个可以同时计算单精度浮点数。双精度浮点数的处理是通过把四个stream core合起来才可以处理的,所以相对来说要慢一些。除了stream core,每个线程处理器实际还包含一个流控制器,他可以处理一些条件分支的情况。 不同型号的GPU的细节参数都是不同的。例如,在ATI Radeon 3870 GPU(RV670)这款GPU里面一共包含了4个SIMD引擎,每个SIMD引擎里面有16个线程处理器,并且每个处理器里面有5个stream core。一共是320个物理处理核心单元。 hd5870架构图,20(SIMD)x(4x2x2 processor) x (5 stream_core)=1600 个流处理器。

hd5670的架构图,5x4x2x2x5 =400个流处理器。

线程处理: 但同一个cycle中,每个SIMD引擎中的所有线程处理器都必须执行同一指令。为了隐藏内存访问所带来的延迟,线程在发送了内存访问命令之后会被立刻切换。GPU的流处理器里面的Cache并没有CPU多,对于内存访问的优化是通过线程之间的切换来进行的。 在一个线程处理器中,每4个cycle中,实际可以对于线程处理器指定四条指令。例如,还是刚才那个3870的例子中,16个线程处理器执行同样的指令,每个线程处理器中可以一次执行四条指令(因为每个线程处理器中有4个stream core)。实际上,从外部看,3870的SIMD引擎可以同时处理64条指令的。被同时执行的所有线程的集合被称为wavefront。这里面我们可以理解为3870的wavefront的大小是64的,注意,不是16。 wavefront的大小是根据GPU的型号不同而可变的。例如,HD 2600 和 HD 2400 的 wavefront的大小分别是32和16,而AMD FireStream 9170的wave front的大小就是64了。

流控制: 流控制实际上是通过把所有的可能涉及的指令都执行结合起来实现的。举个例子,看下面伪代码: if( condition ) { // cost T1 perform operation 1 }else { // cost T2 perform operation 2 } 在一个wavefront里面,如果所有的线程都执行行为1,那么行为2的指令将不会被执行。反之亦然。但是如果有一部分执行了行为1,有一部分执行了行为2,即使是1个线程,那么硬件的做法实际上是让所有线程执行行为1,然后在让所有线程执行行为2。那么总的时间就是T1+T2。 再举个例子,在一个内核函数的循环里面,每次循环cost T,一个wavefront的线程都只循环一两次,除了一个例外线程循环了100次。那么实际的执行时间就是100*T。这个道理和竹筒装水是一样的。 所以我们在进行内核程序开发的时候,一定要对于这种分支很明显的情况保持高度敏感。

内存模型: 在ATI流计算模型中,有三种内存模型: host端的内存:这部分内存就是host程序的数据内存等。他可以被host端访问,但是不能被GPU kernel访问。 PCIe内存:这部分的内存可以被host端或者GPU端访问,但是要做好同步工作。在CAL里面要用calCtxIsEventDone函数,Brook+和OpenCL都已经把这些内容透明了,用户可以无视。 Local内存:这里的局部是相对于GPU来说的,那么很显然,这种内存是可以被GPU访问的,但是不能被host端访问。 有三种方式可以拷贝内存到流处理器内存(局部内存)中: 通过 calResMap 通过 calCtxMemCopy 通过一些自定义内核函数从PCIe内存中拷贝。

流处理器的分配: 高效的流处理器分配机制可以很好的隐藏内存访问所带来的延迟。上面提到GPU是通过线程间切换隐藏内存访问的,这里我们具体举个例子来看一下。

这里我们假设有四个线程。在最开始的时候,T0在运行,然后在第20个cycle的时候,该线程申请内存读取。其实,线程没有自己去读取内存,而是发送一条指令给DMA。然后T0就被suspend起了,这个thread processor就去执行T1。然后T1也会被suspend,切换T2。以此类推。在第70个cycle的时候,线程T0请求的内存被返回,所以这是T0就可以继续进行操作了。那么在T3结束后,T0会继续。从thread processor角度讲,在任何一个时间内,都在工作,没有idle状态,所以利用率很高。而从线程角度讲,由于线程的相互切换,内存访问的延迟就被隐藏起来了。 访问全局的内存的cycle的数量级在200左右,而访问shared memory或者register就会在几个cycle内搞定。这个差距是非常大的。所以为了能够有效的隐藏全局访问的延迟,我们需要让计算更密集。就是说在尽可能少访问内存的情况下,多进行计算操作。另外还要有足够的线程数量,上面的例子是个最简单的例子,访问全局的延迟远远要大于四个指令读取的命令。一定要尽可能的保证线程数量的足够,这样才能最好的利用GPU的硬件特性。 当然,这里绝对不是说为了更好的利用硬件,要增加一些无关的计算,以及一些无用的线程。线程当然是越少越快,但是如果少到一定的程度,甚至比stream core的数量还要少,GPU的利用率是非常低的。
昨天搞了一下ATI Stream SDK 感觉配置起来也很简单。先看一下目录:

-rwxr-xr-x  1 root root  3169 Aug  9 15:14 LICENSE-llvm.txt*
-rwxr-xr-x  1 root root 35567 Aug  9 15:14 LICENSE-mingw.txt*
-rwxr-xr-x  1 root root   135 Aug  9 15:14 Makefile*
drwxr-xr-x  3 root root    72 Nov 16 13:31 TempSDKUtil/
drwxr-xr-x  3 root root    72 Aug  9 15:14 bin/
drwxr-xr-x  3 root root    72 Aug  9 15:14 docs/
-rwxr-xr-x  1 root root   566 Aug  9 15:14 glut_notice.txt*
drwxr-xr-x  4 root root   280 Aug  9 15:14 include/
drwxr-xr-x  4 root root    96 Aug  9 15:14 lib/
drwxr-xr-x  2 root root   152 Nov 17 14:14 make/
drwxr-xr-x  4 root root   120 Aug  9 15:14 samples/
有用的目录有这几个:
bin目录里面就一个clc,个头很大有4MB。但还不清楚这个到底是干什么的。
include包括所有的头文件,包括CL 和GL 部分。
lib包括所有的库文件。bc结尾的是LLVM中间层字节码(有点像java的class 文件)。其实opencl的运行时就是依靠里面的libOpenCL.so吃饭的。而cal的运行时要靠libaticalrt.so 和libaticalcl.so , 不过这两个都在radeon的闭源驱动里,不在SDK中。这目录下的所有文件最好都丢进/usr/lib/,免得ldconfig找不到。
make包含编译配置脚本。各目录中的make文件均会include这里的openclsdkdefs.mk 和openclsdkrules.mk。
samples 目录包含cal(流计算抽象模型)和openCL示例。cal目录中除bin这个已编译二进制文件目录,其他都是带有make的源码目录。openCL目录下同样也是除bin目录,其他几个都是有cpp源码的目录。其中SDKUtil中的是充当编译时库文件的角色,用于其他app去link。
说了半天,开始运行一个sample吧。
运行cal的很简单,直接到bin目录下执行即可。
但openCL的就要稍微配置一下:
(1)下载icd-registration.tar (icd:installable Client Driver)解包到/etc/目录,里面其实就是/etc/OpenCL/vendors/atiocl32.icd 和atiocl64.icd 两个文本,分别记录libatiocl32.so和libatiocl64.so 两个字符串。这两个库文件都位于lib/x86 目录下。openCL 目标代码首先找到libOpenCL.so,然后他分析执行所需要的函数,根据atioclXX.icd 去找对应GPU de  libaticl32.so。可以想到这其实就是一种跨GPU策略,说不定哪天NV 会发布一个libnvocl32.so。
如果少了icd会提示Error:clGetPlatformIDs failed ,Error code: CL_PLATFORM_NOT_FOUND_KHR
(2)需要export ATISTREAMSDKROOT=/path/to/sdk 来设置sdk目录,其实这个主要就是为了设置LD_LIBRARY_PATH(搞不懂ATI为什么不用LIBRARY_PATH变量)。缺少这个变量在执行opencl程序时会报错:
************************************************
sh:/bin/x86/clc : No such file or directory
************************************************
Error: clBuildProgram failed . Error code : CL_BUILD_PROGRAM_FAILURE
感觉opencl其实就是类似java或.net一样的虚拟环境,用g++编译.cpp,.h,.cl 和其他资源文件,编译成的二进制文件虽然可以执行但却需要clc进行二次编译(clBuildProgram()),clc就像jdk中的java ,编译成的二进制文件就像.class 。

SONY MDR-EX1000 发布

sony 新的MDR-EX1000 入耳式耳塞发布,新特性是液晶振膜(my god,Hi-Fi里说不清的东西真多)。EX700的升级版,值得一提的是还有发布了MDR-EX800ST 不过官网没有见,而是放在了sony studio 和CD900ST一起,看来EX800ST 定位是录音棚监听。

EXK的评测基本都是在捧的,超越IE8 ,T50P(这个…我觉得很难啊)云云,不过那些所谓发烧的人很多都是这样,新东西出来就热捧,过一年半年就开始狂贬了,东西要打对折才卖得出去,TF10 就是一个典型。

不过EXK有一点值得肯定,终于sony 开始捡回那多年不见的Made in japan(激动) ,而且大大地印在上面十分显眼。

種類 型番 特徴 発売日 価格
ヘッドフォン MDR-Z1000 液晶ポリマーフィルム振動板
50mm径 新開発HDドライバーユニット
高耐入力4,000mW
7N OFCリッツ線
着脱式ケーブル
11月10日 61,950円
カナル型イヤフォン MDR-EX1000 液晶ポリマーフィルム振動板 16mm径 新開発ドライバーユニット
7N OFCリッツ線
フレキシブルイヤーハンガー
ノイズアイソレーションイヤーピース
着脱式ケーブル
10月23日 61,950円

关于探测可用中断

注释一下LDD3中DIY探测中断的一段代码:
irqreturn_t short_probing(int irq, void *dev_id, struct pt_regs *regs)
{
if (short_irq == 0)
short_irq = irq; //说明被探测中断线上捕获了一个中断
if (short_irq != irq)
short_irq = -irq; //说明不是第一次被中断捕获,也就是说注册的多个中断中不止一个被触发
return IRQ_HANDLED;
}
void short_selfprobe(void)
{
int trials[] = {3, 5, 7, 9, 0};//建立尝试中断号数组,以0为结束
int tried[]  = {0, 0, 0, 0, 0};//
int i, count = 0;
for (i = 0; trials[i]; i++)
tried[i] = request_irq(trials[i], short_probing,SA_INTERRUPT, “short probe”, NULL); //依次注册各个被探测中断,并记录结果到tried
do {
short_irq = 0; /* none got, yet */
outb_p(0x10,short_base+2); /* enable */
outb_p(0x00,short_base);
outb_p(0xFF,short_base); /* toggle the bit */
outb_p(0x00,short_base+2); /* disable */
udelay(5);   //在这期间会发生中断,short_irq的值会变化
if (short_irq == 0)
printk(KERN_INFO “short: no irq reported by probe\n”);
} while (short_irq <=0 && count++ < 5);//最大重试5次,其中包括多个中断号被捕获的情况
for (i = 0; trials[i]; i++)
if (tried[i] == 0)
free_irq(trials[i], NULL);//仅清除成功注册过的探测中断号

if (short_irq < 0) //我觉得作者假设被探测的中断号肯定在trials中,如果严谨的话我觉得条件应该是short_irq<=0 ,即加上可能性:没有任何中断被探测到。
printk(“short: probe failed %i times, giving up\n”, count);
}
这段代码需要特别注意short_irq = -irq 这句,以及short_irq这个变量的变化,因为中断可能随时发生(尽管SA_INTERRUPT会禁止当前处理器所有其他中断,但执行完return IRQ_HANDLED 后很有可能紧接着再继续执行一个short_probing)。

HP DV6 上秘密

偶尔用evtest测试/dev/input/event1o的时候发现一个未知的东西,而且无规则的发出事件:
linux:~ # evtest /dev/input/event10
Input driver version is 1.0.0
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: “ST LIS3LV02DL Accelerometer”
Supported events:
Event type 0 (Sync)
Event type 3 (Absolute)
Event code 0 (X)
Value     -3
Min    -2304
Max     2304
Fuzz      54
Flat      54
Event code 1 (Y)
Value    -66
Min    -2304
Max     2304
Fuzz      54
Flat      54
Event code 2 (Z)
Value    984
Min    -2304
Max     2304
Fuzz      54
Flat      54
Testing … (interrupt to exit)
Event: time 1289392074.426632, type 3 (Absolute), code 1 (Y), value -58
Event: time 1289392074.426643, ————– Report Sync ————
Event: time 1289392077.234645, type 3 (Absolute), code 0 (X), value -11

google了一下ST LIS3LV02DL Accelerometer 发现这竟然是一个三轴加速计。搬动机器的时候反应会很剧烈,但也很灵敏,稍微震动都会有反应。我立刻意识到这肯定是用来实现硬盘保护的。不过这个机制能保证即使把传感信号告知应用程序吗? 这个东西是挂在I2C总线上的,而且启动保护的也是软件机制。感觉HP的这个东西可靠性不高阿。 值得一提的是这个东西的厂商是台湾的ST,而且价格不便宜,每片大约400+NT。