這樣比較, 是蠻怪的
主要是因為近日升級了原有桌機 Acer Aspire X3200
自 Athlon 64 X2 4400+ 換成 Phenom X4 9450e
(礙於X3200 僅有 220W的電源, 搭配 ATI 5570 1GB 顯卡)
而目前在用的 Notebook 用的是MSI CX420其CPU為Core i5 430M
沒有做甚麼各項評比,無論NB/Desktop換硬體都是希望編譯時間短些
兩者都以 make -j8 方式去編譯同一份 Android code
Phemon X4 9450e: 44 mins
Core i5 430M: 50mins
參照PassMark 的評比分數
Phenom X4 9450e: 2663
Core i5 430M: 2361
換算下來的確 2663x44(117172) 約略等同 2361x50(118050)
看來PassMark還蠻值得參考的
2010年11月12日 星期五
2010年10月27日 星期三
Clang 成功編譯能運作的 Linux kernel 2.6.36
Linux 2.6.36 在上週釋出了
關心進展的可以追 KernelNewbie 和 The H Open Source
著名的 LLVM 的 C frontend - Clang
繼去年宣佈能成功編譯 FreeBSD kernel 之後
LWN 上得知, 現在已經能夠編譯能運作的 Linux 2.6.36 Kernel
相信不久之後, 除了GCC 外 編譯 Linux 就有 Clang 這個新選擇
關心進展的可以追 KernelNewbie 和 The H Open Source
著名的 LLVM 的 C frontend - Clang
繼去年宣佈能成功編譯 FreeBSD kernel 之後
LWN 上得知, 現在已經能夠編譯能運作的 Linux 2.6.36 Kernel
相信不久之後, 除了GCC 外 編譯 Linux 就有 Clang 這個新選擇
2010年10月20日 星期三
急起直追的 Firefox 4
跨入十月之後, Firefox帶來了值得高興的消息
從持續紀錄 Firefox 最新 JavaScript 效能的arewefastyet網站上
Firefox 在自己的 sunspider 與 Google 的 v8bench 兩項效能評估指標
都有超越 Apple Nitro 的成績
上圖為 6月時 Firefox對比於 Apple Nitro/Google V8 優勢的窘境
隨著網頁技術的演進, 瀏覽器的角色日益重要
新興瀏覽器(Chrome, Opera, IE9)皆有著不錯的技術背景
Firefox 新的競爭者重心由以往的 IE6/7 轉向了這些新挑戰者
回顧在6月時, chrome v8/apple nitro 對於firefox 還是如此的遙不可及
在Chrome的蠶食逼近, IE9 的改頭換面下
甚至有要Mozilla放棄自有的 Gecko 投入 Webkit 的言論出現
在Chrome V8點燃的瀏覽器 JavaScript 效能競爭
並隨著之後HTML5取代Flash 以及 GPU在網頁瀏覽的應用等話題
新的瀏覽器戰爭已經揭開了序幕
在以 Firefox 揭開瀏覽器革命時代之後
Mozilla再次用行動向大眾證明了維護 Firefox/Gecko 技術平台的信念
續 Xubuntu On MSI CX420 - RT3070 dkms support
昨日更新系統到 Xubuntu 10.10
由於kernel版本更新, 一再重複安裝 rt3070 驅動程式, 也是相當煩瑣
想要讓它像目前使用的 fglrx 一樣透過dkms 更新
其實一方面也是因為沒嘗試過dkms
於是參考了RT3090的範例, 昨晚花了點時將 rt3070 driver 打包為 dkms 形式
由於kernel 2.6.35改動了一些usb function的名稱, 所以ubuntu 10.04 與 10.10 稍有不同
(其實正確來說是 kernel <= 2.6.34 用 10.04, kernel >= 2.6.35 用10.10)
有需要者請自行取用: 10.04版 10.10版
後註: 其實 RALINK 官網上有對應新版的 RT3370 驅動程式, 然而 dmesg 看來雖然有驅動, 但卻無法正常運作, 所以這裡使用的是次新的版本, 有時間再來看新版的問題
由於kernel版本更新, 一再重複安裝 rt3070 驅動程式, 也是相當煩瑣
想要讓它像目前使用的 fglrx 一樣透過dkms 更新
其實一方面也是因為沒嘗試過dkms
於是參考了RT3090的範例, 昨晚花了點時將 rt3070 driver 打包為 dkms 形式
由於kernel 2.6.35改動了一些usb function的名稱, 所以ubuntu 10.04 與 10.10 稍有不同
(其實正確來說是 kernel <= 2.6.34 用 10.04, kernel >= 2.6.35 用10.10)
有需要者請自行取用: 10.04版 10.10版
後註: 其實 RALINK 官網上有對應新版的 RT3370 驅動程式, 然而 dmesg 看來雖然有驅動, 但卻無法正常運作, 所以這裡使用的是次新的版本, 有時間再來看新版的問題
2010年10月9日 星期六
Meego on OpenSuse - Smeegol
上圖為在 EeePC 701 上安裝後調整的效果
(Wifi icon旁原有bluetooth的icon, eeepc沒有就移除掉了)
OpenSuse 近日發布了 Meego 的新聞
該計畫有個有趣的名字 - Smeegol (Suse Meego Linux, 諧音於Lord of Ring中的角色),
LiveCD 的下載位址在此
使用 LiveCD 開機後選取 Yast->Live Installer 就可以安裝好
由於這個Smeegol計畫, 所以初嘗Suse的系統
老實說支援很不錯, zypper也很好用
安裝在 EeePC 701 上, 效果算很不錯 (讓我的EPC 701 有復活的fu)
Meego社交網站整合已經有很多平台了
包含 flickr, facebook, twitter, last.fm, MySpace, digg 等
由於政治因素, 很可惜 Meego 官方比較親近 rpm 體系
所以目前 Debian/Ubuntu 沒有正式支援 Meego
(是有人嘗試編譯 Meego UX 安裝在 Debian 上, 並且有所成果)
雖然Canonical很用心的建構 Ubuntu Netbook Unity
但單以User Experience來看, 個人比較看好 Meego
2010年9月22日 星期三
續 Xubuntu On MSI CX420
2010年9月2日 星期四
Blogger 的另類用途
在碩士時期, 曾因為lab計劃認識一個很不錯的朋友
當時就曾聽他說打算要出國留學的事情
後來隨著lab計劃的告一段落, 加上之後各奔東西
雖曾斷續地聽到它的消息, 但也就因此失了聯絡
昨日驚喜地收到他寄來的 Email
即將要取得學位了,我在這裡也再次恭喜他
只是我沒想過 blogger 還有這點功用 ^^
當時就曾聽他說打算要出國留學的事情
後來隨著lab計劃的告一段落, 加上之後各奔東西
雖曾斷續地聽到它的消息, 但也就因此失了聯絡
昨日驚喜地收到他寄來的 Email
即將要取得學位了,我在這裡也再次恭喜他
只是我沒想過 blogger 還有這點功用 ^^
2010年8月26日 星期四
2010年8月18日 星期三
Linux Kernel 2.6.35
基本上這是舊聞了
Linux Kernel 2.6.35 於 Aug. 1st. 2010 釋出
按慣例, 相關的更動細節可以至 KernelNewbies 看
The H Open 也有篇詳細的 What's New in Linux 2.6.35
簡單說這版的改進主要在於網路效能與功能上的增進
像是能更有效的分散網路流量的loading 到 CPUs 上, 相信這對 server 效能有一定的增進
在者就是支援多個 Multicast(群播) 的 routing table
相信許多人會感到興趣的 i915 對於 VC1, H.264 的硬體加速支援
改善了對於AMD ATI Radeon的支援(主要是系統上的, 像是reset與降低功耗, 而非效能上)
另外檔案系統上改善了 Btrfs/XFS
最後引人注目的核心改進功能是 Memory Compaction
Memory Compaction 對於實體記憶體管理有相當的影響
其功能主要在減少 memory 中的 fragmentation (斷離)
並且增加實體上連續的free pages供核心系統與驅動程式應用
簡短的列舉到此,有興趣的趕快去挖寶吧~
Emerald 佈景 - Moka.改
自從為了簡潔因素而改用 Xubuntu 後
即無法繼續在EeePC 701/900上使用GNOME上慣用的Almond Mini metacity佈景
(主要還是因為其Window Decoration 佔用空間小)
為了享受Desktop的硬體加速, 個人習慣使用 Compiz (scrollbar 比較順...)
而xfwm無法在compiz下使用, 而必須以 Emerald 取代
原本用的是仿 Xubuntu 下預設的 Albatross 佈景
無奈於視覺上感覺佔用了太多空間
搜尋了一下 Emerald 佈景, 發現可以接受的 Moka 佈景
按鈕圖案上, 個人偏愛Shiki Minimal Match所使用的風格
(Shiki Minimal主要在於視窗沒有文字標題)
於是花了點時間做圖案的剪裁與替換
修改inactive window 的標題文字顯示(看設定是有顯示, 但是根本看不出來)
並且減少了Window Border(3->2)
效果上比原有 Moka 來得令我滿意
有興趣者可以到此下載
2010年8月15日 星期日
續 Firefox on Netbook
在女兒開始會爬之後, 就需要有人隨時在側的陪伴
原本用來利用來做監視系統的EeePC 701也就又成為我的床頭機
在長時間不常使用 800x480 解析度後, 對於垂直解析度的浪費變得更無法容忍
對於這樣的topic原本寫了篇Firefox on Netbook
經過如此調整後 titlebar 還是覺得太粗了
於是又加入 Compact Classic 與 Compact Classic Options
最後就是把系統的 task panel 改為直式
這麼一來就從畫面上榨出最後的垂直顯示空間
使用 FireBBS 甚至還可以將字型大小設到 18, 還算堪用
2010年8月9日 星期一
HiRadioTray 20100809 release
對於 HiRadioTray 的維護是對於使用者比較抱歉的地方
並沒有投入相當的時間在維護與更新上
今日將 script 更新並且針對ubuntu 10.04 i386/amd64 編譯並提供兩個版本
有需要者請到下載頁面下載
新的 script 使用更新功能也可以下載
並沒有投入相當的時間在維護與更新上
今日將 script 更新並且針對ubuntu 10.04 i386/amd64 編譯並提供兩個版本
有需要者請到下載頁面下載
新的 script 使用更新功能也可以下載
2010年7月22日 星期四
Office 軟體的新選擇 - IBM Lotus Symphony 3
Linux 桌面使用者對於 OpenOffice 都不陌生
OpenOffice 的確也逐漸成熟了, 儘管功能性上已經很充足
然而在易用與便利性上的確還有許多改善空間
近日安裝 Xubuntu 想安裝 OpenOffice 時忽然想起沈寂已久的 Lotus Symphony
IBM 在三年前推出 OpenOffice 1.x 為基礎的 Lotus Symphony 1.x 後
很可惜的是當年OpenOffice 以進展至 2.x 相容性與速度上都領先不少
跑去IBM Lotus Symphony官網看了之後, 大為驚人
Lotus Symphony 竟然悄悄推出 Symphony 3 beta 而且已經進展到 beta 3
官方的說明是 Lotus Symphony 是建構在 OpenOffice 3 上
搜尋了一下, 繁中網頁竟然少有資訊, 也沒有任何介紹(或許得拜台灣教育與盜版成功吧..)
除了有 Ubuntu 版本外還有 Windows, Mac OS X 與 RedHat 版本, 下載安裝後, 除了一開始一堆問號似乎是 License 的資訊
下圖為啟動程式後, 映入眼中的第一個畫面, 安裝後語言套件後即有中文
網路上隨便找個 DOC 檔來開看看, 介面的配置看來很適合寬螢幕
UI 的配色與格式看來有再設計過, 1.x 版的顯得比較擁擠
再開個 XLS 檔來看看, 這時有特別的感覺了, 維持了一貫的分頁設計
但是 Lotus Symphony 3 有做小 icon 的區別, 1.x 都是 Symphony icon
接著開個 ODP 簡報檔, 在製作時, 我覺得頗為 Smart, 當你做不同屬性的編輯時
右側的頁面會自動切換於不同個功能頁面, 下圖為開啟預設介面
選取方塊物件, 右方立刻可以編輯顏色, 外框等資訊
選擇編輯文字方塊, 旁邊便是字型選擇, 大小, 顏色
甚至是行距的調整
試用幾天後, 個人覺得雖然記憶體消耗較高些
然而 Lotus Symphony 3 的便利性相當令人滿意
如果看膩了 OOo 較為單調的介面, 不妨試試看新的 Lotus Symphony 3
OpenOffice 的確也逐漸成熟了, 儘管功能性上已經很充足
然而在易用與便利性上的確還有許多改善空間
近日安裝 Xubuntu 想安裝 OpenOffice 時忽然想起沈寂已久的 Lotus Symphony
IBM 在三年前推出 OpenOffice 1.x 為基礎的 Lotus Symphony 1.x 後
很可惜的是當年OpenOffice 以進展至 2.x 相容性與速度上都領先不少
跑去IBM Lotus Symphony官網看了之後, 大為驚人
Lotus Symphony 竟然悄悄推出 Symphony 3 beta 而且已經進展到 beta 3
官方的說明是 Lotus Symphony 是建構在 OpenOffice 3 上
搜尋了一下, 繁中網頁竟然少有資訊, 也沒有任何介紹(或許得拜台灣教育與盜版成功吧..)
除了有 Ubuntu 版本外還有 Windows, Mac OS X 與 RedHat 版本, 下載安裝後, 除了一開始一堆問號似乎是 License 的資訊
下圖為啟動程式後, 映入眼中的第一個畫面, 安裝後語言套件後即有中文
網路上隨便找個 DOC 檔來開看看, 介面的配置看來很適合寬螢幕
UI 的配色與格式看來有再設計過, 1.x 版的顯得比較擁擠
再開個 XLS 檔來看看, 這時有特別的感覺了, 維持了一貫的分頁設計
但是 Lotus Symphony 3 有做小 icon 的區別, 1.x 都是 Symphony icon
接著開個 ODP 簡報檔, 在製作時, 我覺得頗為 Smart, 當你做不同屬性的編輯時
右側的頁面會自動切換於不同個功能頁面, 下圖為開啟預設介面
選取方塊物件, 右方立刻可以編輯顏色, 外框等資訊
選擇編輯文字方塊, 旁邊便是字型選擇, 大小, 顏色
甚至是行距的調整
試用幾天後, 個人覺得雖然記憶體消耗較高些
然而 Lotus Symphony 3 的便利性相當令人滿意
如果看膩了 OOo 較為單調的介面, 不妨試試看新的 Lotus Symphony 3
2010年7月21日 星期三
淺談 OpenCore execution model
由於新工作與 OpenCore 有關, 前輩考量到未來對效能調整, 希望我能了解 OpenCore 架構
為此而稍微細看OpenCore, 感到非常"新奇", "有趣"
在此先不細談 OpenCore 整體 Object Model, 而這部份網路上的談論也不少
大致上即是分為 Engine - PVMF Node - Component 三層
這裡談 OpenCore 中的執行運作模式
或許是OpenCore 受到 Symbian Active Object Framework 諸多影響(文件上也有諸多Symbian字眼)
基本上, 對於Symbian 個人認知不深
然而對於OpenCore這樣注重 realtime 特性的 Multimedia Framework 採用這樣的方式感到"新奇"
上圖為運作的圖解
OpenCore 內基本執行單位為 PVActiveBase
而衍生出的 class 為 OsclActiveObject(AO) 與 OsclTimerObject(TO)
實作中需要被執行的元件繼承 AO or TO
而每個繼承AO/TO的類別需要個別實作其要不斷被執行的 Run() 介面
OpenCore 執行模式為 single thread
在 OsclScheduler::BlockLoopL() 這個無線迴圈當中
透過 WaitForActiveObject() 來取得下一個需要被執行的AO/TO
接著呼叫 CallRunExec() 來執行 AO/TO 的 Run()
對於規劃中需要被執行的AO/TO物件
只要沒腦地執行 PVActiveBase::AddToScheduler() 即可
接著便會依序被執行該AO/TO所實作的 Run()
看似簡單的行為, 然而直覺操作上卻讓人毫無頭緒
是的, 介面上無需透過具體的 scheduler instance, 從何來, 哪裡去就像黑盒子般
這點一時間讓我有點難以接受
細看實作上透過 macro 的方式取得 current thread 的 scheduler
只能說如此的 execution model 機制顯得不太clean
這樣的 model 基本上如果是為了 single thread/co-operative multitasking 的考量
也算說得過去, 只能說真的不是很優雅與直覺
再來, 其中最有趣的一點便在於 OsclTimer 與 PVMFMediaClock 這兩個 timer 類別
實作中AO/TO通常向此兩者註冊callback function 希望通知特定 time event 的發生
OsclTimer (oscl/oscl/osclproc/src/oscl_timer.h) 仰賴著 CallbackTimer
CallbackTimer 繼承自 "OsclTimerObject" ~ Wow~
看看 PVMFMediaClock (pvmi/pvmf/include/pvmf_media_clock.h)
一堆繼承物件中, 第一個物件即為 "OsclTimerObject"
而兩者的 Constructor 都呼叫了 AddToScheduler()
其時間的資訊是去 polling 系統的 OsclTickCount 得知
這麼看來 Timer 這點可"有趣"了, Timer 的運作與通知機制也仰賴著這個 BlockLoopL
而如果某一 AO/TO Run() 稍微久一點, Timer Event 可能就失真不少
ex:
試想, 假若一個 decoder 具有硬體加速, 然而 interrupt 有問題
因此採用 polling 方式以得知硬體狀態
component 中期望 timer 能夠每 10 ms 通知一次,
方便於 check 硬體狀態來決定是否要命令硬體 decode 下一張 frame
而在此同時 audio decoder 為軟體實作, 每解一個單位需要 30ms
這麼一來 ......
是的, 如果要遷就這樣的 model, 每個 component 實作上必須特別考量到 timing
而軟體實作上可能必須是 progressive 的方式, 不要一次將全部結果解出, 減少 Run() 單一執行時間長度
以這樣的方式, 來換得 timing 的精確度
如果是為了遷就不用 thread 而使用這樣的 timer 實作呢?
那 Audio 處理與 proxy interface 中就不該大剌剌地使用 OsclThread
anyway, 很高興在 trace 期間自 jserv 那聽到 2.2 已是預設的 StageFright
雖然目前實作不若 OpenCore 完整, 然而看來就個人的理解是"正常"多了 ...
20100727 後記: 應該好好說明一下 proxy interface, 其實本文中舉的例子並不一定會出現, 這裡用這樣的例子來解釋這樣的方式的問題, 文中例子的發生與否取決於是否使用proxy interface(是的, 這是compile option, 而且意義並非網路proxy), 在OpenCORE 中 codec 以 openmax 封裝為 omx_xxx_component, 若透過 proxy interface 即 create 了各 codec 的 thread. 儘管 OpenCORE 中透過使用proxy interface如此與設計不同的方式來避開 codec 的時間問題, timer 依舊容易受到 system I/O 與 parser 之類的影響.
為此而稍微細看OpenCore, 感到非常"新奇", "有趣"
在此先不細談 OpenCore 整體 Object Model, 而這部份網路上的談論也不少
大致上即是分為 Engine - PVMF Node - Component 三層
這裡談 OpenCore 中的執行運作模式
或許是OpenCore 受到 Symbian Active Object Framework 諸多影響(文件上也有諸多Symbian字眼)
基本上, 對於Symbian 個人認知不深
然而對於OpenCore這樣注重 realtime 特性的 Multimedia Framework 採用這樣的方式感到"新奇"
上圖為運作的圖解
OpenCore 內基本執行單位為 PVActiveBase
而衍生出的 class 為 OsclActiveObject(AO) 與 OsclTimerObject(TO)
實作中需要被執行的元件繼承 AO or TO
而每個繼承AO/TO的類別需要個別實作其要不斷被執行的 Run() 介面
OpenCore 執行模式為 single thread
在 OsclScheduler::BlockLoopL() 這個無線迴圈當中
透過 WaitForActiveObject() 來取得下一個需要被執行的AO/TO
接著呼叫 CallRunExec() 來執行 AO/TO 的 Run()
對於規劃中需要被執行的AO/TO物件
只要沒腦地執行 PVActiveBase::AddToScheduler() 即可
接著便會依序被執行該AO/TO所實作的 Run()
看似簡單的行為, 然而直覺操作上卻讓人毫無頭緒
是的, 介面上無需透過具體的 scheduler instance, 從何來, 哪裡去就像黑盒子般
這點一時間讓我有點難以接受
細看實作上透過 macro 的方式取得 current thread 的 scheduler
只能說如此的 execution model 機制顯得不太clean
這樣的 model 基本上如果是為了 single thread/co-operative multitasking 的考量
也算說得過去, 只能說真的不是很優雅與直覺
再來, 其中最有趣的一點便在於 OsclTimer 與 PVMFMediaClock 這兩個 timer 類別
實作中AO/TO通常向此兩者註冊callback function 希望通知特定 time event 的發生
OsclTimer (oscl/oscl/osclproc/src/oscl_timer.h) 仰賴著 CallbackTimer
CallbackTimer 繼承自 "OsclTimerObject" ~ Wow~
看看 PVMFMediaClock (pvmi/pvmf/include/pvmf_media_clock.h)
一堆繼承物件中, 第一個物件即為 "OsclTimerObject"
而兩者的 Constructor 都呼叫了 AddToScheduler()
其時間的資訊是去 polling 系統的 OsclTickCount 得知
這麼看來 Timer 這點可"有趣"了, Timer 的運作與通知機制也仰賴著這個 BlockLoopL
而如果某一 AO/TO Run() 稍微久一點, Timer Event 可能就失真不少
ex:
試想, 假若一個 decoder 具有硬體加速, 然而 interrupt 有問題
因此採用 polling 方式以得知硬體狀態
component 中期望 timer 能夠每 10 ms 通知一次,
方便於 check 硬體狀態來決定是否要命令硬體 decode 下一張 frame
而在此同時 audio decoder 為軟體實作, 每解一個單位需要 30ms
這麼一來 ......
是的, 如果要遷就這樣的 model, 每個 component 實作上必須特別考量到 timing
而軟體實作上可能必須是 progressive 的方式, 不要一次將全部結果解出, 減少 Run() 單一執行時間長度
以這樣的方式, 來換得 timing 的精確度
如果是為了遷就不用 thread 而使用這樣的 timer 實作呢?
那 Audio 處理與 proxy interface 中就不該大剌剌地使用 OsclThread
anyway, 很高興在 trace 期間自 jserv 那聽到 2.2 已是預設的 StageFright
雖然目前實作不若 OpenCore 完整, 然而看來就個人的理解是"正常"多了 ...
20100727 後記: 應該好好說明一下 proxy interface, 其實本文中舉的例子並不一定會出現, 這裡用這樣的例子來解釋這樣的方式的問題, 文中例子的發生與否取決於是否使用proxy interface(是的, 這是compile option, 而且意義並非網路proxy), 在OpenCORE 中 codec 以 openmax 封裝為 omx_xxx_component, 若透過 proxy interface 即 create 了各 codec 的 thread. 儘管 OpenCORE 中透過使用proxy interface如此與設計不同的方式來避開 codec 的時間問題, timer 依舊容易受到 system I/O 與 parser 之類的影響.
2010年7月20日 星期二
Xubuntu On MSI CX420
近日由於工作需要編譯 Android 環境, 原有的配有 Sempron Mobile 3800+ 筆電不敷使用
到了附近的賣場看了後, 決定了購入新的筆電 - MSI CX420
所俱備的性能與價格搭配看來是具有相當高性價比的機子
當然, 拿到手第一件事當然是想辦法安裝 Linux 環境
安裝本身並不是難事, 問題發生在安裝完成後
1. 安裝 ATI 驅動程式, 無論透過 Ubuntu 的啟動ATI專有驅動程式, 或是手動安裝ATI Driver, 安裝後重新開機都會是黑螢幕(Yap, 為此我重裝一次....).
這部份的線索是從 MSI CX420 驅動程式頁上對於 XP 需要設定 Primary Display為 PEG
是的 Linux 同 XP 不支援 SG(Switchable Graphics) 特性
需要刷新 BIOS 版本, 將 Primary Display 設為 PEG(PCI-Express Graphics)
刷新後, 原本黑濛濛的畫面就變得非常亮眼~ (無需重裝Linux, 刷新後就正常了)
2. Ralink 1T1R 802.11bgn 無線網路裝置無法驅動
從 Windows 上可以看到為 USB 裝置, 也可以看到所在的 Port & Hub 位置
於 Linux 上 lsusb 可以得到下列訊息:
Bus 002 Device 002: ID 8087:0020
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0db0:3870 Micro Star International
Bus 001 Device 002: ID 8087:0020
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
喔!? 竟然顯示微星 (lsusb -v 的 verbose mode 也只能看出是 Ralink裝置, 就省略了)
搜尋 device id 0db0:3870 可以看到 rt2800 的訊息
加上看到MSI官網上的驅動程式, 解開後閱讀 inf, 標明為 rt2870, 第一時間我就以為是Ralink RT2870
跑到 Ralink 的Linux驅動程式頁面下載RT2870USB 驅動程式
還自作聰明地將device id 加入來偵測, 結果是裝置驅動了, 然而無法scan ap 與連線
不能 work 的 driver 等於沒有, 於是回到了原點
接著想找社群的 open source 方案
由於 google 0DB0 3870第一時間會看到這個頁面
這表示 rt2800usb 還是與 CX420 上的裝置有關
從頁面聯結的 rt2800usb.c 原始碼可以看到 裝置歸類於 RT2800USB_UNKNOWN
然而這檔案看來也不是最新的, 當然立刻看 git.kernel.org 上最新的 rt2800usb.c
ok, 這裝置在 rt2800usb driver 中被歸類為 RT2800USB_RT30XX
於是, 這時恍然大悟, 被搞錯的型號也呼之欲出
0x0db0:0x3870 的 Ralink USB 裝置應該為 RT3070
重新去網頁下載RT3070USB驅動程式, WIFI 速度非常!
到此終於解決了 Video 與 Wifi 兩大問題.
WebCam 後來測試是ok的, bluetooth 我沒在用也就無從測起了..^^
到了附近的賣場看了後, 決定了購入新的筆電 - MSI CX420
所俱備的性能與價格搭配看來是具有相當高性價比的機子
當然, 拿到手第一件事當然是想辦法安裝 Linux 環境
安裝本身並不是難事, 問題發生在安裝完成後
1. 安裝 ATI 驅動程式, 無論透過 Ubuntu 的啟動ATI專有驅動程式, 或是手動安裝ATI Driver, 安裝後重新開機都會是黑螢幕(Yap, 為此我重裝一次....).
這部份的線索是從 MSI CX420 驅動程式頁上對於 XP 需要設定 Primary Display為 PEG
是的 Linux 同 XP 不支援 SG(Switchable Graphics) 特性
需要刷新 BIOS 版本, 將 Primary Display 設為 PEG(PCI-Express Graphics)
刷新後, 原本黑濛濛的畫面就變得非常亮眼~ (無需重裝Linux, 刷新後就正常了)
2. Ralink 1T1R 802.11bgn 無線網路裝置無法驅動
從 Windows 上可以看到為 USB 裝置, 也可以看到所在的 Port & Hub 位置
於 Linux 上 lsusb 可以得到下列訊息:
Bus 002 Device 002: ID 8087:0020
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0db0:3870 Micro Star International
Bus 001 Device 002: ID 8087:0020
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
喔!? 竟然顯示微星 (lsusb -v 的 verbose mode 也只能看出是 Ralink裝置, 就省略了)
搜尋 device id 0db0:3870 可以看到 rt2800 的訊息
加上看到MSI官網上的驅動程式, 解開後閱讀 inf, 標明為 rt2870, 第一時間我就以為是Ralink RT2870
跑到 Ralink 的Linux驅動程式頁面下載RT2870USB 驅動程式
還自作聰明地將device id 加入來偵測, 結果是裝置驅動了, 然而無法scan ap 與連線
不能 work 的 driver 等於沒有, 於是回到了原點
接著想找社群的 open source 方案
由於 google 0DB0 3870第一時間會看到這個頁面
這表示 rt2800usb 還是與 CX420 上的裝置有關
從頁面聯結的 rt2800usb.c 原始碼可以看到 裝置歸類於 RT2800USB_UNKNOWN
然而這檔案看來也不是最新的, 當然立刻看 git.kernel.org 上最新的 rt2800usb.c
ok, 這裝置在 rt2800usb driver 中被歸類為 RT2800USB_RT30XX
於是, 這時恍然大悟, 被搞錯的型號也呼之欲出
0x0db0:0x3870 的 Ralink USB 裝置應該為 RT3070
重新去網頁下載RT3070USB驅動程式, WIFI 速度非常!
到此終於解決了 Video 與 Wifi 兩大問題.
WebCam 後來測試是ok的, bluetooth 我沒在用也就無從測起了..^^
2010年7月10日 星期六
無意取悅小螢幕裝置的 Ubuntu Unity 介面
近日注意到Ubuntu 新的Distribution - Ubuntu Light
其 UI 系統稱之為 Unity
由於是屬於 Ubuntu Netbook Edition 的系列 UI
於是就裝到 EeePC 701 上測試
對於視覺呈現上並不滿意
常用的 Web Browsing 應用即能顯示出 Unity 在 800x480 解析度上的不便
首先, 螢幕上方的 toolbar 並無任何設定選項
由於高度不夠, gcin icon 就被截去了一段
側邊的 toolbar 很華麗, 整合了快速啟動與程式切換的功能
於是, 高度就在上方的 toolbar 與 視窗 titlebar 雙重的浪費下, 垂直顯示範圍縮小不少
不若原有UI 在使用顯示面積上來得有效率
當然, 現今Netbook 提升至 10" 以上, 解析度上也高了一到兩階
誰還在乎EeePC 701的 800x480?
但是手持裝置的 MID(ex: SmartQ5/Q7), 中小型Tablet 這樣的解析度也是常有
然而以定位看來 Unity 目標與適用範圍在於解析度夠高的 Netbook 與 iPad 等級的 Tablet
這樣的結果看來也是無可厚非
2010年6月15日 星期二
VP8 spec study - Chapter 4 壓縮資料格式概論
每個frame的 bitstream 包含了3個以上的部份. 開頭為未壓縮資料, 在 intra frame 為 10 bytes, inter frame 為 3 bytes. 緊接著的是2個或以上的段落(被稱為 partition), 每個 partition 皆為 byte alignment.
第一個 partition 包含兩個段落
1. 套用於整個 frame 的 header 資訊
2. per-macroblock 資訊, 指定讓 decoder 推測 macroblock 內容的 prediction mode.
macroblock 資訊以 raster-scan 方式存放.
剩餘的 partition 包含了每個 macroblock 用以計算 residue signal 的 DCT/WHT 參數(coefficient). 這部份大約佔用 70% 的資料量. VP8 支援將序列的 macroblock 壓縮後之 DCT/WHT 參數, pack 為分開的數個 partition. 若有不只一個 partition 用以存放這些 DCT/WHT 參數, 除了最後一個 partition 之外, 每個 partition 的位元長度, 以 little endian/3bytes 格式存放於每個 partition 的開頭. 長度欄位使得 decoder 能夠一次存取數個 partition, 平行處理這些參數.
將 predicton data 與 coefficient data 分開於不同的partiton存放, 允許 decoder 的實作更有彈性. 實作可能先存放 frame prediction 資料, 之後再計算 frame 的 residue signal. 也有可能同時處理兩個 partition 資料以 macroblock 為單位計算 prediciton 與 residue signal.
不同的 partition 必須以分開的 entropy decoder 解壓縮. 而 in-partition 的搜尋並不被支援.
第一個 partition 包含兩個段落
1. 套用於整個 frame 的 header 資訊
2. per-macroblock 資訊, 指定讓 decoder 推測 macroblock 內容的 prediction mode.
macroblock 資訊以 raster-scan 方式存放.
剩餘的 partition 包含了每個 macroblock 用以計算 residue signal 的 DCT/WHT 參數(coefficient). 這部份大約佔用 70% 的資料量. VP8 支援將序列的 macroblock 壓縮後之 DCT/WHT 參數, pack 為分開的數個 partition. 若有不只一個 partition 用以存放這些 DCT/WHT 參數, 除了最後一個 partition 之外, 每個 partition 的位元長度, 以 little endian/3bytes 格式存放於每個 partition 的開頭. 長度欄位使得 decoder 能夠一次存取數個 partition, 平行處理這些參數.
將 predicton data 與 coefficient data 分開於不同的partiton存放, 允許 decoder 的實作更有彈性. 實作可能先存放 frame prediction 資料, 之後再計算 frame 的 residue signal. 也有可能同時處理兩個 partition 資料以 macroblock 為單位計算 prediciton 與 residue signal.
不同的 partition 必須以分開的 entropy decoder 解壓縮. 而 in-partition 的搜尋並不被支援.
2010年5月20日 星期四
Google 公開 On2 VP8 Tech.
Google 又丟了一顆震憾彈, 在今日成立 WebM 計劃
該計劃以 BSD-License, royalty-free 方式公開釋出 VP8 格式標準與相關程式碼
並同時地在 Youtube HTML5 beta 支援中加入了 VP8 支援
儘管在Google 收購 On2 之後, 公開 VP8 的傳言就沒有斷過
但看到相關新聞的第一時間, 想法還只是圍繞在 VP8 規格
之後細看與思考後, 才體會到這樣作法的背後可能有著多強的效應
在視訊瀏覽服務以成為主流服務的今日
這些服務以往多半只仰賴著 Adobe Flash 技術
對於 Adobe 而言, Flash 平台可以說是金雞母, 對於 PC 有著極高的安裝率
因此也理所當然成為網頁動態/互動效果與多媒體服務的一時之選
然而對一些人對於Flash感到頭疼
像是問題早已存在於既有的智慧型手機使用者
因此手持裝置與非 x86 平台裝置開發商也對此感到感冒
著名的有如: 蘋果的 Jobs 因為不支援 Flash 問題而動怒,
ARM 也因為 Flash 延誤 Smartbook 市場策略而公開斥責
意會到手機使用者的潛在市場的網站, 也增加了HTML5 的支援 (scribd, youtube...)
這些林林總總與瀏覽器戰爭所帶來的教訓
人們都意識到與其寄望單一廠商的開放, 不如訴諸公開標準
在 Apple Inc. 提到 HTML5 後, 除了知名度大升之外, 的確也被人們寄予厚望.
然而HTML5只是格式, 對於多媒體支援並無侷限.
頓時瀏覽器都必須選邊站, 於是就成了經濟實力的角力
有錢人組的 Google, Microsoft, Apple 對於旗下瀏覽器HTML5 選擇支援 H.264
支援公開標準組的 Mozilla, Opera, ... etc 選擇支援 Theora(事實上這是On2 的VP3技術)
(這麼說是很簡化的說法, Google Chrome 也有支援 Theora)
一時間, HTML5 的視訊支援的選擇陷入了分歧, 且少有交集
H.264除了商業瀏覽器的採用外, 加上最大線上視訊服務 Youtube 採用
可以說 H.264 在 HTML5 的視訊服務採用上佔有極大優勢
或許 Google 意會到這與其網路服務業務有極大關係
選擇在這樣的方式提供了兩個陣營都可以接受的方案(微軟第一時間也決定 IE9 將支援 VP8)
同時地, Youtube HTML5 beta 服務也加入了 WebM(VP8) 的支援
也因此 VP8 非常有可能成為 HTML5 中最被廣泛採用的視訊格式.
儘管現在 Flash 依然在 Web 佔有相當重要的地位
然而在 Adobe 開放不足, 加上缺乏善意的情況下
當大眾有共識地要擺脫 Flash 的當下, Adobe 或許該好好反省
不然 Flash 很有可能要面臨成為另一個 Java 的窘境.
該計劃以 BSD-License, royalty-free 方式公開釋出 VP8 格式標準與相關程式碼
並同時地在 Youtube HTML5 beta 支援中加入了 VP8 支援
儘管在Google 收購 On2 之後, 公開 VP8 的傳言就沒有斷過
但看到相關新聞的第一時間, 想法還只是圍繞在 VP8 規格
之後細看與思考後, 才體會到這樣作法的背後可能有著多強的效應
在視訊瀏覽服務以成為主流服務的今日
這些服務以往多半只仰賴著 Adobe Flash 技術
對於 Adobe 而言, Flash 平台可以說是金雞母, 對於 PC 有著極高的安裝率
因此也理所當然成為網頁動態/互動效果與多媒體服務的一時之選
然而對一些人對於Flash感到頭疼
像是問題早已存在於既有的智慧型手機使用者
因此手持裝置與非 x86 平台裝置開發商也對此感到感冒
著名的有如: 蘋果的 Jobs 因為不支援 Flash 問題而動怒,
ARM 也因為 Flash 延誤 Smartbook 市場策略而公開斥責
意會到手機使用者的潛在市場的網站, 也增加了HTML5 的支援 (scribd, youtube...)
這些林林總總與瀏覽器戰爭所帶來的教訓
人們都意識到與其寄望單一廠商的開放, 不如訴諸公開標準
在 Apple Inc. 提到 HTML5 後, 除了知名度大升之外, 的確也被人們寄予厚望.
然而HTML5只是格式, 對於多媒體支援並無侷限.
頓時瀏覽器都必須選邊站, 於是就成了經濟實力的角力
有錢人組的 Google, Microsoft, Apple 對於旗下瀏覽器HTML5 選擇支援 H.264
支援公開標準組的 Mozilla, Opera, ... etc 選擇支援 Theora(事實上這是On2 的VP3技術)
(這麼說是很簡化的說法, Google Chrome 也有支援 Theora)
一時間, HTML5 的視訊支援的選擇陷入了分歧, 且少有交集
H.264除了商業瀏覽器的採用外, 加上最大線上視訊服務 Youtube 採用
可以說 H.264 在 HTML5 的視訊服務採用上佔有極大優勢
或許 Google 意會到這與其網路服務業務有極大關係
選擇在這樣的方式提供了兩個陣營都可以接受的方案(微軟第一時間也決定 IE9 將支援 VP8)
同時地, Youtube HTML5 beta 服務也加入了 WebM(VP8) 的支援
也因此 VP8 非常有可能成為 HTML5 中最被廣泛採用的視訊格式.
儘管現在 Flash 依然在 Web 佔有相當重要的地位
然而在 Adobe 開放不足, 加上缺乏善意的情況下
當大眾有共識地要擺脫 Flash 的當下, Adobe 或許該好好反省
不然 Flash 很有可能要面臨成為另一個 Java 的窘境.
2010年5月18日 星期二
Linux kernel 2.6.34
Linux kernel 2.6.34 日前釋出了, 在 OSNews 與 slashdot 上已看得到相關新聞訊息
概略的 kernel change log 可以參考 KernelNewbies
除此之外, 推荐 The H Open 的在釋出之前就針對 Linux kernel 2.6.34 系列介紹文章
Kernel Log: Coming in 2.6.34 (Part 1) - Network Support
Kernel Log: Coming in 2.6.34 (Part 2) - File Systems
Kernel Log: Coming in 2.6.34 (Part 3) - Graphics
Kernel Log: Coming in 2.6.34 (Part 4) - Architecture and Virtualisation
Kernel Log: Coming in 2.6.34 (Part 5) - Drivers
若是覺得把"落落長"的五篇看完太耗費精神,
還可以看The H Open在釋出後的概略介紹文 - What's new in Linux 2.6.34
個人覺得 slashdot 上第一則 comment 真的蠻無厘頭搞笑的..XD
概略的 kernel change log 可以參考 KernelNewbies
除此之外, 推荐 The H Open 的在釋出之前就針對 Linux kernel 2.6.34 系列介紹文章
Kernel Log: Coming in 2.6.34 (Part 1) - Network Support
Kernel Log: Coming in 2.6.34 (Part 2) - File Systems
Kernel Log: Coming in 2.6.34 (Part 3) - Graphics
Kernel Log: Coming in 2.6.34 (Part 4) - Architecture and Virtualisation
Kernel Log: Coming in 2.6.34 (Part 5) - Drivers
若是覺得把"落落長"的五篇看完太耗費精神,
還可以看The H Open在釋出後的概略介紹文 - What's new in Linux 2.6.34
個人覺得 slashdot 上第一則 comment 真的蠻無厘頭搞笑的..XD
2010年4月21日 星期三
VIA ARTiGO A1100 released
在facebook上注意到威盛電子(VIA) 本週釋出了新款 PicoITX-based 產品 ARTiGO A1100
與上一代產品 ARTiGO A1000 最大的不同點在於:
使用了新一代的 Via Nano 與 VX855 取代了原有的 Via C7 與 VX700
除了 Nano 所帶來的效能增進外
由於VX855的關係, 視訊播放的硬體支援除了提升到1080p外
格式上亦新增了H.264 (具有 CABAD, 看來應該到Main Profile)
此外 ARTiGO A1100還具備了 HDMI 界面
VIA 目的應該是想藉由強大的多媒體處理能力來吸引市場注目.
(而這也是採用 ATOM 平台需要額外成本加強的部份)
個人也在 facebook 上提到, 在 x86 市場操作/推廣上
VIA 市場策略應盡量提升 x86 在消費性電子的應用性
在主流的 Desktop/Notebook 上, 可以預見的是由於知名度, 與不願得罪intel等綜合因素
VIA x86 PC接受度上依然是個問題
加上提供的特性&價格上並無讓人眼睛一亮的感覺
接著, 不錯的平台就容易掩蓋在 CPU性能 與價格的單一評比之中..
購買請到此
2010年4月6日 星期二
Firmware 沒有那麼容易 不只 Function Call 來 Call 去...
個人於上個月底離職了
主要因素是需要一段時間休息運動和調養身體
這段空檔時間, 按照慣例一樣作了一些目標設定
算是去年一月空檔時弄Prex的延續, 然而平台已經不是S3C2440
在告一段落後, 希望能藉此能有更進一步的突破
回想這幾年, 由於工作因素不斷地在 linux 與 embedded os 間交錯
對於 firmware 相關工作日漸有些許不平之鳴
而這些林林總總, 多半在所謂良善管理與時程下而掩蓋
改寫"沒那麼簡單"歌詞: "Firmware 沒有那麼容易, 不只 Function Call 來 Call 去"
道出了 firmware 的甘苦辛酸
若以公司為出發點的角度去思考
Firmware 最大的困難之處或許不在於 coding 實作本身
而是在於相關工作難免接手的人來來去去.
這樣的情形下, 一旦 Firmware 在介面與架構缺乏良好規劃的前提
在接手/參與的人無法完全熟悉的情況下, 為了盡快地完成任務, 也只能依樣畫葫蘆
只是如此時間一拉長, 經手的人一多, 就會轉變為一個悲劇.
換來的是, 日漸膨脹混亂, 開發與除錯時間逐漸地延長.
即便在此看來簡短而淺顯易懂, 但諷刺的地方在於, 這部分很容易被管理階層所忽略
這裡舉個常見現象作為例子
一個以 MP3 player作為起始產品時可能僅支援 MP3
而在 IC 中需要 Hw 需要的功能是 Audio playback, SD Card, LED display, Buttons.
軟體上需要的就是 FAT FileSystem 與 MP3 decoder
硬體的 Audio Hw 通常透過 Interrupt 去擷取需要輸出的 audio buffer
這個 case 就是 mp3 decoder output buffer.
接著藉由某種 message 傳遞通知 decoder 繼續 decode
這樣的情況下, 很有可能的方式就是直接在 ISR 中取用 MP3 decoder buffer
然而隨著 audio 格式一多 aac, ogg ... etc
依樣畫葫蘆的結果就是針對不同codec的一堆Audio ISR
最後就是演變成 policy 與 mechanism 混亂的情形
隨著規格要求不同有不同與交錯混亂的 path
這樣的問題並不侷限在這方面, 而是廣泛見於各種軟硬體程式介面上
像是 File System, 多半好一點都會將 FS 與 flash device 做個 layer
慘一點的 flash device 與 filesystem 混著寫也是有的
鮮少見再將 SD/NAND/NOR 的 protocol 與 device 分離的實作
更不用再多說由於多數Firmware 的 monolithic 特性
很容易在缺乏訓練之下或是為了急就章, 任意呼叫不適當的 function
因而造成日後專案維護性與移植性的低落
的確很多時候是用不到 Linux 這樣龐大架構的系統
然而相對而言的lightweight OS更需要心力去維護良架構.
最後是之前隨手改的詞, 博君一笑..
=================================================
沒那麼簡單 就能寫出想要的方案
尤其是在 firmware 年久失修又雜亂
總是不安 只好硬幹
誰謀殺了我的責任感
沒那麼簡單 就能去改 別的全不看
變得實際 也許好也許壞各一半
不愛加班 一久也習慣
被老婆唸勝過被老闆狗幹
靈感來了就快Coding去
感覺累了就聊天打屁
主管的意見 隨便聽一聽 自己作決定
開會不想投入情緒
一杯咖啡配coding
在周五晚上 關上了手機 免得六日被Call去
Firmware沒有那麼容易 不只 function call來 call去
過了有理想的年紀 架構翻新不如穩定
架構沒有那麼容易 才會特別讓人著迷
剛出社會的年紀
曾經最用心 所以最開心 曾經
主要因素是需要一段時間休息運動和調養身體
這段空檔時間, 按照慣例一樣作了一些目標設定
算是去年一月空檔時弄Prex的延續, 然而平台已經不是S3C2440
在告一段落後, 希望能藉此能有更進一步的突破
回想這幾年, 由於工作因素不斷地在 linux 與 embedded os 間交錯
對於 firmware 相關工作日漸有些許不平之鳴
而這些林林總總, 多半在所謂良善管理與時程下而掩蓋
改寫"沒那麼簡單"歌詞: "Firmware 沒有那麼容易, 不只 Function Call 來 Call 去"
道出了 firmware 的甘苦辛酸
若以公司為出發點的角度去思考
Firmware 最大的困難之處或許不在於 coding 實作本身
而是在於相關工作難免接手的人來來去去.
這樣的情形下, 一旦 Firmware 在介面與架構缺乏良好規劃的前提
在接手/參與的人無法完全熟悉的情況下, 為了盡快地完成任務, 也只能依樣畫葫蘆
只是如此時間一拉長, 經手的人一多, 就會轉變為一個悲劇.
換來的是, 日漸膨脹混亂, 開發與除錯時間逐漸地延長.
即便在此看來簡短而淺顯易懂, 但諷刺的地方在於, 這部分很容易被管理階層所忽略
這裡舉個常見現象作為例子
一個以 MP3 player作為起始產品時可能僅支援 MP3
而在 IC 中需要 Hw 需要的功能是 Audio playback, SD Card, LED display, Buttons.
軟體上需要的就是 FAT FileSystem 與 MP3 decoder
硬體的 Audio Hw 通常透過 Interrupt 去擷取需要輸出的 audio buffer
這個 case 就是 mp3 decoder output buffer.
接著藉由某種 message 傳遞通知 decoder 繼續 decode
這樣的情況下, 很有可能的方式就是直接在 ISR 中取用 MP3 decoder buffer
然而隨著 audio 格式一多 aac, ogg ... etc
依樣畫葫蘆的結果就是針對不同codec的一堆Audio ISR
最後就是演變成 policy 與 mechanism 混亂的情形
隨著規格要求不同有不同與交錯混亂的 path
這樣的問題並不侷限在這方面, 而是廣泛見於各種軟硬體程式介面上
像是 File System, 多半好一點都會將 FS 與 flash device 做個 layer
慘一點的 flash device 與 filesystem 混著寫也是有的
鮮少見再將 SD/NAND/NOR 的 protocol 與 device 分離的實作
更不用再多說由於多數Firmware 的 monolithic 特性
很容易在缺乏訓練之下或是為了急就章, 任意呼叫不適當的 function
因而造成日後專案維護性與移植性的低落
的確很多時候是用不到 Linux 這樣龐大架構的系統
然而相對而言的lightweight OS更需要心力去維護良架構.
最後是之前隨手改的詞, 博君一笑..
=================================================
沒那麼簡單 就能寫出想要的方案
尤其是在 firmware 年久失修又雜亂
總是不安 只好硬幹
誰謀殺了我的責任感
沒那麼簡單 就能去改 別的全不看
變得實際 也許好也許壞各一半
不愛加班 一久也習慣
被老婆唸勝過被老闆狗幹
靈感來了就快Coding去
感覺累了就聊天打屁
主管的意見 隨便聽一聽 自己作決定
開會不想投入情緒
一杯咖啡配coding
在周五晚上 關上了手機 免得六日被Call去
Firmware沒有那麼容易 不只 function call來 call去
過了有理想的年紀 架構翻新不如穩定
架構沒有那麼容易 才會特別讓人著迷
剛出社會的年紀
曾經最用心 所以最開心 曾經
2010年3月14日 星期日
OpenGL 4.0 specification released.
上週引起廣大討論的新聞莫過於 OpenGL 4.0 規格的釋出
眼尖的人可以發現 GLSL 的版本編號與 OpenGL 一致了
(不再像以往有著不同的編號: ex: GLSL 1.4 - OpenGL 3.1, GLSL 1.5 - OpenGL 3.2)
同一時間 OpenGL 3.3 規格也釋出了
OpenGL 3.3主要目的在於盡可能導入4.0的功能, 提供OpenGL 3.x世代硬體所能利用的 4.0 特性
詳細關於 4.0 的介紹可以參考這篇
特別的新功能在於
1. 兩個新的 shader 來處理 geometry tesselation
2. 能夠使用 OpenGL/OpenCL 計算出的資料來繪圖 ( 如此將可大幅降低CPU運算, 也降低CPU 對於CG, Gaming 的重要性, 可以預期的是與其花大錢買高速CPU, 其效應可能不如省下來買張中階顯卡還有找 )
3. shader 支援 倍精準(double) 浮點數運算, 以增進繪圖的正確性與品質.
Linux kernel 2.6.33
Linux kernel 2.6.33 在 Feb 24th, 2010 釋出了
主要的更動可以參考 kernelnewbies 與 H-Online 的What's new in linux 2.6.33這篇
這個版本受到注目在於
1. 整合Nouveau - open source nvidia 3D driver (Nvidia 並無提供協助, 主要是以逆向工程實作)
2. 整合DRBD - Distributed Replicated Block Device, 能視為基於網路的 RAID-1 實作
3. 整合Compcahe - 提供 Ram-Based Compressed Swap Device, 主要是切割出一塊記憶體空間, 將需要swap-out page資料, 壓縮後存放. 如此達到在記憶體中放置更多page 的目的, 減少 Harddisk IO(現今 CPU 壓縮/解壓縮 速度勝過對 HardDisk 讀寫), 提高效能.
4. Android removed from the linux kernel - 相關細節請參考 Android and the Linux kernel community (關於文章作者Kroah), 在今年二月初時此事在各大資訊相關網站廣受討論.
主要的更動可以參考 kernelnewbies 與 H-Online 的What's new in linux 2.6.33這篇
這個版本受到注目在於
1. 整合Nouveau - open source nvidia 3D driver (Nvidia 並無提供協助, 主要是以逆向工程實作)
2. 整合DRBD - Distributed Replicated Block Device, 能視為基於網路的 RAID-1 實作
3. 整合Compcahe - 提供 Ram-Based Compressed Swap Device, 主要是切割出一塊記憶體空間, 將需要swap-out page資料, 壓縮後存放. 如此達到在記憶體中放置更多page 的目的, 減少 Harddisk IO(現今 CPU 壓縮/解壓縮 速度勝過對 HardDisk 讀寫), 提高效能.
4. Android removed from the linux kernel - 相關細節請參考 Android and the Linux kernel community (關於文章作者Kroah), 在今年二月初時此事在各大資訊相關網站廣受討論.
2010年3月8日 星期一
from linux thread to protothread
去年在使用 buildroot/uClibc 環境移植 linux 過程中
由於編譯時對於 thread 選項選取預設的 linuxthreads 而非較為完整的 NTPL
因 thread 行為模式的緣故, 造成 IP 廠商提供的 OpenGL ES 環境無法正常運作
當時觀察到主要的錯誤在於每個 thread 取得的 pid 是不相同的
明顯地, 這不符合 thread 一般的認知, 然而這也與 linux thread 實作演進有相當的關係
(而linuxthreads 演進到 NTPL 的過程, 請參考 wikipedia 上的關於linux thread的歷史, 這裡就不詳加說明.)
在碰到這樣結果的當下, 稍微感到有些訝異
現今 thread 的概念在 OS 教科書中是一大重點
而 thread programming tutorial/guide 更是垂手可得
利用 thread 來改善系統效能, 更是常見於日常的程式中
這些資訊多到讓人產生一種 thread 的存在是理所當然似地
看著 wikipedia 中對於 thread 的說明, 跟教科書其實相去不遠
撇開 user-level/kernel-level 的優缺 和 1:1, N:1, N:M 的 Model 不同的理論不談
kernel-level threads 間的 context switch 可能可以較容易理解, 或是寄情於OS的能力
其中最引人入勝的莫過於 user-level threads 間又是如何達成的?
對於 user-level thread 的考量點有二
1. 如何於 user space 維護 thread context
2. thread switch 的時機點
preemptive or non-preemptive
其中 1.又取決於針對 2.的考量決定複雜的程度
可以想見, 可能必須在 process 中建構屬於 thread 的context
從 PC register, stack, 甚至可能細到 signal, 取決於實作的規劃
複雜者可能如 FSU Thread 在user-level 中實作了 POSIX thread
另外常見的 user-level thread 方式是提供特定的 I/O 與 switch API
讓 programmer 決定可以選擇切換的時機
這類者像GNU Portable Thread 即為一例
對於 GNU Pth 的細節技術可以參考這篇論文
主要在於使用泛 unix 的 ucontext/setjmp 支援
然而確也可能簡單到像 Contiki 中使用的 protothread
(與 coroutine 不同的地方在於 protothread 是 stack-less)
其概念可以拜讀 Simon Tatham 關於 coroutine 的大作
jserv 於 2006 年也對 coroutine 做了簡單的介紹
其精神在於僅存放 thread 所在的狀態, 以利於切換時跳至正確的位置
由於不停地在 thread 中切換, 若 thread 的 execution time 過小
搭配 sleep 的時機不佳, 簡單者是浪費 cpu 的 busywaiting
然而延伸而言, 卻也會影響 scheduling 與 cpu freqency 切換的判斷
而需要 computation 時, thread 間執行時間的比例, 與 sleep 可能造成降低效能
而這些都與使用 user-level thread API 實作 thread routine 的方式有很大的關係
儘管 thread 帶給 programmer 許多便利性
然而需要注意 thread 在各種環境下的特性, 才能夠正確地使用
由於編譯時對於 thread 選項選取預設的 linuxthreads 而非較為完整的 NTPL
因 thread 行為模式的緣故, 造成 IP 廠商提供的 OpenGL ES 環境無法正常運作
當時觀察到主要的錯誤在於每個 thread 取得的 pid 是不相同的
明顯地, 這不符合 thread 一般的認知, 然而這也與 linux thread 實作演進有相當的關係
(而linuxthreads 演進到 NTPL 的過程, 請參考 wikipedia 上的關於linux thread的歷史, 這裡就不詳加說明.)
在碰到這樣結果的當下, 稍微感到有些訝異
現今 thread 的概念在 OS 教科書中是一大重點
而 thread programming tutorial/guide 更是垂手可得
利用 thread 來改善系統效能, 更是常見於日常的程式中
這些資訊多到讓人產生一種 thread 的存在是理所當然似地
看著 wikipedia 中對於 thread 的說明, 跟教科書其實相去不遠
撇開 user-level/kernel-level 的優缺 和 1:1, N:1, N:M 的 Model 不同的理論不談
kernel-level threads 間的 context switch 可能可以較容易理解, 或是寄情於OS的能力
其中最引人入勝的莫過於 user-level threads 間又是如何達成的?
對於 user-level thread 的考量點有二
1. 如何於 user space 維護 thread context
2. thread switch 的時機點
preemptive or non-preemptive
其中 1.又取決於針對 2.的考量決定複雜的程度
可以想見, 可能必須在 process 中建構屬於 thread 的context
從 PC register, stack, 甚至可能細到 signal, 取決於實作的規劃
複雜者可能如 FSU Thread 在user-level 中實作了 POSIX thread
另外常見的 user-level thread 方式是提供特定的 I/O 與 switch API
讓 programmer 決定可以選擇切換的時機
這類者像GNU Portable Thread 即為一例
對於 GNU Pth 的細節技術可以參考這篇論文
主要在於使用泛 unix 的 ucontext/setjmp 支援
然而確也可能簡單到像 Contiki 中使用的 protothread
(與 coroutine 不同的地方在於 protothread 是 stack-less)
其概念可以拜讀 Simon Tatham 關於 coroutine 的大作
jserv 於 2006 年也對 coroutine 做了簡單的介紹
其精神在於僅存放 thread 所在的狀態, 以利於切換時跳至正確的位置
由於不停地在 thread 中切換, 若 thread 的 execution time 過小
搭配 sleep 的時機不佳, 簡單者是浪費 cpu 的 busywaiting
然而延伸而言, 卻也會影響 scheduling 與 cpu freqency 切換的判斷
而需要 computation 時, thread 間執行時間的比例, 與 sleep 可能造成降低效能
而這些都與使用 user-level thread API 實作 thread routine 的方式有很大的關係
儘管 thread 帶給 programmer 許多便利性
然而需要注意 thread 在各種環境下的特性, 才能夠正確地使用
2010年1月9日 星期六
HiRadioTray 20100109 & Hinet Radio Script 20100110
HiRadioTray 20100109
檔案連結: HiRadioTray_20100109_ubuntu910_i386.deb
1. 根據 Hinet 更動了 mms 取得方式
2. 修正 奇美古典音樂網 格式
3. 修正更新功能
由於個人疏忽, 20091010版無法使用更新功能
使用 20091010 版本的使用者:
安裝更新檔者:
請移除 ~/.HiRadioTray 目錄後再執行程式即可
不想安裝更新檔者
請到此下載 update.sh 並覆寫原本 ~/.HiRadioTray 下的檔案, 以修正更新功能
請到此下載 get_mms.sh 並覆寫原本 ~/.HiRadioTray 下的檔案, 以修正收聽功能
Hinet Radio Script 20100110
檔案連結: radio_20100110.tgz
或執行 update.sh 更新即可
檔案連結: HiRadioTray_20100109_ubuntu910_i386.deb
1. 根據 Hinet 更動了 mms 取得方式
2. 修正 奇美古典音樂網 格式
3. 修正更新功能
由於個人疏忽, 20091010版無法使用更新功能
使用 20091010 版本的使用者:
安裝更新檔者:
請移除 ~/.HiRadioTray 目錄後再執行程式即可
不想安裝更新檔者
請到此下載 update.sh 並覆寫原本 ~/.HiRadioTray 下的檔案, 以修正更新功能
請到此下載 get_mms.sh 並覆寫原本 ~/.HiRadioTray 下的檔案, 以修正收聽功能
Hinet Radio Script 20100110
檔案連結: radio_20100110.tgz
或執行 update.sh 更新即可
訂閱：
文章 (Atom)
-
現今對於 Daily Linux Developer / User 面對不同程式/開發版本環境感到很頭疼, 常常疲於 執行舊版程式需要安裝舊版本 Library, 設定 RPATH / LD_LIBRARY_PATH 開發需求建立不同的版本 SDK 開發/執行環境, 在較舊系統... -
這幾年個人在影像處理程式優化的領域打滾, 如果問到感到棘手的工作, floating point 的處理應該可以排上很前面的名次 在許多演算來說由於同時對於 precision 與 dynamic range 的需求, 因此在計算過程中對於浮點數的使用是非常常見的 (若要避免... -
這版是新增預約錄音前的整理版本 本版本開始產生 .deb file 新功能為 斷線偵測, 自動重新連線(基本錄音功能顯示STOPPPED) source code: HiRadioTray_20091010-2.tgz Ubuntu 9.04 x86 deb package: H...