На iPhone нет способа вручную настроить шейдеры. Стоит отметить, что на iPhone, в частности, нет оптимизаций, которые вы можете сделать, чего не может компилятор. Тем не менее, GLSL-компилятор, вероятно, будет бить или соответствовать вашей сборке, настроенной вручную.
Однако на ПК я лично не верю, что драйвер должен знать, что шейдер шлейфа должен использовать меньше регистров и больше инструкций для достижения большей пропускной способности за счет более высокой загрузки. Водителям просто не хватает контекста, чтобы все время делать правильный выбор. Специфичные для данных оптимизации во время компиляции являются отличным примером этой проблемы.
Как человек, который фактически посмотрел на вывод сборки компилятора GLSL и попытался отыграть стратегию распределения регистров компилятора, я могу вам сказать, что отсутствие доступа к сборке абсолютно снижает производительность (на ПК есть некоторые общедоступные инструменты от NVidia и AMD, которые позволяют это делать). Компромисс в использовании сборки состоит в том, что каждый шейдер должен быть настроен вручную для каждой поддерживаемой детали, чтобы достичь максимально возможной производительности. Хотя это немного экстремально, если я хочу потратить свое время на тонкую настройку рендеринга для каждой видеокарты, которую поддерживают мои продукты, я смогу это сделать. Более практичным примером будет ручная настройка для видеокарт низкого уровня, но позволить компилятору GLSL справиться со своей задачей на более высококачественных видеокартах.
Кроме того, автономные компиляторы обеспечивают механизм безопасности. Многие видеоигры сегодня полагаются на драйверы для имитации многих функций, доступных в современных графических API. Как разработчик игр, работающий в области «игра как услуга» на ПК, я могу вам сказать, что очень неудобно получать вызовы среди ночи из-за незначительной ошибки GLSL в недавно выпущенном графическом драйвере , Ошибки водителя сильно влияют на общий опыт игрока. Большинство игроков просто думают, что ваша игра сломана, и в результате вы можете потерять игроков (и мы, вероятно, имеем). Возможность компилирования по одному разу для каждой поддерживаемой видеокарты и ручная настройка по факту была бы огромной победой в этом отношении. Это просто означает, что водителю придется выполнять меньше работы. Код - это зло, поэтому чем меньше кода выполняется, тем лучше =).
В качестве примечания я сделал следующую демонстрацию, используя подход 'compile' - 'view assembly' - 'modify' - 'repeat': http://www.youtube.com/watch?v=km0DpZUgvbg. Я могу сказать вам со 100% уверенностью, что смогу еще больше улучшить производительность этого трассировщика лучей с ассемблером, и AFAIK, это самый быстрый воксельный трассировщик лучей, чье существование было опубликовано (так было в марте 2012 года, но скорее всего уже не правда). Неудивительно, что каждый раз, когда выходил новый драйвер, я видел, как производительность этой демонстрации снижалась с 125-130 кадров в секунду до 30 кадров в секунду - и все это потому, что водитель не знал, как правильно оптимизировать мой шейдер. Это означает, что мне придется повторять процесс оптимизации каждый раз, когда выходил новый драйвер, что заставляло меня просто законсервировать проект (ACK!). Несмотря на то, что мой воксельный raytracer может эффективно работать с большим количеством оборудования, драйверы в настоящее время делают невозможной поддержку этой технологии в полном продукте. У меня просто нет веса, чтобы применить эту технологию в действии, потому что это потребовало бы, чтобы поставщики драйверов знали, каким образом им нужно оптимизировать мой шейдер. Сколько других технологий было бы возможно, если бы у нас был просто прямой доступ к шейдерам сборки? Это означает, что отсутствие доступа к сборке на самом деле является серьезной ценой. Для всех, кто находится в этой должности, я рекомендую следующее: Используйте язык ассемблера NVidia, когда это возможно, и переходите к GLSL, когда это не так. Если мы покажем преимущество сборки над GLSL, то, надеюсь, мы получим первоклассную поддержку сборки от всех поставщиков =).
И, наконец, не выбирать другого автора, но я хочу отметить, что аргумент «Николя Боласа» почти полностью ошибочен (извините, Николь, я ничего не имею против вас, но я хотел бы отметить несколько популярных аргументы, которые просто не выдерживают этический тест). Обратите внимание, что ошибочный аргумент не означает, что конкретный вывод является неправильным - просто приведенный аргумент просто ошибочен.
«Почему? Вы не доверяете компилятору выполнять свою работу? Вы действительно думаете, что знаете достаточно о рассматриваемом графическом процессоре, чтобы иметь возможность постоянно побеждать компилятор?»
- Это не аргумент. Это просто вопрос, на который многие люди не могут придумать реального ответа. Поэтому они приходят к выводу, что они должны просто доверять компилятору. Это препятствует дальнейшему изучению последствий доверия к компилятору и предотвращает логический анализ фактических плюсов и минусов. Кроме того, использование слова «действительно» в вашем втором вопросе подразумевает, что кто-то, отвечающий «да», должен быть введен в заблуждение. Это также намекает на то, что вы думаете о себе, Николь, - это означает, что вы цените свое мнение выше всех остальных, и любой, кто не думает, что вы, должен иметь с ними что-то не так (не то, что они ошибаются, но что они имеют что-то не так с ними - большая разница). Тем не менее, вы могли бы хотеть занять некоторое время, чтобы подумать о вашем мыслительном процессе, ваших чувствах и вашем эмоциональном состоянии. Использование этого подхода серьезно ограничит вашу способность к обучению, так как вы не будете оспаривать свои собственные идеи с достаточной тщательностью. Пожалуйста, прекратите использовать этот аргумент. Это не здорово и не этично.
"В конце концов, вам просто нужно будет доверять компилятору, созданному людьми, которые создали ваш графический процессор. Ни у кого больше нет проблем с этим в наши дни."
- У меня проблема с этим. Кроме того, даже если бы ни у кого не было проблем с этим, это все равно не имело бы значения. Дело в том, что использование сборочных шейдеров может принести пользу. Тем не менее, консенсус не означает правильность. Кроме того, этот аргумент особенно неэтичен, потому что подразумевается, что «в наши дни ни у кого нет проблем с этим, поэтому, если у вас есть проблемы с ним, вы должны быть странными или устаревшими в своем мышлении». У людей есть естественное желание вписаться, и использование этого аргумента является способом разделения людей по этому вопросу и преследования людей, которые не думают, как вы. Тем не менее, этот аргумент особенно коварен из-за его последствий. Пожалуйста, не используйте этот аргумент.
Николь, обе твои ошибки подразумевают, что ты прав и нормален, и любой, кто с тобой не согласен, неправ и имеет с ними что-то не так. Это крайне нездоровые точки зрения, и вы должны тщательно их изучить для определения своего психического здоровья и карьеры.
Для дальнейшего использования: http://en.wikipedia.org/wiki/List_of_fallacies#Formal_fallacies
Спасибо!