Search Unity

一部グラフィックス機能の非推奨化(Deprecation)と削除について

, 8月 27, 2015

この記事は将来のUnityのバージョンで一部のグラフィックス機能を削除することについて、それがいつか、どのように取り組むかのプランについてのお知らせです。え、なぜ削除するのかって…? 時には捨てることが、レンダリングの輝かしい未来につながるからですよ!

より良い見た目、より速いスピード、そしてより良い柔軟性…私たちがUnityの機能をより良くしようと試みるとき、古い例外処理対応や古いハードのもつ制約への対応が大きな障害になることがあります。基本方針としては、私たちはUnityのバージョンが上がってもすべてが問題なく動作するように努力をしていますが、時には古い制約への対応をやめることで得られるメリットが大きすぎ、またそれによって影響をうける人たちが少ないという状況が発生します。

それではさっそく、グラフィックスについて「将来動作しなくなる」機能のリストを見ていきましょう!ちなみにこれらの内容はあくまでプランであって、主にこれから取り組む変更です。なので、もしあなたがこの中の機能について、本当に、本当に…ほんっとぉーーにずっとその機能が必要がだというならば!ぜひお知らせ下さい!

シェーダー:プリコンパイル済シェーダーアセットのサポートの廃止

プリコンパイル済シェーダーというのは要するに「ソースコードのない」シェーダーアセットのことです。可読性のあるHLSLのコードのかわりにコンパイル済のシェーダーアセンブリもしくはマイクロコード、もしくは複数のプラットフォームに向けた変換済シェーダーコードが含まれています。

プリコンパイル済シェーダーの問題は、(もしあなたが何処かでこれを手に入れて使っているならば)これらのシェーダーは将来追加されるプラットフォームでは動かない、ということです。例えば、あるシェーダーがDirectX 9、OpenGLとOpenGL ES 2.0 用にプリコンパイルされているとしましょう。このシェーダーはコンソールプラットフォームでは動きませんし、MetalやDirectX 11でも動作しません。もうこの理由だけで、プリコンパイル済シェーダーを使うというのは良くない方針と言えます。

もう一つのプリコンパイル済シェーダー対応を削除したい理由は、シェーダーのシリアライズフォーマットを改善して、ディスクスペース、ロード時間およびランタイムでのメモリ消費量をいまより大幅に改善したいからです。現在私たちが使っているシェーダーフォーマットは、まぁ正直に言ってあまり効率のよろしくないテキストベースのフォーマットで、シェーダーのロード時間の観点からもメモリ使用量の観点からも優秀とは言いがたいです。私たちがより効率のよい新しいフォーマットを作って実験してみたところでは、シェーダーバリアントの複雑度によっては数メガバイトから数十メガバイトのレベルでメモリ使用量が大幅に、さらにロード時間も削減されました。しかしながら、この変更を入れると古いUnityがサポートしていたプリコンパイル済シェーダーはもう動作しなくなります。しかし、私たちはこのトレードオフは良いものだと考えています。

この変更のメリット:

  • ゲームデータの中で使われるシェーダーのディスクサイズは大幅に小さくなります。(数%ではなく、数分の1になります)
  • シェーダーのロード時間が全然速くなり、シェーダーの非同期ロードがメインスレッドに与える影響が大幅に小さくなります(つまり、シェーダーのロード理由でのフレーム落ちなどの問題が改善します)
  • ゲームの実行中にシェーダーが締めるメモリが大幅に小さくなります。
  • DX11環境では シェーダーインスペクターで “Show compiled code” を行った時に、意味不明な文字の海の代わりにちゃんとしたシェーダーディスアセンブリを表示できるようになります。

この変更のデメリット:

  • シェダーのプリコンパイル(インスペクターで“show compiled code”を押すと出てくるやつです)が出来なくなります。また、それを使っていたシェーダーは動作しなくなります。

影響する人々:シェーダーをプリコンパイルする人々、さらにその人達からプリコンパイル済シェーダーを提供されて使っている人々。

実施予定: Unity 5.3から (2015年12月)

ハードウェア:DirectX 9 シェーダーモデル 2.0 向け GPU

