Sony 放出 PS5 拆解影片...

Hacker News Daily 上看到 PS5 的拆解影片:「PS5 Teardown: An up-close and personal look at the console hardware」。

本來想說這種東西為什麼會上 Hacker News Daily,是有拆出什麼有趣的東西嗎... 後來看到一半才注意到這是 Sony 官方丟出來的影片,不是第三方拆機開箱影片 XDDD

然後回頭看發現這是 Sony 家的 VP 出來拍的:

基本上是個官方拆機指南,雖然影片開頭有警告自行拆機會有風險以及保固問題 XD

在一台電腦上多畫面與多鍵盤滑鼠操作遊戲:Universal Split Screen

Hacker News Daily 上看到這款工具,可以在 Windows 上把拆出多個畫面,並且提供給不同的鍵盤與滑鼠使用:「Universal Split Screen」,而且是 open source 專案 (使用 MIT License),程式碼在 UniversalSplitScreen/UniversalSplitScreen 這邊。

理論上只要不是太吃資源的遊戲,應該都適合這個方法搞 (從他列出來的遊戲列表看起來,似乎都不會太吃 CPU 與顯卡)。

另外在想是不是也可以拿給其他用途使用,像是 PuTTY 之類的程式?

自幹 VR 眼鏡

Hacker News Daily 上看到「Relativty‍ an open-source VR headset」這個自幹 VR 眼鏡的專案,專案可以在 GitHub 的「relativty/Relativty」這邊看到。

看起來是使用 3D 印表機生出配件,然後用 ArduinoCore-sam 開發軟硬體的部份,目前的系統可以在 2K 解析度下跑 120fps:

The Relativty firmware, which powers the actual physical device, is based on ArduinoCore-sam. So in addition to the Relativty Motherboard, it is compatible with Arduino Due or any other board equipped with a processor that supports the ArduinoCore.

Relativty headset runs a 2K dual-display at 120FPS. However, because of the open nature of Relativty you can use any display as long as your computer is able to handle it. From more affordable 90Hz 1080p screen to 4K panels.

不過不知道反應延遲有多高,偏高的話會有 3D 暈的問題,在網站裡面沒提到,我猜應該會是痛點... 另外看起來是想要商業化,頁面下面有 hiring 的資訊,先觀望看看好了?

證明圓周率 π 是無理數

前陣子在 Michael Penn 教授的 YouTube 頻道上看到的證明:

這個證明方式在其他人的 YouTube 頻道也有做過,像是 MindYourDecisions 在 2019/3/14 (Pi Day) 發表的影片:

這兩篇使用的方法是 Ivan M. Niven 在 1946 年提出來的方法 (發表在 1947 年 AMS 的期刊,第 53 期的 Bulletin of the American Mathematical Society 上):「A simple proof that π is irrational」。

先不討論證明方法本身,我把這份 PDF 印出來慢慢看,當年用打字機打的字型讀起來超有味道的... (這份 PDF 看起來是掃描檔)

從 PDF 可以看出證明超級短,只有一頁,但畢竟這是大師丟出來的證明,裡面其實省了很多步驟。這接步驟不難推導,但是是屬於考試作答時不能省略的部份,如果加上去的話應該會兩到三頁 (還是非常短)。

整個證明的過程很巧妙的設計了兩個函數搭配反證法。裡面有用到微積分,但只用到最基本的微積分,其中微分的部份用到的公式就這三個,其中是三角函數的微分公式:

\frac{d}{dx} sin(x) = cos(x)\newline\newline\frac{d}{dx} cos(x) = -sin(x)

然後是兩個函數相乘後的微分公式:

\frac{d}{dx} f(x)g(x) = f'(x)g(x) + f(x)g'(x)

積分的部份只用了定義的部份 (主要是在微分的部份證完)。

然後證明是圍繞在「整數」上面做文章,夾擠出一個不可能的情況,因此得到矛盾,證明了 π 是無理數。

整個證明可以在高三範圍 (如果現在高三還有教微積分的話) 或是大一教過微積分之後的程度證完,作者講的 "Simple" 主要是出自這邊...

KataGo 最近的進展

KataGo 是目前 open source 裡最強的計算引擎了,不過先前的缺點就是得透過 OpenCL 或是 CUDA 才能跑,所以基本上得有張夠力的顯示卡才行。

如果要想要在 CPU 上跑 (不透過硬體顯示卡),一種方式是透過 OpenCL 的方式模擬,在 Linux 下可以透過 pocl 達成,效能就普普通通,但算是會動的東西,不過 Windows 下好像不太好弄... 這也是先前蠻多人還是繼續使用 Leela Zero 的原因。

