AMD 推出 FidelityFX Super Resolution

AMD 推出了功能上類似於 NvidiaDLSS 的技術,叫做 FidelityFX Super Resolution (FSR),並且 open source 出來:「AMD FidelityFX Super Resolution is Here」,另外可以看一下 GPUOpen 官方網站裡面的內容。

DLSS 的機制上可以這樣解釋,遊戲輸出 1080p,透過 machine learning 運算的方式將畫質提升到 2K 或是 4K,這樣比起遊戲直接要計算 2K 或是 4K 的輸出內容,運算量可能會比較少。

不過 DLSS 只能跑在 RTX 20xx 與 30xx 系列的顯卡上,以前的舊顯卡不支援。而先前 AMD 公佈 FSR 的時候,除了是宣示 AMD 也推出類似的技術外,另外一個賣點是 FSR 可以跑在 Nvidia 的顯卡上。

而這次的消息則是又多說明了 open source 的釋出部份,將在七月中放出來:「AMD FidelityFX Super Resolution is Here」。

The source code for FidelityFX Super Resolution 1.0 will be coming to GPUOpen in mid July!

目前有七個遊戲支援,後續會有更多遊戲加入...

讓 Lotus 1-2-3 支援寬螢幕

一樣是在 Hacker News Daily 上看到的文章:「Lotus 1-2-3」,講怎麼讓 DOS 版的 Lotus 1-2-3 支援寬螢幕。在 Hacker News 上也有些有趣的討論:「Lotus 1-2-3 arbitrary resolution (cmpxchg8b.com)」。

裡面提到個有趣的事情,目前 Lotus 1-2-3 的 FTP 站還活著:

Believe it or not, the old Lotus ftp site is still online. I mirrored everything they had to my workstation and sifted through it.

作者把修改的成果放到 GitHub 上:「Lotus 1-2-3 R4D Display Driver for DOSEMU2」,可以看出當年 Lotus 1-2-3 程式裡面沒有 hard code 太多 width = 80 的部份。

另外個有趣的東西是他提到的 TASM,當年 Borland 的產品。

懷古的感覺...

用 OpenCV 與類神經網路放大圖片

在「Deep Learning based Super Resolution with OpenCV」這邊看到 OpenCV 支援這些類神經網路的演算法了,而且有預先訓練好的模型資料可以下載來用。

傳統放大的方法包括 bicubic 與 nearest neighbor,速度很快但是效果就普普通通,而 NN 類的方法的效果遠超過傳統方式,不過速度慢不少。

文章裡面有提到可以指定不同的 NN 模型:

The first parameter is the name of the model. You can choose between: “edsr”, “fsrcnn”, “lapsrn”, “espcn”. It is very important that this model is the correct one for the model you specified in ‘sr.readModel()’. See the Model section on the bottom of the page for the specifications of each model.

拿這些模型名字搜了一下資料,在「Super-resolution benchmarking」這邊可以看到比較,主要是在講 EDSR 很棒,然後 ESPCN 很快?

不過看起來可以直接拿來用在不少地方了...

Twitter 對 2x 與 3x 的圖片的研究...

所以發現很多時候用 2x 的圖片就夠了?:「Capping image fidelity on ultra-high resolution devices」。

會這樣討論主要是發現螢幕特性:

The most modern screens are OLED. These screens boast some really great features like pure blacks, and are marketed as 3x scale. However, nearly no "3x scale" OLED actually has perfect 3x3 pixels per dot on their screen.

因為螢幕不是真的到 3x 的要求,丟 2x 的圖片出去就好,省頻寬又省下載時間:

This means that most OLED screens that say they are 3x resolution, are actually 3x in the green color, but only 1.5x in the red and blue colors. Showing a 3x resolution image in the app vs a 2x resolution image will be visually the same, though the 3x image takes significantly more data. Even true 3x resolution screens are wasteful as the human eye cannot see that level of detail without something like a magnifying glass.

省下 38% 的資料量,32% 的時間:

There's no difference that the human eye can see, but will save 38% on data and 32% on latency on the capped image load for this particular example which is reflective of most images that load on Twitter.

這也另外帶出了其他的想法,如果沒有太多時間研究的話,可以考慮先提供 2x 的就好,不需要特地做 3x 的版本...

PChome 修正了問題,以及 RFC 4074 的說明

早些時候測試發現 PChome 已經修正了之前提到的問題:「PChome 24h 連線會慢的原因...」、「PChome 24h 連線會慢的原因... (續篇)」,這邊除了整理一下以外,也要修正之前文章裡的錯誤。

