【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】
■ このスレッドは過去ログ倉庫に格納されています
>>55
> --vbrhq 0 --vbr-quality 32
この使い方は知らなかった 一体いくらかかるんだろうw
MSのAzureにも似たサービスあるけど、あっちはMS独自のエンコーダーだったかな ビデオエンコーダブロックNVENCはTuring用に更新されています。
NVENCの最新の反復では、特に8K HEVCエンコーディングのサポートが追加されています。
一方、NVIDIAはエンコーダの品質をさらに向上させることができ、これまでと同様の品質を25%低いビデオビットレートで達成することができます。
NEVCでB-FRAME使えるのかな?? いつも思うけどハードエンコの開発元はPSNRなりのデータ出して欲しいね
ソフトウェアならデータ出してるとこ多いのに Pascal世代でもマクロブロックの捜査処理部の性能向上だけでHEVCの画質上げてたからな
Maxwellで同じプロセスルールのまま動作クロックとワットパフォーマンスをKeplerから馬鹿みたいに向上させてみたり
地味にnvidiaの回路設計技術は変態の域 NVIDIAはBフレを軽視しすぎている
というか規格に対する準拠意識が低い
今回発表のチューリングで、そのあたりがどこまで改善されるのか HWエンコでBフレ有りだと明らかに劣化する上、速度が遅いから要らんな
永久保存したいならSWエンコしなさいよ そんなもん、エンコーダーの出来が糞なだけだ
「Bフレを有効にする=画質劣化」ではない >>68
規格的にBフレ使用義務なんて無いが?
規格準拠とか言いつつ糞も理解してないだろ >>69
現状の実装だけみてハードウェアエンコーダは汚いと言い切るのは、さすがにどうかしている
実装次第だからな
ソフトウェアであっても実装がクソなエンコーダならば汚いことに変わりはない
ハードウェアかソフトウェアかだけで語るのは無意味 >>72
現状の実装以外に何を語るの?未来人なの?
1人だけ勝手にSWエンコ時もBフレが汚い話に捉えてるけど、おまえ以外はHWエンコ時の話しかしてないよ 少なくともQSVのH.264(LA-ICQ)でエンコしてSSIMやVMAFで評価した場合は、
BフレームとBピラミッド無し(--bframes 0)にすると、かなり酷いレベルで圧縮効率が低下するんだけどな。
(ちなみにデフォルトだと--brframes 3 --b-pyramid)
QSV-H.264-LAICQ_Bフレーム有無の差
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3501.jpg
>>67や>>69のように「BフレありのHWエンコは劣化が酷い」みたいに言ってる人は、
どのHWエンコーダのどのコーデックで、どのように評価してそう言ってるんだろ?
他にBフレームが使えるHWエンコというと、
・QSVのH.265
・NVEncのH.264
・VCEのH.264 (Polarisより古いハードのみ?)
のいずれかだが・・・。 圧縮効率が何で画質の悪さと関係あるんだよ
映像見て語れよ >>76
面倒くさい奴だな・・・。
一応crowd_runでも調べてやったけど、Bフレ無しだと圧縮効率が下がることに変わりはないぞ。
QSV-H.264-LAICQ_Bフレーム有無の差_crowd_run
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3502.jpg
ソース: https://media.xiph.org/video/derf/
>>77
もしかして圧縮効率を考えずに「画質が悪い」とか言ってるのか・・・?
「Bフレありの1Mbps」と「Bフレ無しの5Mbps」みたいに
ビットレートが異なるファイルを比べて「Bフレ無しの方が綺麗」とか言ってるんじゃないだろうな・・・。
それとも「Bフレーム有効にするといくらビットレートを上げても糞汚いHWエンコーダがある」とでも言いたいのか?
>>75での疑問にも何も答えてないし、何が言いたいのかよくわからん。 >>79
最低限の情報も出さず、まともな説明もしないお前の方がアホだと思うが・・・。
もしかしてグラフの意味を理解できてないのか?
同じビットレートで比較したいなら、同一ビットレートでのSSIMの値を見て比較すればいいだけなんだが。
SSIMでの客観評価じゃなく、同一ビットレートでの主観評価をしろってことなら、俺はそこまでやる気はないんで
「Bフレ有効だと画質が悪い」と主張するお前がテストして、その結果を示せばいいと思うけど。
それ以前に
・どのようなソースを
・どのHWエンコーダの
・どのコーデックで
・どのような条件でどのように評価した結果、Bフレありだと画質が悪いと主張しているのか
をちゃんと書いたほうがいいと思うけどね。そういった情報も無しにただ喚かれても、話にならんだろ。 やる気ないってwww
エンコしてるならその映像見てグラフと一緒に示せば完全論破でドヤ顔出来るのに、しないのが証拠だろ? 最低限の情報すら頑なに出さないアホの探偵ごっこか・・・。
目の前にある事実を無視して、わざわざ遠くにある迷宮に入りにいって帰ってこないタイプなんだろうな・・・。 いや、単純にSSIMやグラフの見方が分からないだけだと思う・・・ >>83=84
とうとう自演しやがったwww
全角の使い方でバレバレ >>83-84
ワッチョイ b9ec-PcWx
ワッチョイ 29c3-PcWx
くっさww ワッチョイの下4桁はUserAgentで決まるから被ってもおかしくないはず
PcWxはMonazilla/1.00 JaneStyle/4.00 Windows/10.0.17134らしいから利用者も多いだろうし たまたまこんな過疎スレで全角もワッチョイも被って
たまたまレスが並ぶなんて珍しい事が起きたんだね
なるほど〜 JaneStyle使ってるだけで同じ人扱いされるとは・・・俺はずっと↓このIDだから
http://hissi.org/read.php/avi/20180825/RG92RG4vWWEw.html
>>88
君はもう少し勉強してからレスしような NVEncの固定品質(>>58)試してるんだけど、どうもコレ内部では
ビットレート指定VBRと全く同じモードで動いてるっぽい
(少なくともGTX1060では)
ビットレート指定VBRと画質が全然変わらなかった
実写、アニメ、前半実写で後半アニメの3つくらいでエンコしてSSIM測って
SSIM-ビットレートをプロットしたら全部同じ線上に並んでしまった
という訳で今の所使う意味なさそう
次のTuringでは良くなるのかなぁ んなもんソースによる、一概な答えしか容認出来ない馬鹿は頬っておけ Turingの方はTensorコア使ったポストエフェクトとか超解像の方がトピックかもしれん
SDKから機能的にどう触れるかはまだ解らんけども、描画フレームにms単位の処理時間で適用出来る変態仕様みたいなんで
デコードされたフレームデータにも使えたらフィルタ処理系で色々面白い事出来るかも >>90
mpc-hcでビットレート観測するのが簡単
なんか、どっかでも書いたけど3Mbpsとか比較的十分にビットレートを使ってたら画質差は出にくい あれ、でもやっぱりビットレート分布は全然違った
ビットレート指定VBRと同じではなかった
ビットレート分布が変わっても平均するとプラマイゼロでSSIMは変わらないのか・・・ >>83
分かったからID:Fz8j+osy0 連れて来いよww NVEncの固定品質はちゃんと固定品質になってた
↓最初4分の1が実写で以降アニメの動画をエンコードしてCheckBitrateでビットレート分布出した
https://i.imgur.com/BfPIXjI.png
SSIMはほぼ同じだったけどSSIMはそういうものなのかな
まぁでも固定品質がちゃんと使えることは分かったわ
これからは固定品質一択だね
ビットレート指定VBRなんて必要ないわ >>92
Tensorコアでリアルタイムwaifu2xに期待 >>90 >>96
>>55と>>58にあるNVEncの
> --vbrhq 0 --vbr-quality 32
については、rigaya氏のブログのNVEnc 4.12の記事のコメント欄でやりとりされていて、
そこでのrigaya氏のコメントは以下のようになってる。
---
固定品質モードですが、ご指摘の方法でよろしいかと思います。
NVEncCのドキュメントにないのは、一応NVENCのSDK上では、
これがビットレート指定モードの一部だからです。
(「Rate control」としてはずばり固定品質モードというのはなく、
vbrhqでビットレートを指定しない(つまり0)、という形が必要です)
--- ビットレート指定モードの一部が固定品質モードってのはなんか分かりにくいなw >>97
何勘違いしているのか、知ってるフィルタの名前使いたいのか知らんけど
Tensorコアでwaifuの処理内容が高速に処理出来る訳じゃ無い
nvidiaが用意した機械学習成果を元にTensorコアで判断処理して補正・補完を適用するnvidiaの超解像技術になる
学習データが更新されると精度も上がるだろうし、レイトレなんかよりコンシューマPC環境にTensorコアを使用した処理環境が降りてくる方がデカい nvencの固定品質モードってのは便宜上やりとりとしてがそう呼称してるだけで
ビットレートの指定を明示的に無くす事で、指定ビットレートに近づけるために量子化係数の増減調整がされなくなるから、実質上固定品質と同意の処理になるってだけ >>100
別に勘違いしてないよ
nvidiaが用意するモデルにも興味はあるけど、既に高画質だって分かってるwaifu2xが
Tensorコアを使えるようになってリアルタイムくらいの速さになればいいなって期待してる
Tensorコアはfp16(半精度)で4x4の行列積を演算するコアだよ
convolutionを高速に計算するためにあるんだから、
convolutionがボトルネックになってるwaifu2xも高速化できるはず
今はfp32で演算してるからfp16でも精度がなるべく落ちないようにチューニングする必要はあるだろうけど
Tensorコア使ってconvolutionを計算するところはcuDNNがやってくれるから
書き換えはそんなに大変じゃないと思う >>101
揚げ足取るようで申し訳ないけど、固定量子化量(Constant QP)じゃないんだから
量子化係数は調整してるでしょ
もしかして今の実装的には 固定品質=固定量子化量 だったりする? >>103
「指定ビットレートに近づけるために量子化係数の増減調整」と書いているんだが
画質評価基準に擦り寄せる為の量子化係数の調整と勝手に思い込みで混同されても困る
waifu2xの件も行列積の浮動小数点演算精度が半精度化しているなら、行列積としての精度どれほど落ちると思ってる?
もうそれはwaifu2xのロジックをベースとした精度が大幅低下した派生物でwifu2xでは無いんだよ、同じ処理が出来ている訳じゃ無いんだしな
都合良く読み替えたり、後出しで精度不足とか都合の良い部分容認してみたりとか、ほんとに狡い奴だなお前は >>104
えっと、つまり>>101の
ビットレートの指定を明示的に無くす事で、指定ビットレートに近づけるために量子化係数の増減調整が
されなくなるから、実質上固定品質と同意の処理になるってだけ
↑これの解釈は
ビットレートの指定を明示的に無くす事で、(「指定ビットレートに近づけるために量子化係数の増減調整」と
「画質評価基準に擦り寄せる為の量子化係数の調整」の両方をやっていたところの)
指定ビットレートに近づけるために量子化係数の増減調整がされなくなるから、
(「画質評価基準に擦り寄せる為の量子化係数の調整」だけになって)実質上固定品質と同意の処理になるってだけ
ってことか?それとも
ビットレートの指定を明示的に無くす事で、指定ビットレートに近づけるために量子化係数の増減調整が
されなくなるから、(代わりに「画質評価基準に擦り寄せる為の量子化係数の調整」がされるようになって)
実質上固定品質と同意の処理になるってだけ
ってことか?うーむ・・・ >>104
waifu2xは「Tensorコアで」って書いてるんだから半精度化することも含めて
できたらいいなっていう期待で書いてるんだけど・・・
> waifu2xの件も行列積の浮動小数点演算精度が半精度化しているなら、行列積としての精度どれほど落ちると思ってる?
ディープラーニングの推論をfp16やint8でやっても精度低下は僅かって話はたくさんあるし、
nvidiaがfp16の演算コアを導入したのは、「ディープラーニングでは精度低下は僅かで十分実用的」だからでしょ
それを否定されてもなぁ・・・ >>106
ホントに手前の都合良く緩さを容認した事は「当たり前」と話して、そうじゃない事は違いを許さないとか利己的だな
行列積は単純な浮動小数点の計算と違って、複数回計算で精度取り戻せない
32bit精度で行列演算するコードを16bit精度のTensorコアで高速化とか、半精度を容認する前置きも無く書き込んでおいて
後出しで半精度容認している旨書き込んで悪びれもしないし
waifu2xと同様の処理が出来ても同じ精度維持出来ないから同じ処理は出来ないと言っているのに
機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり
ホントに最低に狡い奴だな 要するに
45c3-iM7h :
精度を落としたものをwaifu2xと呼ぶことは絶対に認めない
29c3-PcWx :
今の waifu2x は高品質だけど遅すぎるから、半精度化によってある程度品質が落ちる代わりに
Tensorコアによる高速化メリットが得られる waifu2x' みたいなもんができるといいな。
(半精度化による品質低下やTensorコアによる高速化がどれくらいかにもよるけど)
ってことじゃないの。
技術的なこだわりが強いのか何なのか知らんが、受け取り方がねじ曲がりすぎじゃね?
カリカリして人格攻撃するほどの話じゃないだろ。 >>107
> 32bit精度で行列演算するコードを16bit精度のTensorコアで高速化とか、半精度を容認する前置きも無く書き込んでおいて
>>92
> Tensorコア使ったポストエフェクトとか超解像
これはディープラーニングを使ったもので、「Tensorコアでディープラーニングを計算する」
って時点で、fp16に精度を落として行列積を計算するってことだよ
つまり、ディープラーニング(正確には行列積部分)をfp16で計算するっていうのは君が最初に言ってること
同じようにディープラーニングで超解像するwaifu2xもTensorコアで高速化できるよね
って話をしてるんだから、fp16で計算するっていうのは何の脈絡もなく出てきたわけではない
> waifu2xと同様の処理が出来ても同じ精度維持出来ないから同じ処理は出来ないと言っているのに
> 機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり
ディープラーニングを使った代表例みたいなwaifu2xにTensorコアを使うことを否定するのは
「機械学習でTensorコアの効果を否定」するのと同義だと思うのだが >>108
NVEncの実際の実装が後者の可能性もあると思うけど、なんで前者だって分かるの? >>110のように「お前が最初に言った」みたいな書き方をすると、また不毛な返答が返ってくる気がするので
"こっちは元々「fp16化+Tensorコアで高速化したリアルタイムwaifu2x(もどき)」を想定して書き込んでて、
>>100でお前が勘違いとか言ってきたからそれに答えて詳細を説明しただけなのに、
精度落としたらwaifu2xじゃないとか、後出しとか狡いとか利己的とか言われて迷惑してる。”
って書いてやった方がよい気がする。 >>113
指摘の弁解も理由も全部後出し
取り繕いばっかりじゃねーかよ
そんで、waifu2xの演算に精度不足というなのがTensorコアが機械学習用途に不適というこじつけなるか理由聞かせてくれよ >>112
「可能性」とか言い出せばどっち前者だろうが後者だろうがイチャモン付けられるってか?
品質基準のVBRロジックなんだから、ビットレート指定時に品質基準での調整ロジックが動いて無く、ビットレート指定を無くした時にだけ稼働すなら、ビットレート指定時は品質基準のVBRじゃなくなるわな
nvidiaが品質基準VBRとして実装しているものすら疑いだしたら、何を基準で正否とするよの?
後者と判断するなら、その根拠を提示してくれよ ffmpegでのエンコードパラメータを極めるスレはどこ? >>114
> waifu2xの演算に精度不足というなのがTensorコアが機械学習用途に不適というこじつけなるか理由聞かせてくれよ
そもそもその前の時点でお前が話を読み違えてるんだよ。>>107でお前が
> 機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり
と書いてるが、106はTensorコアの効果の否定なんてしてないだろ。
下3行の解釈を、お前が間違えてるだけのように見えるが。
29c3-PcWx が言いたいのは、
・Tensorコアがfp16なのは、NVIDIAがfp16でもディープラーニングでは十分実用的だと判断したからではないか
・ならばwaifu2xのfp32処理の部分を、Tensorコアのfp16処理に変えてみるのももしかしたらアリではないか?
ってことでしょ。まあディープラーニングっつっても目的によって必要な精度は変わってくるんだろうから
そんな単純な話が成り立つかどうかは知らんけどね。
とりあえず落ち着いて、やりとりを最初から見直してみたほうがいいんじゃねえの。 まあwaifu2xについて、「処理をfp16にしたらまともな品質にならない」みたいな検証が既にされてるのであれば
淡々とその結果を示してあげればいいと思うけど、これ以上続けたいなら
そろそろ画像拡大スレに移ったほうがいいんじゃないかとは思う。
【超解像】画像拡大ソフト総合スレ2【waifu2x】
https://egg.5ch.net/test/read.cgi/software/1462848853/ >>115
ビットレート指定時は品質基準VBRじゃないでしょ
ビットレート指定のVBRなんだから
ビットレートを指定しなかったときに品質基準VBRになる
> nvidiaが品質基準VBRとして実装しているものすら疑いだしたら、何を基準で正否とするよの?
固定QPモードがあるんだから、ビットレート指定VBRは、
平均ビットレートが目標より大きくズレたら、適当にQP操作してるだけかもしれないじゃん
そこから、ビットレートを目標にあわせる処理を抜いたら、固定QPになっちゃう
NVEncCのデフォは固定QPだし
> 後者と判断するなら、その根拠を提示してくれよ
後者か前者かなんて分からないよ
中の実装がどうなってるかなんて知らないから
エンコード結果、どういう出力がされたかくらいでしか観測できない
ビットレート指定VBR時はビットレート指定VBRのレートコントロールが働いて
品質基準VBR時は品質基準VBRのレートコントロールが働くって考えるのが
最もシンプルな理解だと思うから、そうじゃないときはちゃんと書いてくれないと分からないよ 細かいことはよくわかんねーけど、とりあえずNVIDIA Video Codec SDK 8.2.15 の
NVENC_VideoEncoder_API_ProgGuide.pdf の 「3.8.3 Rate control」の内容を貼っとくわ。
https://pastebin.com/LuGCNXbY >>120
サンクス
この資料だと、Target Quality(固定品質)がVBRの一部って書き方じゃないんだよね
対応してるレートコントロールは以下の4つです
- CBR
- VBR
- 固定QP
- 固定品質
って感じ
あとVBRのレートコントロールについての記述は主に
> The encoder tries to conform to average bitrate of averageBitRate over the long term
これだけ 76 名無しさん@編集中 (ワッチョイWW ea84-/kQw) sage 2018/08/25(土) 08:51:46.65 ID:A+XxIkPU0
どーせアニメだろw
122 名無しさん@編集中 (ワッチョイWW ea84-/kQw) sage 2018/08/27(月) 10:48:37.03 ID:KSUuDcZo0
紙芝居のためにご苦労さま
この間46レスと50時間w
r ‐、
| ○ | r‐‐、 良い子の諸君!
_,;ト - イ、 ∧l☆│∧
(⌒` ⌒ヽ /,、,,ト.-イ/,、 l. 証拠を要求するネトヲタがいるが
|ヽ ~~⌒γ⌒) r'⌒ `i´ `⌒) 君がいくら証拠を開示しても
│ ヽー―'^ー-' ( ⌒γ⌒~~ /| そのネトヲタは絶対信じないぞ!
│ 〉 |│ |`ー^ー― r' | おまけにそいつは自分側の証拠を出したことがない。
│ /───| | |/ | l ト、 |
| irー-、 ー ,} | / i 自分の信じたいものしか信じなくなったらおしまいだな!
| / `X´ ヽ / 入 | なにが正しいかなんてわからんよ
エンコードしないのが一番いい気がするわ 劣化を感じるようなエンコードしかできないのは、ユーザーの能力不足による無理な設定によるところが大きい
いくら優秀なエンコーダーを用いたところで、フルHD動画を最大1Mbpsなんかに設定したら、どうやっても劣化は目につく
それに放送番組を再エンコードするのにノイズ除去すらもせずにエンコード直行など、愚かにもほどがある もうHDD買い足してソースをそのまま保存しとけよ
エンコードなんかしてたら人生損するよ ソースで多少前後するけど
静止画比較しないと気にならないレベルなら
固定量子化ベースの量子化係数設定値なら
H264 QSV 〜22
H264 NVEnc〜20
HEVC QSV 〜24
HEVC EVEnc Pascal 〜23 Maxwwll 〜22
あたりが画質に目立った劣化が知覚できるかの境界線あたりかと(あとは好みで1減らすなり、IPBで階段状に設定するなり
コーデック問わず画質容量比と処理時間でなら、PascalのNVEncが速度とのバランス的に優秀
H264→HEVCでの速度低下がQSVが1/3〜1/4にもなるけど、NVEncだとMaxwellで1/2、Pascalで2/3程度の速度にしか落ちないのがデカい
HWエンコーダで時間問わずならQSVのHEVCなんだろうけど
HEVCだと速度低下激しすぎて(GT2で40fps前後)CPUの方がOC4コア以上ならx264のfasterとかで処理しちまった方が良くなってくる
ただNVEncはGeforce/Titanだと同時処理が2件までなんで、TSの録画後に自動処理で録画タスク毎に処理するのには向かない(やりようはいくらでもあるけど)のが難点 録画後処理じゃなくて
定期的にファイルリストに対して
1本ずつ処理したらええだないかね >>115
組める人には問題ないけどね(自分もそうやっている
フォルダ監視して順次エンコさせる場合には、リスト取得や録画中のファイルか録画完了したファイルかの判断とか
録画管理ソフトで録画終了時に実行する様なバッチみたいに、コマンドラインのエンコード命令にに毛の生えたぐらいのと違って、自分で組まなきゃならん部分多いから多少はハードル高くはなる
実際に他のスレで同時エンコ数の制限有るから使いづらいみたいな事書き込んでた奴も見かけてるし >>137
「また,エンコーダの圧縮アルゴリズムにも改良が入っており,Pascal世代と比較して,同じ画質ならH.264で15%,H.265なら25%も低ビットレート化できるようになった。
逆に言えば,同じビットレートならPascal世代のGPUを使うよりも高い画質を得られるということだ。」
おぉー!
これは期待しちゃうなぁ AMDって今何してるの?
動画ならAMDなんて時代もあったのに… 画像の中の表によると
1080・60pの動画をビットレート6Mbps設定でエンコードした場合に
x264のプリセットFastと、Turing世代のGPUでH.264(かと思われ)を比較すると、
PSNRの値が少しTuring世代のGPUのほうが上回っている
となると、x264のプリセットslowと比べるとしてもビットレートを2割増程度で充分対抗できるかも?
なんかすごいことになってきたな >>139
CPU作ってるよ
ATiって言わない時点で知ってるんだろマヌケ Poralisでリアルタイム2パスエンコードエンジン採用してディティールが残るとか言ってたのは結局どうだったの?
https://www.4gamer.net/games/329/G032949/20160629072/ 文脈読むならNVIDIAやインテルにGPUエンコでぼろ負けだけどGPUでエンコやる気ないの?だろ
どう見てもなさそうだねw
費用対効果で割りに合わないと思ってそう >>140
6Mbpsか・・
2Mbpsとかでも馬脚を出さなかったら凄いけど
どうなんだろ >>144
2MbpsはHEVCでもキツいだろ
解像度かフレームレート落とせば収まるだろうけど >>138
6万弱になってる1080無印でも新しく載せようかと思ってたが
2070待ってた方がいいのかな。 AMDのGPUは二度と手を出さない
過去にいい思い出がないから >>148
待てるなら待ったほうがいい
それと、2070と2080以上ではいろいろ違いがあるから、可能ならば2080もしくは2080Tiを狙ったほうが後々後悔しなくて済む >>151
・RTX 2080 Ti / 2080 / 2070が登場、スペックや性能、価格と発売日をまとめ
https://chimolog.co/bto-gpu-geforce-20-series/#GeForce_RTX_2080
・GTX 1080 Ti VS RTX 2080 Ti
理論上約20%の性能向上
・GTX 1080 Ti VS RTX 2080
理論上約13.4%の性能向上(GTX 1080 Tiに近い性能)
・GTX 1070 Ti VS RTX 2070
理論上約9%の低い性能低下(価格は1070Tiよりも100ドル程度上昇したにもかかわらず)
・GTX 1070 VS RTX 2070
理論上約16%の性能向上
コスパで考えると、1070Tiと2070の比較は分が悪い
1070との比較で性能向上したから良しとするならば性能については問題はないが、
今回の2080Ti、2080、2070はすべてチップが別々になっているところから言って、
細かいところで2070は省略されているものがあるのではないかと噂があるのは確か >>152
そのページ古くね?
2070は1080超えてると思うぞ? 今は買うな時期が悪い7nmまで待て
今は買うな時期が悪いHBM2搭載まで待て
とりあえずこれで東京オリンピックまではいける >>147
> 動画再生なら今もAMDだがな
動画再生におけるAMD GPU
→メリット
・Fluid Motionがある。
→デメリット
・VP9のDXVAに対応しているのが今のところRavenRidgeのみ。
他に何かあるっけ? ■ このスレッドは過去ログ倉庫に格納されています