最近 KataGo 在 1.5 版實做了純 CPU 版本的程式碼,是透過 Eigen 這套 library 達成的,不過大家測過以後發現慢到爆炸 XDDD

因為作者沒有提供 CPU 版本的 binary,我自己在 Linux 下抓程式碼 compile 後測試發現只會用一個 CPU (沒有 multi threading),對比於在 1080Ti 上跑 OpenCL 版本大約 150 visits/sec (40b),但 CPU 版本是 0.0x visits/sec 啊 XDDD

作者自己在 GitHub 上討論時也有提到這個版本只有確認正確性,完全沒有考慮效能...

不過就有其他人跳出來改善了,在「Optimization of Eigen backend #288」這邊可以看到 kaorahi 拋出了不少修改,可以看到從一開始的 eigen_naive_loop (對比 1.5 版有 13x 的成長) 一路到 borrow_tensorflow (1400x) 的版本,使得在 CPU 上面跑 15b 也有 10 visits/sec 了:

"borrow_tensorflow" version: x1400 speed up from 1.5.0 (70% of libtensorflow backend). Now 15b net is usable for me. I get 19 visits/s in benchmark and 10 visits/s in GUI with 15b net.

這樣看起來已經快了不少,這樣子 Leela Zero 應該會逐漸淡出了,CPU-only 算是最後一塊 Leela Zero 還可以爭的地盤...

不停機把 server 搬到兩百米外的機房

Hacker News Daily 上看到的有趣故事,作者在 Reddit 上描述怎麼不停機把實體的伺服器搬到兩百米外的機房,中間還經過了停車場:「[Rant... sorta] Physically moved a server today...」,另外作者的 FAQ 在「[FAQ][Rant... sorta] Physically moved a server today...」這邊可以看到。

我會把這個當故事看一看就好,裡面還是有一些細節沒有被敘述 (像是網路不斷線的部份),感覺不太對,但就一個故事來看是蠻有趣的 XD

搬運的過程中間包括了使用 UPS 與多顆 switch 對接,另外中間經過一個停車場,算是很有趣的方式?

用純 HTML + CSS 做出來的踩地雷...

一樣還是 Hacker News Daily 上看到的東西,不過這個東西主要就是趣味性為主而已。這次看到的是純 HTML + CSS 做出來的踩地雷 (Minesweeper),沒有 JavaScript 在內:「css-sweeper from PropJockey」。

自從 HTML + CSS3 證明是 Turing-complete 後,再加上 CSS 本身又一直加各種互動性質的操作,出現這些東西好像不太意外就是了 XDDD

依照他的說明,這邊用到的 CSS 技巧主要是 Space Toggle 這個技巧 (也就是 --toggler 這個),但試著找了對應的文獻說明居然沒翻到,有人可以給個 hint 嗎...

Mass Effect 的 3D 場景黑塊問題一路追到 Intel/AMD 的 SSE2 指令集...

Mass Effect 是個 2007 在 Xbox 上推出的遊戲,並且在 2008 推出 Windows 版,這個遊戲在 2011 年 AMD 推出的 CPU 上 (Bulldozer),某些場景會產生人物黑塊的 bug,社群有些猜測但一直都沒被證實,作者一路追出不少問題,並且給了一個還算乾淨的 workaround:「Fixing Mass Effect black blobs on modern AMD CPUs」,另外在 Hacker News 上有很精彩的討論:「Fixing Mass Effect black blobs on modern AMD CPUs (cookieplmonster.github.io)」。

這篇主要是看趣味的,裡面的狀況有點複雜。

社群有一些 workaround 可以避開這個問題,作者後來是從關閉 PSGP (Processor Specific Graphics Pipeline) 的方法找問題,然後發現在計算時會產生出 NaN 的問題,所以導致貼出來的圖就變成黑塊了...

一路追下去,發現遊戲本身好像沒什麼大問題,但跟 Direct3D 裡面的 D3DXMatrixInverse 有關,會依照 CPU 的支援度決定怎麼跑:

  • Disabling PSGP makes both Intel and AMD take a regular x86 code path.
  • Intel CPUs always take an intelsse2 code path.
  • AMD CPUs supporting 3DNow! take a amd_mmx_3dnow or amd3dnow_amdmmx code path, while CPUs without 3DNow take an intelsse2 code path.

會有這些邏輯是因為 AMD 在 2010 後決定放生 3DNow!,所以會需要這樣判斷。

接著寫了一隻小程式測試,用 memcmp() 判斷是不是一樣,結果發現 AMD 的 SSE2 跑出來的程式不被遊戲接受:(不一樣是正常的,因為這些指令本來就沒有要求完全正確,是可以接受誤差的)

接著就是翻資料,可以知道 XMMatrixInverse 算是接班人:

