16/02/25 18:23:42.35 otUwHTvD.net
>>145
GPGPUは「GPUがグラフィック処理で使う演算装置って、ちょい改造するだけで、すげぇ数の浮動小数点演算コアに出来なくね？」のと
「シンプルな演算機が数あるから、スパコンでやらせるみたいに、比較的単純な演算を馬鹿みたいな数積み重ねて長い時間掛けて計算するのに向いてるよね？」というもの
エンコードは後者にあたるんだけど、計算内容は前者の逆な部分が多いのよ
そして高画質化の大半は、コーデックのエンコード処理ルールの外にあって
「データ放り込む際に、事前にデータをこう前処理した方が圧縮効率上がるから、その分実効データ量（画質）良くなる！」という、
料理の下処理的な手法を多重に使いまくった結果が大きいのよ
重い部分も大半がこの部分で、H264自体は際だって重い訳じゃないけど、画質上げようとすると糞重い処理が増えまくる（x264でやってる事）
この処理は、上に書いた前者にも後者にも該当しづらい複雑で柔軟な処理が求められる整数演算的な内容なんで、GPGPUは苦手な部類になる（CPU視点で考えてるからってのもあるけど）
結局、CPUが得意とする処理の比重が多くて、GPGPUで処理しやすい部分だけ旨く拾い上げて採用したり、GPGPU視点で「これならGPGPUで出来るし、やらないより良い結果が得られるな」という実装追加してるのがQSV
コーデックのコアな部分しか処理してないのがNVENCと前記の工夫部分を廃したQSV FF
CUDAエンコーダは、ソフトウェア的に最小限のエンコードコア部分と、比較的簡単な工夫部分をGPGPU用に実装しただけ