Unity计划放弃支持部分图形特性
着色器（Shader）:去掉对“precompiled(预编译)” shader assets的支持
-
着色器在你的游戏数据文件中占用更少的空间；
-
着色器加载速度更快，尤其是在主线程中异步加载时“打嗝”少得多；
-
运行时着色器占用更少的内存；
-
预编译着色器（在检视面板中的“show compiled code”），且在随后直接使用这些代码将不再被支持。
硬件：停止支持DirctX 9 Model 2.0的GPUs
硬件：停止支持Windows Store APP DX11 featurelevel 9.1 GPUs
着色器：停止在android OpenGL ES 2.0上支持“native shadow maps”
PLANS FOR GRAPHICS FEATURES DEPRECATION
This is a heads-up of graphics related things we plan to “drop” from future versions of Unity, a.k.a. Dropping of Things for Make Benefit Glorious Future of Rendering.
Sometimes when we try to make things better (better looking, faster, more flexible, etc.), we find that some old corner case or old hardware limitations get in the way. In general, we try to keep as much as possible working between versions of Unity, but sometimes the potential benefit of removing legacy functionality is just too great and said functionality hopefully affects very few people (if any).
So without further ado, here’s a tentative list of graphics related “it will stop working” items. Note that all these are “planned” and not actually done yet, so if you really, really need them to keep on working forever, let us know!
Shaders: Drop support for “precompiled” shader assets
A “precompiled” shader is the one that effectively comes “without source code”. Instead of having readable HLSL code in there, these shaders contain already compiled shader assembly or microcode or translated shader code for several platforms.
One problem with “precompiled” shaders (if you got them from somewhere) is that they will not work on platforms that might appear in the future. Say you’ve got a shader that was precompiled for DX9, OpenGL and OpenGL ES 2.0. This shader will not work on consoles, Metal, DX11 and so on! Hence using precompiled shaders is typically a bad practice for this reason alone.
Another reason why we want to remove support for them is because we want the shader serialization format to be much more efficient in disk storage, load times and runtime memory usage. The shader format we had so far was, shall we say, fairly inefficient text-based format that resulted in long shader load times and high memory usage. In our current experiments, we’re seeing big reductions in both of these (megabytes to dozens of megabytes saved depending on shader variant complexity, etc.) by changing to more efficient shader data format. However, that makes these “precompiled with old version of Unity” shaders not work anymore. We think that’s a fair tradeoff.
Advantages:
- Shaders take up less space in your game data files (multiple times smaller).
- Shaders load much faster, and especially the “hiccups on the main thread” while loading them asynchronously are much smaller.
- Shaders take up a lot less memory at runtime.
- “Show compiled code” in shader inspector will display actual shader disassembly on DX11, instead of a not-very-usable sea of vowels.
Disadvantages:
- Precompiling your shaders (“show compiled code” from shader inspector) and then later on using that code directly will stop working.
Affects: People who precompile shaders, and people who got precompiled shaders from someone else.
When: Unity 5.3 (2015 December)
Hardware: Drop support for DirectX 9 Shader Model 2.0 GPUs
DX9 SM2.0 GPUs are fairly old and we’d like to drop support for them! This would mean that these GPUs would stop working in your Unity games: NVIDIA before 2004 (pre-GeForce 6000), AMD before 2005 (pre-Radeon X1000)and Intel before 2006 (pre-GMA X3000/965). In short, GPUs older than 10 years or so would stop working. Looking at the data, it seems that it’s only Intel GMA 950 aka 82945 GPU that is still sometimes found in the wild these days — so that one would stop working.
Note that we’re not dropping support for DirectX 9 as a whole! Often that is still the only practical option on Windows XP, which just isn’t going away… DirectX 9 rendering support (on Shader Model 3.0 or later GPUs) will continue to be in Unity for quite a while.
Advantages of doing this:
- Less hassle for people writing shaders. Currently, all newly created shaders in Unity are compiled to “lowest common denominator” by default (shader model 2.0) and if you want any of more advanced features (vertex textures, dynamic branching, derivatives, explicit LOD sampling etc.), you need to add things like “#pragma target 3.0” etc. If we’d drop SM2.0 support, the minimum spec goes up and you don’t have to worry about it as much.
- Way, way less hassle for us internally at Unity. You don’t want to know, for example, how much time we’ve spent on trying to cram Unity 5 physically based shaders into DX9 SM2.0 fallbacks. We could be doing actually usefulstuff in that time!
Disadvantages:
- Unity games would no longer work on Intel GMA 950 / 82945 GPU.
Affects: Windows standalone player developers.
When: Unity 5.4 (2016 March).
Hardware: Drop support for Windows Store Apps DX11 feature level 9.1 GPUs
Almost all Windows Store Apps devices are at least DX11 feature level 9.3 capable (all Windows Phone devices are). But there were one or two devices in the past that only supported feature level 9.1, so that dragged down the minimum spec that we had to support.
Advantages of doing this:
- All WSA/WP8 shaders will be compiled to feature level 9.3, instead of 9.1, gaining some more functionality that wasn’t working previously (multiple render targets, derivative instructions in pixel shaders etc.).
- We get to remove quite some code that had to deal with 9.1 limitations before.
Disadvantages:
- Your Windows Store Apps would no longer support 9.1 devices (in practice this pretty much means “Surface RT tablet”). Note that Windows Phone is not affected, since all phones have at least 9.3 support.
Affects: Windows Store Apps developers.
When: Unity 5.4 (2016 March).
Shaders: Drop support for “native shadow maps” on Android OpenGL ES 2.0
Shadow mapping can be done using either “native GPU support for it” (sampling the shadowmap directly returns the “shadow value”, possibly also using hardware PCF filtering), or “manually” (sample depth from the shadowmap, compare with surface depth to determine whether in or out of shadow).
The first form is usually preferred, especially since many GPUs can provide 2×2 PCF filtering “for free”. On majority of platforms, we know ahead of time which of the shadow modes they support, however Android OpenGL ES 2.0 was the odd one, since some devices support “native shadow maps” (via EXT_shadow_samplers extension), but some other devices did not. This meant that for any shadow related shader, for Android ES 2.0 we’d have to compile and ship two variants of the shader to cover both cases.
However, we looked at the data and it seems that support for EXT_shadow_samplers on Android is extremely rare (1-2% of all devices). So we think it’s worth it to just remove support for that; we’d just always treat Android ES 2.0 as “manual depth comparison for shadows” platform.
Advantages of doing this:
- Less shader variants to compile, ship and load at runtime on Android ES 2.0.
Disadvantages:
- About 1% of Android ES 2.0 devices would no longer do hardware shadow PCF sampling, but instead do a slightly slower depth comparison in the shader. Note, however, that all these devices can use OpenGL ES 3.0 which has built-in PCF, so it’s better to include support for that!
Affects: Android developers targeting OpenGL ES 2.0.
When: Unity 5.4 (2016 March).
浙公网安备 33010602011771号