DX9 シェーダーモデル2.0 GPUは正直かなり古いので、そろそろサポートをやめようと思います!まぁ、ちょっと落ち着いて…これはどう言う意味かというと、次のモデルのようなGPUが非対応になるということです:2004年以前のNVIDIAのグラフィックスボード(GeForce 6000シリーズ以前)、2005年以前のAMDのグラフィックスボード (Radeon X1000シリーズ以前)、そして2006年以前のIntelのGPU (GMA X3000/965 以前)が対象となります。要するに10年前のGPUで動作しているコンピュータでは動かなくなるということです。我々が集めているデータによると、Intel GMA 950 (82945) GPU がたまに見つかるだけで、残りは絶滅しているようです。なので、Intel GMA 950 を使っている人たちの環境では動かなくなります。

この対応は、Unityが Direct X 9 の対応をやめるという話ではありませんよ!DX9はまだまだWindows XPのような環境では唯一の現実的なオプションですし、この環境を使っている人はまだまだ居ます。(シェーダーモデル 3.0 以降対応のGPUによる)Direct X 9 レンダリングサポートは、まだまだUnityではサポートし続けます。

この変更のメリット:

  • シェーダーを書く人々の心が安まります。現在Unityでシェーダーを作成すると、Unityはデフォルトでは「最大公約数として利用可能な技術」を使ってコンパイルします(つまり今は Shader Model 2.0 です)。これを変更するにはイチイチ「#pragma target 3.0」とか書く必要がありますし、Shader Model 2.0のサポートを辞めることができれば、必要最小スペックを押し上げることができ、シェーダーを書くときの対応や心配事が減ります。
  • Unityの中の我々の心が超安まります!!おそらく知りたくもないでしょう…例えば私たちがUnity 5の物理ベースシェーダーの開発において、Shader Model 2.0フォールバック対応に一体どれほどの時間と技術を詰め込んだのか… こいつさえいなければ私たちは本当に役に立つことに時間を使えるんですよ!!

この変更のデメリット:

  • Unityで開発されたゲームが Intel GMA 950 / 82945 GPU で動作しなくなります。

影響する人々:Windows PC向けにゲームを開発している開発者。

実施予定:Unity 5.4 (2016年3月)

ハードウェア:Windows ストアアプリにおけるDirectX11 機能レベル 9.1 のGPU

ほとんどすべてのWindowsストアアプリ対応デバイスは少なくともDirectX11 機能レベル9.3に対応しています(Windows Phoneデバイスは全てが対応)。しかしながら、過去に機能レベル 9.1 のデバイスが1つか2つリリースされており、それが私たちの必要対応最低スペックを押し下げています。

この変更のメリット:

  • すべてのWSA/WP8 シェーダーは機能レベル9.1の代わりに9.3でコンパイルされます。これにより複数レンダーターゲット(multiple render target)、ピクセルシェーダーの差分命令(derivative instructions, ddx()やddy()など)のような、以前は動作しなかったいくつかの機能が使えるようになります。
  • 9.1対応のために必要だったプログラムを大幅にUnityから削除出来ます。

この変更のデメリット:

  • あなたが開発したWindows Storeアプリは9.1対応デバイスでは動作しなくなります。これはまぁ別の言い方をすると「Surface RT タブレットで動作しなくなります」と大体同じ意味です。すべてのWindows Phoneは9.3対応以上なので、Windows Phoneへの影響はありません。

影響する人々:Windows Storeアプリ開発者。

実施予定:Unity 5.4 (2016年3月)

シェーダー:Android OpenGL ES 2.0における「ネイティブシャドウマップ」サポート

シャドウマップの処理は大きく分けて2つの方法があります。「GPUの機能で対応する(ネイティブ方式)」と「自分で処理する(マニュアル方式)」です。GPUの機能で対応する方式では、シャドウマップのサンプリングを行うと直接「影の値」が返ってきます。その際にハードウェアによるPCFフィルタリングが利用できることがあります。自分で行う場合は、主にシャドウマップのデプスをサンプリングして、サーフェイスのデプスと比較して対象が影の外か中かをチェックします。