I figured that since we were to replace that matrix function anyway, I could try replacing it with XMMatrixInverse being a “modern” replacement for D3DXMatrixInverse. XMMatrixInverse also uses SSE2 instructions so it should be equally optimal to the D3DX function, but I was nearly sure it would break the same way.

所以就弄個一個 DLL,把本來呼叫 D3DXMatrixInverse 的部份用 XMMatrixInverse 改寫換掉:「SilentPatchME/source/D3DXMatrix.cpp」,這個方式算是乾淨的 workaround 掉,保持 API 相容性,以及該有的加速能力 (由 XMMatrixInverse 提供)。

Hacker News 上有討論到 Intel 與 AMD 這些指令在 SSE2 上的誤差值,都是在規格要求的範圍內:

Const-me 14 hours ago [–]

Here’s Intel versus AMD relative error of RCPPS instruction: http://const.me/tmp/vrcpps-errors-chart.png AMD is Ryzen 5 3600, Intel is Core i3 6157U.
Over the complete range of floats, AMD is more precise on average, 0.000078 versus 0.000095 relative error. However, Intel has 0.000300 maximum relative error, AMD 0.000315.

Both are well within the spec. The documentation says “maximum relative error for this approximation is less than 1.5*2^-12”, in human language that would be 3.6621E-4.

Source code that compares them by creating 16GB binary files with the complete range of floats: https://gist.github.com/Const-me/a6d36f70a3a77de00c61cf4f6c17c7ac

至於為什麼會生出 NaN 的原因,沒找出來還是有點可惜,不過這個解法還行,就是「新版的 library 既然沒問題,就大家也不要太計較舊版的問題」的概念...

安排路線的服務 Trail Router

Hacker News Daily 上看到的有趣服務,給起點與終點,以及想要有的長度,可以幫你拉一條差不多長度的路徑出來,可以提供給慢跑或是騎腳踏車的人規劃路線:「Trail Router」。

然後發現原來公司對面有 YouBike 站點... XD

這個服務的作者有在 Hacker News 上接受大家的詢問,可以到 Hacker News 上討論的頁面看一下作者的回應:「Show HN: Trail Router – generate running routes that prefer greenery and nature (trailrouter.com)」。

另外值得一提的是,這個服務用了 Mapbox 的圖資 (跟 OpenStreetMap 有關),看起來台北地區的呈現已經遠超過以前「堪用」的程度了,以後如果有需要用到的話可以考慮看看,就不一定要綁在 Google Maps 上了...

WebP 的檔案大小未必比 JPEG 小...

在「Is WebP really better than JPEG?」這邊發現在差不多的條件需求下,WebP 壓出來的檔案大小未必會比 JPEG 小。

先講結論:提供服務的人可以先確認自家的 JPEG 壓縮是不是有先用 MozJPEG (壓縮率更好),然後再考慮要不要支援 WebP。

Google 在推 WebP 這個格式的時候,宣稱失真壓縮的部份可以比 JPEG 小 25%~34%:(出自「A new image format for the Web」)

WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.

但作者發現 Google 之所以可以達到 25%~34% 這個數字,是因為比較的對象是 Independent JPEG Group 所釋出的 cjpeg,而如果拿 MozJPEG 相比的話應該得不到這個結果,另外也把 AV1 的 AVIF 拉進來一起測試了:

I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed.

這邊作者測試用的圖集是 Kodak Lossless True Color Image Suite,測試的結果發現 WebP 的確比 libjpeg (cjpeg) 好一些,但沒有像 Google 講的那麼多 (這邊就不知道是不是現在的 libjpeg 又有改善),而 WebP 與 MozJPEG 相比的話就沒有明顯優勢了:

WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.

However, when compared to MozJPEG, WebP only performs better with small 500px images. With other image sizes the compression is equal or worse.

I think MozJPEG is the clear winner here with consistently about 10% better compression than libjpeg.

另外也提到了 AVIF 的壓縮率很好,不過要注意演算法會把非重點部位的細節吃掉:

I think AVIF is a really exciting development and compared to WebP it seems like a true next-generation codec with about 30% better compression ratio compared to libjpeg. Only concern I have is the excessive blurring of low detail areas. It remains to be seen if this can be improved when more advanced tooling becomes available.

對網頁的應用來說,WebP 另外一個痛點是在 Safari 上的支援度,在 caniuse.com 的「WebP image format」這邊可以看到目前各瀏覽器都支援了,就剩下 Safari 還不支援,所以目前在 iOS 上得降回 JPEG:

不過這點之後也改變了,在 iOS 14 beta 裡的 Safari 可以看到支援 WebP 了:「Safari 14 Beta Release Notes」。

Media
New Features
Added WebP image support.

所以這個狀況變得有點微妙了...