在 RFC 4074 (Common Misbehavior Against DNS Queries for IPv6 Addresses) 裡面提到了當你只有 IPv4 address 時,DNS server 要怎麼回應的問題。

在「3. Expected Behavior」說明了正確的作法,當只有 A RR 沒有 AAAA RR 的時候,應該要傳回 NOERROR,而 answer section 裡面不要放東西:

Suppose that an authoritative server has an A RR but has no AAAA RR for a host name. Then, the server should return a response to a query for an AAAA RR of the name with the response code (RCODE) being 0 (indicating no error) and with an empty answer section (see Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that there is at least one RR of a different type than AAAA for the queried name, and the stub resolver can then look for A RRs.

在「4.2. Return "Name Error"」裡提到,如果傳回 NXDOMAIN (3),表示查詢的這個名稱完全沒有 RR,而不僅僅限於 AAAA record,這就是我犯的錯誤 (在前面的文章建議傳回 NXDOMAIN):

This type of server returns a response with RCODE 3 ("Name Error") to a query for an AAAA RR, indicating that it does not have any RRs of any type for the queried name.

With this response, the stub resolver may immediately give up and never fall back. Even if the resolver retries with a query for an A RR, the negative response for the name has been cached in the caching server, and the caching server will simply return the negative response. As a result, the stub resolver considers this to be a fatal error in name resolution.

Several examples of this behavior are known to the authors. As of this writing, all have been fixed.

PChome 這次的修正回應了正確的值 (而不是我提到的 NXDOMAIN):

$ dig shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw

; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<<<- opcode: QUERY, status: NOERROR, id: 40767
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;shopping.gs1.pchome.com.tw.    IN      AAAA

;; AUTHORITY SECTION:
gs1.pchome.com.tw.      5       IN      SOA     ns1.gs1.pchome.com.tw. root.dns.pchome.com.tw. 20171123 3600 3 3600 5

;; Query time: 16 msec
;; SERVER: 210.242.216.91#53(210.242.216.91)
;; WHEN: Fri Nov 24 01:44:52 CST 2017
;; MSG SIZE  rcvd: 134

另外 RFC 也有一些其他的文件可以參考,像是 RFC 2308 (Negative Caching of DNS Queries (DNS NCACHE))、RFC 4697 (Observed DNS Resolution Misbehavior) 以及 RFC 8020 (NXDOMAIN: There Really Is Nothing Underneath),這些文件描述了蠻多常見的問題以及正確的處理方法,讀完對於現在愈來愈複雜的 DNS 架構有不少幫助。

AWS CloudWatch 推出秒級的記錄功能

AWS CloudWatch 推出了秒級的記錄功能:「New – High-Resolution Custom Metrics and Alarms for Amazon CloudWatch」。

從一分鐘變成一秒鐘讓之後的調整以及 debug 好用很多... 不過這次支援秒級的是 custom metrics,原先 AWS 自家服務的支援不在這次範圍:

Today we are adding support for high-resolution custom metrics, with plans to add support for AWS services over time. Your applications can now publish metrics to CloudWatch with 1-second resolution.

另外 alarm 的時間可以降到十秒:

You can watch the metrics scroll across your screen seconds after they are published and you can set up high-resolution CloudWatch Alarms that evaluate as frequently as every 10 seconds.

對於市場上一堆服務的衝擊應該不小 XD

Netflix 對於拍攝影片的要求

Netflix 對於拍攝影片的要求直接放在網站上:「Production and Post-Production Requirements v2.1」。

Provide a set of technical requirements for production and post-production workflows to ensure that a high level of quality is maintained throughout the lifecycle of a project from capture to archive. This serves the purpose of future-proofing the content as the Netflix platform and viewing experience continue to evolve.

裡面有提到一些產品,這些資訊其實可以當作採購指南用... (當預算有到這個 range 時 XD)

不過動畫會怎麼算啊 XDDD (應該是另外的 requirement?)

NieR: Automata 將會出 HiRes 版 OST

看到 moraNieR: Automata 將會出 HiRes 版 OST:「3/29「NieR:Automata」 Original Soundtrack ハイレゾ同時配信決定!」。

2/23に発売されたアクションRPG『NieR:Automata』のゲーム内BGM を収録した、「NieR:Automata」 Original Soundtrackが 3/29ハイレゾ同時配信になります!NieRシリーズはゲームサウンドの評判が高い事でも知られていますが、今作もプロデューサー 齋藤陽介、ディレクター ヨコオタロウ、サウンドプロデューサー 岡部啓一(MONACA)の完全監修による、NieRファン、ゲーム音楽ファン必携の一枚です。

這太棒啦~