Search Unity

ГРАФИЧЕСКИЕ ФУНКЦИИ, ОТ КОТОРЫХ МЫ ПЛАНИРУЕМ ОТКАЗАТЬСЯ

, 27 августа, 2015

Эта новость посвящена тому, что из графики мы планируем удалить из будущих версий Unity.

Многим знакома ситуация, когда попытка улучшить продукт — сделать графику красивее, улучшить быстродействие, гибкость — сталкивается с ограничениями, не зависящими от вас.

Как правило, мы пытаемся добиться максимальной преемственности версий Unity. Однако некоторые устаревшие элементы попросту мешают дальнейшему развитию Unity, и остается надеяться, что их удаление не повредит разработчикам.

Мы составили предварительный список элементов, которые вскоре пойдут «под нож». Пока еще мы ничего не трогали, поэтому, если вам крайне необходим какой-то из них — сообщите нам!

Шейдеры: поддержка предварительно собранных шейдеров

Имеются в виду случаи, когда применяются шейдеры, которые вместо исходного кода на HLSL используют предварительно собранные фрагменты (микрокод, ассемблер, транслированный код для нескольких платформ).

У такого подхода есть несколько недостатков. Во-первых, предварительно собранные шейдеры не будут работать на более новых платформах, чем те, для которых они были собраны. Допустим, шейдер для DirectX 9, OpenGL и OpenGL ES 2.0 будет бесполезен для игровых приставок, Metal, DirectX 11 и т.д.

Во-вторых, мы собираемся улучшить процесс сериализации шейдеров. Текстовый формат, используемый сейчас, не отличается эффективностью, занимает много памяти и увеличивает время загрузки. Новый формат, с которым мы экспериментируем, серьезно улучшил бы ситуацию (в зависимости от сложности шейдера могут освобождаться десятки мегабайт памяти), но за это придется заплатить совместимостью с шейдерами, собранными для предыдущих версий Unity.

Преимущества:

  • Шейдеры будут занимать в несколько раз меньше места на диске.
  • Загрузка шейдеров ускорится, исчезнет «торможение» основного потока при асинхронной подгрузке шейдеров.
  • Шейдеры будут занимать меньше оперативной памяти.
  • Функция Shader Inspector «показать собранный код» будет выдавать ассемблерный код для DirectX 11, а не бесполезный набор символов

Недостатки:

  • Невозможно будет использовать предварительно собранные шейдеры.

Кого коснется: разработчиков, которые предварительно собирают или используют предварительно собранные шейдеры.

Когда: Unity 5.3 (декабрь 2015 г.)

Устройства: поддержка графических процессоров, использующих DirectX 9 Shader Model 2

Мы собираемся прекратить поддержку старых графических процессоров, использующих DirectX 9 SM2.0. Unity перестанет работать на устройствах NVIDIA, произведенных до 2004 г. (до серии GeForce 6000), AMD до 2005 г. (до Radeon X1000) и Intel до 2006 г. (до GMA X3000/965) — то есть, в основном, на устройствах старше десяти лет. Статистические данные показывают, что из таких процессоров «в строю» остались в значительном количестве только Intel GMA 950 (82945 GPU).

Это не означает, что мы отказываемся от поддержки DirectX 9! Мы понимаем, что многие игроки до сих пор используют Windows XP, для которой поддержка DirectX 9 необходима. Unity будет поддерживать DirectX 9 — для графических процессоров с SM3.0 и выше — ещё долгое время.

Преимущества:

  • Меньше ненужной работы при написании шейдеров. На данный момент все шейдеры по умолчанию собираются для модели 2.0, и для использования более развитых функций (вертексные текстуры, динамическое ветвление, деривативы, явный семплинг LOD и т.п.) необходимо писать дополнительный код (например, добавлять «#pragma target 3.0»). Отказ от поддержки SM2.0 исправит ситуацию.
  • Гораздо меньше ненужной работы для нас. За то время, что мы потратили, пытаясь заставить физически точные шейдеры Unity 5 работать с SM2.0, мы бы могли сделать что-то гораздо более полезное

Недостатки:

  • Unity перестанет работать с графическими процессорами Intel GMA 950 / 82945 GPU.

Кого коснется: разработчиков приложений для Windows.

Когда: Unity 5.4 (март 2016 г.).

Устройства: Поддержка Windows Store Apps DX11 Feature Level 9.1

Большинство устройств, поддерживающих Windows Store Apps, имеет DirectX 11 Feature Level 9.3 (все смартфоны Windows Phone именно такие). Однако существует некоторые количество устройств, ограниченных Feature Level 9.1, поэтому нам приходится постоянно оглядываться на совместимость с 9.1.

Преимущества:

  • В средах WSA/WP8 все шейдеры будут собираться для Feature Level 9.3 вместо 9.1, что откроет недоступную ранее функциональность (многобуферный рендеринг, деривативные инструкции для пиксельных шейдеров и т.п.).
  • Мы сможем отбросить ставшие ненужными «костыли» для обхода ограничений 9.1.

Недостатки:

  • Прекращение поддержки устройств с Feature Level 9.1 (в основном, планшетов Surface RT). Устройства Windows Phone не пострадают.

Кого коснется: разработчиков приложений Windows Store Apps.

Когда: Unity 5.4 (март 2016 г.).

Шейдеры: Поддержка нативного рендеринга теней для Android OpenGL ES 2.0

Рендеринг теней может выполняться двумя способами: или с использованием нативной поддержки графического процессора (семплинг карты теней непосредственно возвращает значение затененности, возможно использование фильтрации PCF), или вручную (сопоставлением интенсивностей из карты теней с реальными значениями для определения затененности).

Предпочтительным считается первый вариант — особенно с учетом того, что многие графические процессоры предоставляют фильтрацию 2×2 PCF. Однако в случае с платформой Android OpenGL ES 2.0 возникают сложности. В отличие от большинства платформ, для которых поддержка различных режимов обработки теней фиксирована, она может либо поддерживать, либо не поддерживать нативный рендеринг с использованием расширения EXT_Shadow_Samplers. Из-за этого приходится создавать два варианта шейдеров для Android ES 2.0.

Исследование показало, что на самом деле поддержка EXT_shadow_samplers на Android встречается крайне редко (1–2% всех устройств). Поэтому мы считаем, что поддержку этого варианта можно опустить и сделать режим «ручного сопоставления интенсивностей» используемым по умолчанию для Android ES 2.0.

Преимущества:

  • Упрощение работы с шейдерами для Android ES0.

Недостатки:

  • Приблизительно 1–2% устройств, использующих Android ES 2.0, будут несколько медленнее обрабатывать шейдеры из-за перехода к сопоставлению интенсивностей. Так как такие устройства обычно совместимы с OpenGL ES 3.0, имеющим встроенную функциональность PCF, рекомендуется использовать именно этот интерфейс.

Кого коснется: разработчиков, имеющих дело с OpenGL ES 2.0.

Когда: Unity 5.4 (март 2016 г.).

53 replies on “ГРАФИЧЕСКИЕ ФУНКЦИИ, ОТ КОТОРЫХ МЫ ПЛАНИРУЕМ ОТКАЗАТЬСЯ”

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.

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

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.

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.