この2つの方式では多くのGPUが「コストなしで使える」2×2のPCFフィルタリングを提供しているので、大体の環境においては最初のやりかたが望ましいのですが、AndroidのOpen GL ES 2.0はちょっと違う状況ににありまして、いくつかのデバイスは EXT_shadow_samplers 拡張による「ネイティブシャドウマップ」方式に対応しているものの、対応していないデバイスも結構あるのです。これがどういう事を意味するかというと、Android ES 2.0 向けのシェーダーはこの2つのケースを両方対応するために、両方のバリエーションをコンパイルしてゲームに含めるようにしている、ということです。

しかしながら、実際にまた現実のデータを見てみますとEXT_shadow_samplers 拡張をサポートしているAndroidというのは極めてレアで、すべてのデバイスのうち精々1~2 % しかないことが分かりました。これなら、私たちはこの対応をいっそ削除してしまってすべてのAndroid ES 2.0 デバイスでマニュアル方式を採用するほうがよいと考えます。

この変更のメリット:

  • Android ES 2.0対応デバイスに向けたシェーダーではシェーダーバリアントが減り、コンパイル、ディスク、ランタイムでのロードが改善します。

この変更のデメリット:

  • おおむね1% のAndroid ES 2.0 デバイスでハードウェアによる影処理とPCFサンプリングが出来なくなり、かわりにそれよりほんのちょっとだけ遅いデプス比較のためのシェーダーコードで対応されるようになります。ちなみに全てのこれら1%に該当するデバイスはビルトインPCFが利用可能なOpenGL ES 3.0に対応しているので、そちらの対応を含める方が得策です!

影響する人々:OpenGL ES 2.0 デバイスをターゲットにしているAndroid アプリ開発者。

実施予定:Unity 5.4 (2016年3月)

53 replies on “一部グラフィックス機能の非推奨化(Deprecation)と削除について”

Delighted to hear about precompiled shader deprecation for the side-reason that it’s impossible to tell when some AssetStore shaders are actually precompiled shaders until you’ve purchased them (you can’t tell by looking at the asset’s file list the same way you can looking for DLLs to check for precompiled binaries.) Looking forward to these assets no longer working (although some of them will doubtless move to intentional obfuscation of the HLSL.)

When i playing ifscl game (created with unity) its always not responding. The developer was say “your graphics card is to weak” but i dont know what is graphics card. So what is grapichs card and how i fix that problem?

I like the current direction of Unity. I always had the feeling that Unity cares too much on lower end and lower important techniques. With Unity 5 I am looking more confident in the future of high definition desktop development with Unity.

native shadow map? so what are we using for shadows in opengl e.s. 2.0, won’t it become much more slower?

does that mean on opengl es 2.0 devices, dynamic shadows have different settings, how will it actually affect performance?

While i support this decision to push unity graphic for the future,
what i’m curious is how is it gonna affect mobile developer?
Say GearVR for example, will it still runs Unity games?

[…] Plans for Graphics Features Deprecation – az 5.3-as verzióval a Unity engine nyugdíjba küld néhány feature-t. […]

The Dx9 drop part scared me. Then noticed it will still be available. On my machine Dx11 is very slow in Unity. I can run Dx11 games great but Unity runs 2x slower. So I have to use Dx9.

I love cleanup like this, old devices sometimes slow our progress without clear advantage. Is there a graph or a chart that shows which GPUs are mostly used in the wild these days?.

Cheers.

Thanks Aras – cleaning the old before adding the new (and discuss it in advance) is good thing!

One maybe offtopic question – Unity 5 Standard Shader – will there be finally a way directly in editor to choose individually (per texture) the UV channel (example UV0 for diffuse and UV1 for AO) – feature needed and promissed long ago…?

The same question applies to the option to change the tiling settings individually per texture (as was possible in older versions)…

These limitations are very unfortunate and seem so easy to fix… at least to a naive amateur :-)

How about you deprecate some very persistent bugs as well? Like the spotlight shadows that stop drawing WAY to soon when you get closer to an object. Related to graphics.
It’s a 6 year old bug that makes spotlights virtually useless if you want them to cast shadows.

