【悲報】macOSでOpenGL/CLが非推奨、CUDA対応は終了
■ このスレッドは過去ログ倉庫に格納されています
NVIDIA、macOSをサポートした最後のCUDA Toolkiをv10.2リリース。次期アップデートでmacOSは非サポートに。
https://applech2.com/archives/20191124-nvidia-last-release-to-support-macos-for-cuda.html
macOSのNVIDIAドライバについては、2018年09月にリリースされたmacOS 10.14 Mojaveで
Appleがグラフィックドライバを完全にコントロールし、NVIDIA GPUでパフォーマンスの低下や
予期しないレンダリング発生する不具合が報告され、NVIDIAがドライバ・アップデートを開発しても
Appleがそれを許可せず、実質的にNVIDIAが利用できるmacOSはmacOS 10.13 High Sierraまでとなっています。
同時に、AppleはOpenGL/CLをレガシィAPIとして非推奨とし、開発者に対しMetal APIへ移行を促すとともに、
MacではdGPU/eGPUにAMD製グラフィックのみをサポートし続けてきましたが(NVIDIA GPUは
2016年以降のMacでは採用されていません)、そんな状態が約1年半続いた中でNVIDIAは
macOSでCUDAのサポートの打ち切りを決めたようで、 >>1
Appleはそう思ってないだろうけど、これでMacでGPGPUを使った数値計算は
絶望的状況になりそう。 そのうち、AppleではWebGLも動かなくなりそうな予感。 WebGLに代わる新しいものをAppleが提案してきそうだよなw
仮にMSがやったとしたらWebDirectXみたいな名前で >>4
それだと、IE以上に酷い運命をたどるだろう。
いずれにせよ、Appleは倒産はしなくても、NECと同様に大幅に弱消化する予感がする。 元は単なるゲーム対応のためだったかもしれないが、
DirectXへの投資は先見の明があったよな 最初、IEだけ独自だったので場合分けして対応する手間でWebプログラマは困っていた。
そのうち、プログラマの中にIEは無視する人が出てくるようになった。
IEのシェアが低下し、FireFoxやChromeがどんどん使われるようになっていった。
Appleでもこうなって欲しいと願うプログラマーは多いが、既にシェア低下の傾向が
現れ始めている。 これからは良くても今までのソフトの移植は大変だろうな
Macだけ切り捨てってことにもなりかねない たいした手間でもないんだけどな
DirectXとMetalの親和性は高いがOpenGL自体が実にめんどくさい
今までOpenGLでかいてたコードをMetalに置き換えるのは問題ない DirectXではなくOpenGLを使っていたのは、
単一のコードでどこでも動くからだよ。
だからシェアが少ないmacOSにも対応できてたのに、
それができなくなったら、macOSに対応する意味ないじゃないか Apple自身が作らせたOpenCLから手を引いたらこりゃもうおしまいかね。
IntelやAMDはどうするんだろう。 >>9
OpenGL ES からは面倒になったが、昔の OpenGL はとても分かり易かった。
逆に Direct3D のものすごく面倒だった。
究極まで速度を追求しなくて良い場合は >>12
誤送信してしまった。
究極まで速度追求をしなくて良い場合は、OpenGLが好まれた。
例えば、CADや3Dモデラなどでは、OpenGLでも十分だった。
それらの分野では、OpenGLは分かり易くて直感的だったのでDirect3Dでも
好んで使われる傾向があった。 >>10
恐らく、iPhoneも売れなくなってきて、本人達は何か知恵を働かしてApple製品を
買わそうとしているんだと思う。例えば、Metalに自信を持っていてApple製品だけ
がMetalが使えるから買う動機になる、というように。
ところが、iPhoneは特にそうだが、既にAppleはファッションやブランドで買って
いる人がほとんどで、技術で勝っている人はいなくなっている。そもそも
Appleのプラットフォームに限らず、個人でプログラムしてもまず食っていけるほどには
売れないので、Metalなどのライブラリの美しさはApple製品を買う動機にはまずならない。
しかし、その辺がAppleの中の人は分かって無いらしい。
仮に僅かにMetal目的で買う人がいても焼け石に水で、逆にOpenGLアプリが動かなく
なることで離れていく一般ユーザーの方が多いことが分かってない。
一般プログラマ目線で行くと、iPhoneなどのプラットフォーム用に対応したアプリが作れなく
なってしまうことで失う稼ぎはもったいないが、時間の問題でiPhoneからAndorid系への
移行が進むことを待たざるを得ない人も多いと思う。
ただし、大手ゲームメーカーなどはそんなことは関係なく、iPhoneにもゲームを出すとは
思う。 >>13
誤:それらの分野では、OpenGLは分かり易くて直感的だったのでDirect3Dでも
正:それらの分野では、OpenGLは分かり易くて直感的だったのでDirect3Dより >>9
大手ゲームメーカーの場合はプログラマが多いので大した手間では無いが
人数が少ないチームだと一般論としてDirectXとMetalで分けて書くのは大変だろう。
CADなどだと OpenGLでも十分な速度だったのに、敢えてMetalにするのは手間が
増えるだけ。CADの場合は今後も長くバージョンアップを続けるので、
永遠に二重のメンテナンスがかかり続けるコストもかかってくる。 ゲームはMacなんて切り捨てていいだろ
全体でも10%しかシェアないし >>14
Appleの人達は自分達が技術的な「提案」を出来る立場に居ると思っているのかも
しれない。しかし、一般プログラマ目線で見れば、既にAppleはファッションブランド
と化した女子高生に人気のブランドであって、技術的提案を出来るような立場には無い。
そういう解釈の齟齬がある可能性がある。技術的目線で言えば値段だけが高いメーカーの
ものを、技術に詳しいホビーイストが買うわけが無い。
逆に資金力のある大手ゲームメーカーは、Metalなどはどうでもよくて、PS4やNintendo, XBox
など用に出すのが一番儲かる。PC用に出すとしてもDirectXで十分だと思っている。
スマフォ向けに出す場合は、OpenGL ES や WebGL などで十分な程度のゲームを念頭に置いている。
そうやって3Dの重たさのランク分けしている。
だから、Metalなんて競争力向上には全くならないが、Appleの人達はなると思っている。
まだ、Apple II の時代だと思っているが、既にAppleブランドは、アパレルファッションブランド
として認識されてしまった後なので無理だ。 >>17
確かにそうで、
1. 大手ゲームメーカーは、ゲーム専用機に出したほうが儲かることを知っている。
2. ゲーム専用機に出すための機材購入費なども無いような弱小ゲームメーカーは、
SNSゲームとしてスマフォに軽量ゲームを出すので、Metalなんて要らない。
SNSゲームの場合、WebアプリにしてWebGLでも十分なこともありえる。
3. フリーゲームなどの場合は、基本、ソースコードが一本に絞られなくては難しいので
Windows専用にするか、OpenGLにするか、WebGLにするかになる。本当は、
OpenGLにするとしても、その他の部分のApple専用コードが大変で、フリーゲーム
には負担が大きいと思うが。その場合は、Xamarineなどを使うのかもしれないが、
それはC#になってしまうので、速度面でまた問題が生じる。 QuickDraw 3Dの時代に逆戻りかぁ。
ただでさえ3D関連は厳しいのに。 >>19
今はソーシャルゲームの方が遥かに市場が大きいそうです。
・スマホゲーム:市場規模は1兆4,000億
・家庭用ゲーム機:ハード含めて4,400億円。ハードが半分、ソフトが半分。
・PCのゲーム:大体700億円
・アーケードゲーム: 店舗を含めて6,000億円ぐらい。 Metalを作るのはいいが、OpenGLを廃止する必要はないし
CUDAのサポートを禁止する必要もない。
DirectXと同時にOpenGLやCUDAのサポートも
しているのがWindows >>14
単にMetalの方がパフォーマンス出るからOpenGL/CLをレガシーにするんでしょ
一般のユーザーにMetalの優秀さをアピールしても全く伝わることはないと思う >>23
大手ゲームメーカーは、AndroidではOpenGL ES、iOSではMetalの両対応に
するのは難しくない。すると、同じゲームでもiOS版の方が見栄えの良い
ゲームになるので、「iPhoneの方がゲームが凄い」と言われる状況を
目指しているのかもしれない。でも、同じ価格ならAndroidマシンの方が
3D性能が良いので、ポリゴンの数や重たい処理ではAndoridに軍配が上がる
可能性もある。だから、iOSの場合は、Metalを使ってやっと、Android
のゲームに追いつくような状況になるかもしれない。 まぁ今となってはOpenGLはレガシーなAPI仕様であることは否定できないな。
バージョンアップするのは良いけど変える必要のないとこまで微妙に変更して非互換になったりなかなかプログラマー泣かせだったわ。 DirectXと比べればレガシーだったよね。
AppleはDirectX相当のものを作る力がなかったからOpenGL/CLに依存していた。
だけどやっぱりOpenGL/CLは古い。AppleもDirectX相当のものがほしい。
そうやってMSから遅れること数十年、ようやくDirectXの対抗技術のMetalを作った。
そいう流れ >>25
実は、3DハードウェアやOpenGLが出来る前、各自が2D-VRAMに独自に
3Dグラフィックを描いていたころ、できるだけ高速化するために、初期の
Direct3Dのような描き方をする流儀はあったので、初期のDirect3Dが
OpenGL 2.0 に比べて新しいという分けではなかった。なにより、
OpenGL 2.0 は、分かり易さが凄かった。glBegin() と glEnd() で囲った部分に
頂点の数だけ glVertex() 系関数で座標を指定すると言う作法。これは、
当時の遅いパソコンユーザーからは発想できない方法だった。SGIは
とても高級なマシンを使っていたのでその程度の速度の犠牲を考えずに
美しさを選ぶことが出来た。なお、OpenGL ES は、OpenGL 2.0とは
似ても似つかない流儀となっており全く分かり易さが無く、OpenGL
の良さは全く失われてしまっており、いわば、Direct3Dのオープン版
というようなものだと思っている。OpenGL 2.0 はDirect3D とは比較
にならないほどの美しさを持っていたので OpenGL ES だけしか
知らない人には、OpenGL 2.0 ファンの気持ちは分かってもらえないと思う。 >>27
「ES」は、Embedded System の略なので、CPUパワーが貧弱で、
GPUだけが高速であるような環境で威力を発揮し易い流儀になっている
ように思っていた。これは、WebGLと表裏一体で、ブラウザでは、
JavaScriptは遅いが、GPUは、nativeと同じものを使えるのでとても
速いという今言ったことにぴったりの条件になっている。
まず、GPUに直接つながっている「(汎用)VRAM」に頂点座標と頂点番号、
頂点のつながり方の情報を、初期化段階か、初期化に類する段階で
転送しておく。そして、CPUがGPUに対して描画を指示した場合、
完全にCPUとは独立したシステムで何もかもを実行できる仕組みに
なっている。この際、GPUが参照しているメモリの(ICチップ相当のもの)
自体がCPUのものとは完全に独立しているのでWAITの必要も無い。 3Dの理解にはOpenGL 1.0から2.0関連は有益だと思うんだけど、DirectXにせよMetalにせよVulkanにせよGLESにせよ、
今のモデルありきのライブラリ構造はそういう点ではいただけない。 >>26
一応Quickdraw3Dはあったけどね
Jobs復帰でOSXへ切り替えることが決まったから継続する意味はなくなったんだろう
DPSとOpenGLの関係もあったし >>31
Safariでは、そもそも WebGL がまだ実験的実装になっていて、OptionでON/OFF
するようになっているところからしても、先行き不安。
CUDAという数値計算屋にとって大切なものまで除外し始めたし、
WebGLやCUDAに問題があるのではなく、Appleに問題があるので、
個人的にはAppleが消えてなくなってくれれば助かる。 Appleを独占禁止法違反指定して欲しい。
EUは頑張って。 CUDAはそもそもnvidia依存すぎるのが大問題だったし
それでOpenCL扱う人が多かったわけ
Metalでも簡単な書き換えは必要だがOpenCLからコールできるライブラリが出てるから問題ないと言えば問題ない あとね数値計算屋って言っても様々で
nvidiaの方針自体がある意味使わせないって方向だから反発してる人も相当多いんだよ
使用禁止の範囲で無理に使っても今度は精度が担保できてない問題にぶち当たる
ボードごとに検査が必要で全滅ってことも過去にあった
nvidiaは昔から精度に関してあまり重視していない
ATIだとこういったことは一切ないから安心して使えるんだな
TSUBAMEの中の人もCUDAに関しては否定的だしそんなもんよ >>35
だとしてもそれは消費者が選択することで、中央政府の様なところが
決めてしまうのは昔の中国やソ連の計画経済みたいで困る。 そもそも、nVidiaがAppleの協力無しには実装できないのであれば別として、
独自にMacで動くように整備できる技術を持っているんだとすれば、
それをAppleが無理やり阻止するのはおかしいと思う。
最近のアメリカのIT企業に目立つのは、他の企業が自分の力で作り上げてきた
ものを難癖を付けて動作できないようにしてしまうこと。 デベロッパーから文句言われたりしてないのかなぁ。
困る人は多いと思うんだけど。 アメリカのIT企業がやっているのは、ある種の「暴力」。
暴力を使えばなんでもできてしまうが、それだと社会の進展が望めないから
暴力は抑止されている。
社会の進展とは、科学、技術、文化、芸術、心などの発展のこと。
アメリカのIT企業がやっているのは、魅力的なハシゴを作っておいて、
みんなが真ん中まで来たときに、ダイナマイトで壊してしまう。
彼らは、そういう暴力も実力のうちだと思っている。
しかし、ITの世界でも、暴力と技術を分離し、暴力は抑止していくべきだ。 >>39
developer forumでは特にCUDAがないと困るとか必要とかの話題はまったくないよ
Metal対応の話題は活気あるが
2010あたりには既にCUDAを積極的に使おうなんて話は見かけなかったように思う
5770/5870対応が必要だったのでnvidia/ATI両対応する方向しかあり得なかった >>41
そういえば、倍精度浮動小数点型(double)が高速に使えるGPGPUは、
AMD製のものにはありましたがnVidia製のものには丁度いいのが余りなかった
記憶があります。数値計算をしたいなら double は必須ですので、
結局 nVidia製のGPGPU は数値計算には向いて無いとその時には
思いました。 >>41
ということは、周りが言うほど必要性は感じられないってことかな。
ただOpenGLとVulkan、OpenCLの対応はしてほしい。OS依存の環境は何時放棄されてレガシーになるか分からん。特にApple、お前だお前。 >>43
ただ、nVidiaにとっては、Macが環境として存在すると思ってやってきたのに
突然その環境自体を壊してしまうのは、独占禁止法に違反している恐れがある。 今後AppleからNVIDIA搭載のハードは出ないって事だよね? 出るんじゃない?
そもそもAMDもCUDAに対応してないんだし、
macOSがハードウェアの性能を活かせないってだけ 2013/09/18 の xcode 5.0 で OpenGL ES のサポートが追加されてまだ
6年ほどしか経ってないが、もう、非推奨なんだね。
若い人の感覚では6年一昔か。 >>47
OpenGL ES そのものではなく、OpenGL ES 3.0 の追加。
なぜか書き込めてなかった。 Metalがある以上必要ないからね
サポートしても足引っ張られるだけで意味がない
どうしてもOpenGL使いたければMetalへのラッパーはあるから
そういうの使えばいいだけだけどパフォーマンス悪化させるだけでいいことないね 移植性が落ちるのと、OS依存のAPI群はOSメーカーからサポート打ち切られたら覚えたことが無駄になるから。
Appleが「あ、もうMetalやめるね」って言い出したら勉強し直しだし、プロじゃないから出来る限りOS依存は避ける。 >>49
Metalへのラッパーはなくならないの?
「非推奨」であって「サポートしなくなるよ」という意味ではないのかい。 こないだ700万のハイエンドPC出してたけど、買った人涙目だな 優れているならAppleが採用するので、Appleが採用していないものは優れていないということだ Q.E.D.
とかいう、Appleがすべての判断基準をネタでも違和感もなく本気で言うから、ここのユーザーは怖いなあと思う ANGLEがMetal使ったOpenGL ES 2.0の対応中だな
3.0にもいつかは対応するだろう
ES使ってれば取り敢えず動かす事は出来そうだ >>4
21年遅いよ君
Chromeffects
https://ascii.jp/elem/000/000/312/312750/
Chromeffectsの必須環境
今回は、マイクロソフトのChromeffectsに関する戦略を紹介したいと思う。前回も書いたとおり、出版社向けの配布はもうすぐ始まるはずだが、一般ユーザーは、いつ、どのようにすればChromeffectsを入手できるのだろうか。
この疑問に答える前に、まずChromeffectsの動作条件を紹介しておこう。これは入手方法にも関わってくる。
●ハードウェア
CPU:Pentium II-300MHz(K6-2-300MHz)以上
メモリー:64MB以上
グラフィック:3DサポートAGPビデオカード(ビデオメモリー4MB以上)
●ソフトウェア
OS:Windows 98
そのほか:Internet Explorer 4.0x以上、DirectX 6.0
まあ、Windows 98ならIE4.0xは標準機能だし、Chromeffectsのランタイムをインストールすれば、DirectX 6.0も自動的にインストールされる。Windows 98なら特になにかを用意しなくても、Chromeffectsは利用できるということだ。 つーかRadeonをGPGPU使うのならROCmサポートしろよまあ現状Linuxのカーネルの実装にベッタリだから恐らくLinuxカーネルで動くMacOSを作るほうが難易度は優しいだろうけど
https://github.com/RadeonOpenCompute/ROCm/issues/18 メタルの使い方の日本語ページ公開してくれるならどうでもいい MacでOpenGLの仕事してる場合、次買うのはWinの方がいいんだろうか
非推奨なだけで使えるのは分かってるんだけど、非推奨と言われると何かあったときに自己責任だよね これがMSだとかだと「非推奨」てあっても皆困るのがわかってると
なあなあでズルズルそのまま放置してくれるけど
アッポウのイシキタカイ人たちは「非推奨」だからもう消すのが正義
とばかりにいきなりガチで消しにくるからな
正直そこまでOSやらパソコンに理想を打ちたてたいその宗教みたいな
潔癖さがさっぱり理解できん
ただの装置だろ
そこまでこだわってどーすんの、っていう macにこだわりなんかない
ずっとwinだったから
iPhone向けにもアプリ出そうとmacに手を出してmac使ってたってだけ
android向けにwinでopenGL、iPhone向けにmacでmetal
androidとiPhoneを相手にする場合、PC二台体制にしなきゃならんのか?と悩んでる
macに手を出したのはandroidもiPhoneも両方いけるから
非推奨で中途半端なことになるからどちらか一方を選ばざるを得ないことになるならandroid winを選ぶと思う >>61
めんどくさいのは、10年以内には絶対iOSのシェアは極端に低くなっていることが
明らかなのに、日本ではiOSのシェアが大きすぎるから、今の段階で無視する訳
には行かないこと。
速く女子高生とかがiOSから離れてくれるように願う。
何とかしてくれ。
日本人にとって絶対的に不利なのがiOSなんだし。 >>62
それな
今の状況を考えると2台持ちせざるを得ない もう一つ言うと
グラフィックやってる人のPCスペックはそこそこ高い
winもmacも両方揃えるってなるとザックリ見積もって最低でも100超えるよね(ソフトウェアや周辺機器含め)
何のための出費?しかも1番高いのは…
そう考えるとアホらしくてな MacOSで非推奨なわけで
iOS/Android開発には関係ないよね >>59
一応WindowsもOpenGLはLegacy Graphics扱い >>66
でも、OpenGLは、今後、MSが公式対応することになった、と先日聞いたばかりだよ。
今まで OpenGL 1.0 までは MSが対応していたが、それより後のは、
wglXxxx() 系関数以外は、MSではなくベンダによる対応ということになっていた。 そもそもAppleにいさんは何が気に入らなかったんだ? せっかく、WebGLとOpenGL ESでGraphic APIが世界で始めて共通化されたと言っても過言では無かった状況で、また梯子外しが始まった。 OpenGLのクロノスグループが100社以上の企業で
形骸化と老害化してて
1企業のアップルの意見が通り難くなったからかな?
使う側からは直接的に命令して使いたいけど
グラボメーカー側はあんましダイレクトに叩かれると補償出来ないし
のせめぎ合い? OpenGLは、SGIがやっていたVer 1.0は超美しい体系を持っていて、
「3Dを良く知っている人が作りました、という感じがする」
などと、3Dグラフィックの専門家からの評判がとても良かった。
ところがOpenGL ESやWebGLの基礎となったOpenGL 1.2はとても汚い。 >>72
MSが公式サポートしたのは、そのVer1.0までで、Ver1.2以後は、
MSは、関数アドレスを取得したり基本的なコンテキストを取得するための
wglXxxx() APIだけを提供して、関数本体はOEMベンダに任せる仕組みになっていた。
そしてなぜか、そっちの部分は強烈に汚い仕様で、
「馬鹿が考えたの間違いなし」
というようなものとなった。 ■ このスレッドは過去ログ倉庫に格納されています