IC 設計公司買 IP 的時候要考慮什麼呢？我的朋友 Yiyung 給了我一些忠告. 我怕我很快就會忘光光, 所以編了個口訣來幫助記憶. 這個口訣就叫做 problem.
P – power consumption, price issue. people handles it.
R – reference, 問問用過的人. 對 video IP 又指 reference frame 的數目, 存放方式是 tile 還是 raster scan.
O – 需要 over-clock 嗎？達到我們需要的功能, 需要多少 clock frequency? Open to public SW library?
B – bandwidth, 它需要多少? 能不能配合 bus arbiter.
L – latency, 對外部的記憶體存取需要多少 μsec?
E – error, 發生 error 時怎麼處理？
M – memory size, 它會用到多少 memory, 包括內部的 SRAM.
QMF 這裡指的是 Quadrature Mirror Filter. 它通常在訊號處理中, 將訊號分解為高低兩個頻帶 (band). 要分成高低兩個頻帶的方法有很多, 大家可能會先想到小波 (wavelet). 根據我的印象, 課本的習題中先出現 QMF, 後來小波才紅起來. 果然, Google 上說, QMF 早在 1976 年就出現了.
既然 QMF 的名字裡面有 mirror, 我們很容易記住它具有對稱性. 兩個 filter 分別是 low pass filter H0 和 high pass filter H1 的話:
H1(z) = H0(-z)…………….. frequency domain
h1(n) = (-1)nh0(n)………………. time domain
至於 quadrature 這個字, 說明它的正交特性. 正交這件事可以想像成透過兩個偏光鏡濾光, 透過水平濾光後的光線, 再透過垂直濾光就變成不透明, 但透過另一次水平濾光還可以順利通過. 把通過垂直和正交濾波的光線相加, 可以再還原回原始的光線的話, 稱為完全還原 (perfect reconstruct). QMF 就具備有這個性質.
因此在訊號處理上, 可以先利用 QMF 把訊號分成高低頻兩個部分, 並且將已經減半的訊號量做降頻以減少計算量. 廣義地來說, QMF 可以泛指兩個頻段以上的訊號分解 [2].
由於此處有降頻和升頻的步驟, 當我們要把一個 96 KHz 的時域訊號和一個 48KHz 的頻域訊號相加時, 理論上我們可以讓 96 KHz 的訊號先通過 H0 和 H1. 把 48 KHz 訊號的頻域加到 H0 上, 再讓他們通過 G0, G1 , 以做出兩者相加的後的時域訊號.
[Ref]
1. Two-Channel Quadrature-Mirror Filter Bank
2. Quadrature mirror filter – Wikipedia, the free encyclopedia
自從聽說過把發票存入悠遊卡可以自動對獎之後, 我對這個流程產生了興趣. 不過聽說還需要自然人憑證才能搞定, 所以一直沒時間動手. 十幾年前, 可能是因為在工研院上班的關係, 我也當過自然人憑證的白老鼠. 當時申請了一個憑證, 存在 1.44MB 的軟碟當中, 從來也沒有用到的機會. 這次剛好週六遇到公家機關補班而我們公司放假, 趁機去辦了一張自然人憑證的晶片卡.
把電子發票歸戶到個人帳戶的過程, 大概分成幾個重點:
1. 買一個晶片讀卡機, 如果電腦不認得它, 可能需要安裝驅動程式.
2. 辦理自然人憑證. 帶著 275 元, 身分證正本就可以去戶政事務所辦了 (可跨區). 網站上說要先填一張表格節省時間. 不過這張表最後沒被收走, 看來只是讓承辦人員方便 key in 而已. 他們會讓我們在幾張打印出來的資料上簽名, 以確認個人資料無誤, 像是用戶代號, 郵件信箱等等.
3. 到內政部憑證管理中心網站變更自然人憑證 PIN 密碼.
4. 到 財政部電子發票整合服務平台 登記未來發票中獎後要匯入的帳戶. 此網站會要求執行 ActiveX, 而且速度挺慢的. IE10 的 ActiveX 選項不知道要從哪邊開? 但我直接把這個站加入信任的網站也就行了. 要注意瀏覽器的部分也只支援 IE 而已.
5. 登入網站後的細節可以參考這一篇:
如果不在網站上設定, 也可以在便利商店的 ibon 操作. 只是相較之下, 在家裡設定還是比較隱密與方便.
6. 走到這一步還差載具的設定. 所謂的載具包括手機條碼、悠遊卡、晶片卡、會員卡、金融卡等等. 電子發票先存到載具, 然後中獎的發票才能進到個人帳戶.
7. 如果載具是手機條碼, 請參考這一篇: 手機條碼當做電子發票載具, 申請、購物、查詢實戰. 據說手機條碼的圖檔不能直接被辨識, 非得印出來不可, 這點真是很可惜. 把條碼貼在手機上未免醜了點. 除了把發票留給自己, 我們也可以做愛心, 把社福團體的條碼印出來使用. 店家可以直接把電子發票捐給這些單位. 最新版本請到查詢社福團體愛心碼網站下載一個 PDF 檔.
[更正] 根據網友 E2 的說法, 手機可以直接顯示條碼的圖檔.
特別要注意的是: email 帳號需要被驗證過 – 和註冊 BBS 相同, 還有一個手機驗證碼要牢記, 它是透過簡訊寄到手機的, 和自然人憑證的 PIN 驗證碼完全無關, 不要搞混了.
8. 其他的晶片卡載具設定請參考這一篇 電子發票歸戶教戰手冊，自動對獎、中獎直接匯入戶頭. 他已經分門別類地把 iCash／金融卡 / 悠遊卡 / 會員卡如何歸戶都介紹完了. 除了悠遊卡是感應式的之外, 其它好像都能在家裡自己操作.
我在 7-11 操作 ibon 的時候發現一個貼心的功能, 那就是可以把優遊卡的卡號和驗證碼 email 到我們的信箱, 這樣就可以避免不小心抄錯了. 畢竟這裡又是 20 個英數字要記.
把優遊卡載具登錄完後, 在財政部電子發票整合平台的載具管理列表中, 看到自己已經登錄的悠遊卡的領獎方式竟然只是 “自行領取"? 這怎麼行呢? 原來還要在會員管理那項裡面啟用銀行帳號, 接著才能看到悠遊卡載具可以選擇 “銀行帳戶". 差點因為沒有啟用而功虧一簣.
9. 最後是消費, 並且告知店家不要把發票印出來, 直接存在載具裡面. 或是依愛心碼捐贈出去. 這樣就大功告成了.
由於很多人都認為 Android 3.0 以前, Android 只用軟體畫圖, 所以 Android 的人跑出來澄清. 雖然這篇文章已經有點久了, 正好可以呼應我上一篇的貼文. 有興趣的人可以去看原版 Dianne Hackborn 的 Google+, . 我在這邊只摘要幾個重點.
1. Android 從 1.0 版就使用硬體加速視窗的的疊加 (all window compositing to the display has been done with hardware), 當然有的時候會用軟體. 下圖共包含四層視窗 (windows): Wall Paper, Launcher, Menu, Status Bar. 如果使用者操作 menu, 只有 menu 會用軟體重畫. 而疊加 (overlay) 的部分和整張畫面滑動的效果則是用硬體做.
2. Android 3.0 開始全部由硬體加速, 4.0 也是一樣. 只不過 Android 3.0 會檢查 App 在 manifest 裡面的 “android:handwareAccelerated="true" 這行 , 以決定是否用硬體加速. 而 Android 4.0 預設就是全部用硬體加速. 這麼一來, 原本只需要局部 UI 更新的狀況也不再交給比較有效率的軟體來執行了; 如此一來導致了一些副作用.
3. 其他用硬體加速的缺點包括浪費記憶體, Imagination Tech 的繪圖驅動程式基本上要吃掉 8MB RAM. 剩餘的 RAM 變少了, 其它的背景程式就會變慢. 因此, status bar 其實不需要用 OpenGL (GPU) 來畫. Android 4.0 就把這部分單獨用軟體處理.
4. 蘋果的 IOS 怎麼做呢? 以瀏覽器為例, IOS 把網頁的畫面以 display list 的方式來畫, 因此沒有什麼更新區域的概念, 整個頁面都要重畫. 這麼做的優點是捲動或試放大縮小的時候不會看見破圖 (artifact) – 假如畫面是分成幾個區塊 (title) 來分別渲染的話, 就可以會有 artifact. 後者恰好就是 Android 的做法, 它比較能夠對抗複雜的頁面而不致於變慢, 因此光是用軟體就可以在 Nexus S2 畫出每秒 60 楨 (60 fps). 作者說他相信 IOS 也是用軟體畫的.
5. 為了解決 GPU 不夠力的問題, Android 還是有用 HW overlay, 而且把底圖 (backgound) 放的比螢幕還大. 這樣一來, 使用者捲動畫面的時候, 底圖就不需要重畫, 只是改個座標 (offset) 而已.
6. 當我們用 CPU 畫 UI 的時候, 多核心並沒有幫助. 因為幫一個 app 繪製 UI 的時候, 沒辦法做平行處理. 這就是為什麼 Android 要用 GPU 加速. 在去年年底 Galaxy S2 出來的時候, ARM 的 CPU (大約是 CA9 1GHz) 還不能畫到 720×1280 的 UI (60 fps), 因此更細緻的解析度都必須仰賴 GPU 來畫.
以下再補充更多的觀點:
7. Android 官網的說法: GPU 擅長放大縮小, 旋轉, 平移, 但是不擅長畫直線和曲線. 所以要多用其長, 少用其短.
8. Qualcomm 說 Android 在他們的 Snapdragon 可以用 GPU 做 composition (也就是不用 HW overlay):
如果 graphic UI (user interface) 和 video 沒有同步, 那麼一般人腦海中的狀況是這樣:
Qualcomm 說: video 可以當作圖形處理中的紋理 (texture), 所以簡單多了.
看到這個題目在 wiki 只有英文和韓文, 忍不住想寫一個中文的精簡版. 不過寫著寫著就偏離主題, 變成了 Android 為何不全面支持 HW Overlay?
我們在 Windows 螢幕上看到的畫面, 基本上是由視窗疊加而成的, 前景擋住後景, 就成了我們看到的模樣. 在其他有視訊輸出的產品中, 同樣會有物件互相遮蔽的現象, 例如: 字幕浮現在電影上, 這樣就是兩個個物件. 如果再加上進度條 (progress bar), 就變成 3 個物件. 當繪圖系統需要依序畫出這三個物件時, 可以用軟體去檢查前後順序, 只把需要的部份畫出. 在 Android 系統中, Surface Flinger 就在做這件事 [註1].
既然有軟體的解法, 硬體解法會不會更快更有效率呢？是的, HW overlay 就是這個硬體的解法. 當每個物件都畫在自己的記憶體, 最後再依據每個物件的先後順序和透明度 (alpha blending) 一次疊加, 那麼每個物件就不用等來等去, 只要各畫各的就好. 如此一來, 雖然浪費了好幾塊記憶體, 控制卻變得很簡單. 特別是物件的更新速率差異很大時, 互等會導致大量浪費頻寬 – 例如電影 (30~60Hz) 與字幕 (大約 0.2~0.5 Hz).
| Surface Flinger | HW Overlay |
|
|
上面這張圖有個小問題, 就是把 SurfaceFlinger 和 Overlay 畫成兩個獨立的模組. 實際上, 在 Android 中, HW Overlay 和 Surface Flinger 關係密切. HW Overlay 算是 SurfaceFlinger 的一個特例 [註 2]. 請參考下圖.
現在的 IC 幾乎都有 HW overlay 的能力, 應該沒甚麼好討論的, 可惜故事還沒有完. 大家如果把玩手上的 Android 手機或是平板, 可能會在設定裡面看到 “停用硬體重疊圖層" 這個選項. 既然 HW overlay 看起來比較好, 幹嘛把它停用呢？ 每一個 OpenGL 的 process 都需要 2~8MB 的 RAM, 浪費記憶體就不用說了. GPU 還要挺高檔才行 [註 3].
每秒可以畫 1000 M pixel/second 的 200MHz SGX544, 在 1920×1080@60FPS (frame per second) 的輸出螢幕上, 能在每個 pixel render 8.0375 次. 若是換成了 SGX531就只能 render 4 次 [註 4]. 這 4 次如果用來畫一層背景, 一層電影. 一層進度條和 OSD (on screen display), 一層字幕, 就已經達到 GPU 的硬體極限. 此時只是做到 HW overlay 的水準而已, 但什麼 3D 動畫效果都畫不出來了.
以上都是說 Android 的壞話, 但 Google 卻可以藉著不支援 HW Overlay 來統一硬體的差異, copybit 不就在 Android 4.0 上被拔掉了嗎? 若是放任每一家廠商製作的 HW Overlay 都不相同, 當然就限制了 APP (跨平台的) 的互通性. 再者, GPU 只要聰明地用, 不要常常 redraw 沒用的畫面, 效率還是不會太差 [註 3]. 按照 Android 的官方說法, 全部的畫面都能進入 GPU 的話, 使用者將可以得到更多樂趣! 至於 GPU 的計算能力….當然必須夠, 這不是 Android 的責任範圍, 它只是個做軟體的. [註5]
Media effects for transforming images and video
A set of high-performance transformation filters let developers apply rich effects to any image passed as an OpenGL ES 2.0 texture. Developers can adjust color levels and brightness, change backgrounds, sharpen, crop, rotate, add lens distortion, and apply other effects. The transformations are processed by the GPU, so they are fast enough for processing image frames loaded from disk, camera, or video stream.
[註]
1. Android Display (surfaceflinger and Overlay)
2. Android 显示系统
3. The truth about hardware acceleration on Android
4. PowerVR
Cash Chou's Blog 