Good idea to ask about removing functions before you actually do it unannounced.

Lightmapping.LockAtlas (since Unity3) and LighProbes.asset file (Unity4) has been removed in Unity5 without warning – killing useful Lightmapping techniques (changing Lightmaps/Lightprobes at runtime) for mobile devices without warning. Any chance of getting them back? See this

I love my Surface RT. I guess it’s time for an upgrade.

Will the Surface RT 2 (Tegra 4) continue to be supported?

hey, is “Windows Store Apps DX11 feature level 9.1 ”
a baseline requirement still for WSA applications?

Or has this changed? If not, then how do we target 9.1 level to clear the WACK?

From what I read you have to keep an old version of Unity around to do that but maybe I misinterpreted what was said by the blog article author.

I’m actually a person that still uses a Intel GMA 950 but am patiently awaiting a Skylake Mac Mini. Until then, I am going to buy a used i5 2nd gen because I’ve found the GMA 950 based Mac Mini even struggles to browse on eBay. That’s the other interesting I found out is my computer struggles more with internet browsers than with Unity. I think it has something to do with multiple instances of flash on an ad heavy web site like eBay but ain’t sure.

Personally, I plan on only publishing using DirectX 12 and Vulkan capable when it becomes available, and when publishing, publish to machines that support Android 4.4, openGL 3.0, and DirectX 11, although I know that I could publish to lower specifications I also know that that creates support scenarios I don’t have the HW for.

Really glad to see that you guys are starting to push through old Unity Engine innards and clean things up, tremendously support this initiative and I hope that you guys will work on some of the more hard ingrained weaknesses / quirks of the engine, too.

Keep going.
If something goes wrong I can export my project as unitypackage and import it back to 5.3 to wait for fix

Yay to all of them! Great stuff Aras. Especially the first one coming in 5.3, the new shader format, would _greatly_ help out some projects I’m involved in. Those hickups have been maddening! Thanks for the blog :)

A graph-based shader tool is as good as the guy who wrote it, plain and silmpe… There has been many attempts, but not many graph-based shader tools exist or are being used effectively. I can agree that some graph-based tools are clunky, generate ugly and bad performing code, and make it harder on the developer to take full control of the output. This doesn’t have to be the case!I’ve been developing a graph-based tool for 8 years now called ShaderWorks which was pulled in by Activision a long time ago. I’ve been beating my head against a wall from day one, I knew this type of tool was very very powerful, but was on the fence about how well of a code generator and shader prototyping power it could be.Only until version 4.0 have I jumped completely on the “graph-based” side of the fence. The main things holding me back was that the code being generated was inherently horrid to look at and the template code which defined the graph/block/node and shader code was just too annoying to deal with. Even though not many have this figured out, I can honestly say it is possible to fix.In most generators, there tends to be a ton of variable indirection and redundancies which make the generated code ugly ( if not done right ) but regardless these things are silmpe for the compiler to optimize away.Another concern was weather or not to generate nested code ( all in one shader function ) from the graph blocks or to generate per-block functions. Either way seems to generate comparable performance but I chose function based as it keeps things very readable and clean and it lets the function inputs/outputs rename the variable names so everything ties in better with the templates.A well done code generator can actually do a perfect job at packing / unpacking interpolator registers and making that part SO SO much easier to manage and change. So with those things covered, what is left that could be slower compared with hand written shaders? Not much since the code written in the graph templates are written by us, the developer, the same people writing the hand coded shaders, so any per shader optimization can easily be done in template, afterwards manually in your very clean shader output

Actually, that will break some of our shaders. We’re currently using a hack to get custom depth write working for our compiled surface shaders, since Unity doesn’t make it possible to write custom depth in a surface shader. So we changed the compiled code, and it works for us. (We even made a tool that automatically adds depth property to any compiled surface shader). But that will stop working. :/

It wouldn’t be a problem if Unity started to support custom depth write in surface shaders. Then we wouldn’t have had to hack it at all to begin with.

Comments are closed.