Часть 6: Интервью с Геннадием Ригером (ATI Technologies)
СОДЕРЖАНИЕ
- Часть 1 — Теория и архитектура
- Часть 2 — Практическое знакомство
- Особенности видеокарт
- Конфигурации стендов, список тестовых инструментов
- Результаты синтетических тестов
- Часть 3 — Результаты игровых тестов (производительность)
- Часть 4 — Сравнение качества рендеринга в играх
- Краткое введение в AVIVO
- Подведение итогов
- Новые технологии: вопросы и ответы. Интервью с Геннадием Ригером (ATI Tech.)
Новые технологии ATI Technologies: интервью с Геннадием Ригером.
iXBT.com: Назовите себя и кем Вы работаете в ATI.
Меня зовут Геннадий Ригер (Guennadi Riguer). В ATI я возглавляю команду инженеров, занимающихся поддержкой разработчиков в Северной Америке и зачастую за ее пределами. Моя команда тесно работает со многими разработчиками игр, помогая им внедрять новые графические технологии.
iXBT.com: Являются ли R520 и RV5XX чипами, полностью поддерживающими SM3, c точки зрения ATI; с точки зрения MS? Сертифицирует ли MS их (драйверы) на соответствие SM3? Какие требования для этого должны быть выполнены? Что означают слухи и разговоры о неполной совместимости с SM3, и имеют ли они под собой какую-либо почву?
Все карты семейства Radeon X1000 полностью удовлетворяют требованиям по поддержке SM 3.0. С точки зрения Microsoft, карточки полностью проходят WHQL сертификацию. Для тех, кто не знает, WHQL (Windows Hardware Quality Labs) тестирование предназначено для проверки совместимости с Windows и на соответствие необходимых спецификаций. Частью WHQL по проверке графических возможностей является Display Compatibility Test (DCT) kit. Этот набор для тестирования доступен на сайте Microsoft, и скептики могут сами протестировать свои карты и убедиться, что все представители Radeon Х1000 семейства проходят все необходимые SM 3.0 тесты. Что касается удовлетворения требований разработчиков, то с точки зрения спецификации API вся необходимая минимальная SM 3.0 функциональность присутствует. Минимальные требования из документации DireсtX® 9: вершинный шейдер 3.0, пиксельный шейдер 3.0. Теперь о слухах. По определению слухи беспочвенны, иначе они были бы не слухами, а фактами. Я лично предпочитаю оперировать фактами, а слухи это для старушек у подъезда, или для тех, у кого слишком много свободного времени. На мой взгляд, за последнее время чрезмерно много внимания было уделено слухам о SM 3.0 совместимости различных производителей видеокарт. Удивительно, что фактам уделяется намного меньше внимания, чем слухам.
iXBT.com: Почему отсутствует доступ к текстурам из вершинных шейдеров, какие соображения могли повлиять на это решение, не может ли это стать препятствием для сертификации на полное соответствие SM3? Не вызовет ли этот ход недовольство разработчиков?
Не стану отрицать, доступ к текстурам из вершинных шейдеров — штука полезная. Несмотря на это, отсутствие выборки из текстур в вершинных шейдерах X1000 семейства было осознанным архитектурным решением. Полноценные текстурники, позволяющие быструю выборку и поддерживающие фильтрацию различных форматов, занимали бы немалую площадь на кристалле чипа, особенно учитывая, что в Х1800 чипе 8 вершинных конвейеров. С другой стороны, имплементация неполноценных текстурников, на мой взгляд, существенно ограничивает практичность использования этой интересной функциональности. Это значит, что внедрение выборки текстур в вершинных шейдерах в реальные игровые проекты было бы достаточно слабым, и для большинства игровых приложений кусок чипа был бы просто незадействованным. Для производителей чипов это равносильно выбрасыванию денег на ветер. До сих пор я не видел ни одной вышедшей Direct3D игры, поддерживающей выборку текстур в вершинных шейдерах. Единственная на сегодня OpenGL игра с поддержкой этого рода функциональности — ИЛ-2. Кстати, очень отрадно отметить, что именно Российский разработчик 1С продвигает передовые графические технологии.
Я сомневаюсь, что разработчики будут разочарованны и тем более недовольны нашим решением. Мы предлагаем альтернативное решение под названием render-to-VB. Но это тема для отдельного разговора.
iXBT.com: В чипе есть широкие возможности по работе с FP16 буфером рендеринга, включая даже MSAA — то, что отсутствует у самых новых чипов NVIDIA и, одновременно, не наблюдается даже билинейной фильтрации FP16 текстур, которая есть в последнем семействе NVIDIA. Чем вызвана такая асимметрия — не очень логичная с точки зрения разработчиков, которые не признают программную реализацию фильтрации в шейдере эффективной, по крайней мере, на текущем поколении железа. Планируется ли поддержка FP16 фильтрации в будущем (R580? Или далее?)? Не ударит ли это решение по HDR столь продвигаемой ныне ATI.
Когда проектируется чип, то приходится принимать решение какие функции имплементировать, а какие оставить «за бортом»; какие должны быть быстрее, а для каких производительность не очень важна. Это обычная часть проектирования, и каждый раз производится такой анализ на основании ключевых игровых приложений и технологий, которые, по нашему мнению, будут наиболее популярны среди разработчиков в ближайшее время. Если это не делать, а помещать в чип все что хотелось бы, то он получится еще больше, с более высоким потреблением энергии при меньшей производительности. Сразу вспоминается старый анекдот об изобретении в Советском Союзе сверхбольшой интегральной схемы с 40 ножками… и двумя ручками.
Я с удовольствием поделюсь нашими соображениями — почему фильтрация FP16 текстур не материализировалась. Когда мы анализировали перспективные методы имплементации HDR, было выявлено, что 10- и 16-битовые целочисленные и FP16 форматы представляют особый интерес, как для хранения текстур, так и для рендеринга. Что касается FP16, то, на наш взгляд, наиболее важен альфа-блендинг и после него мультисэмплинг, а уж потом фильтрация. Отсутствие альфа-блендинга не позволит отрисовать сцены с полупрозрачными объектами, дымом и другими эффектами. Эмуляция блендинга в шейдере с использованием дополнительных рендер буферов в принципе возможна, но дорогостояща в плане ресурсов и производительности. Отсутствие мультисэмплинга очень негативно сказывается на реалистичности сцен — основной причины использования таких технологий как HDR. В это же время, фильтрация FP16 текстур не столь критична для HDR по нескольким причинам. Позвольте пояснить. Во-первых, очень большой диапазон значений нецелесообразен на данном этапе развития игровой индустрии, да и вообще не особо нужен. Так как разработчики игр обычно разрабатывают проекты для широкого спектра «железа», то игры должны работать достаточно хорошо как на «high-end», так и на «low-end» карточках с практически одним и тем же набором текстур и другого художественного оформления. Это накладывает своеобразные ограничения на используемый диапазон значений интенсивности света.
Существует несколько возможных использований форматов с повышенным диапазоном значений для HDR имплементаций. Во-первых, это текстуры, а во-вторых, это дополнительная обработка сцены (post-processing). Широкое использование FP16 формата для текстур не целесообразно. На данный момент, в большинстве случаев, в играх используются текстуры в сжатых форматах, и переход на FP16 потребует 8-ми кратного увеличения объема памяти для HDR текстур. Даже 512 Мб видеопамяти будет недостаточно. Я уже не говорю о падении производительности. Завершающая обработка сцены обычно преследует две цели: тональная коррекция изображения (авто-подстрока яркости для оптимального диапазона освещения) и симуляции мягкого света и «разливания» света от сильных источников. Для разливающегося света особая точность не нужна, так как зачастую все это делается имперически и чисто для удовлетворения художественных потребностей дизайнеров. Так или иначе, использование сравнительно небольшого диапазона интенсивности, продиктованное использованием художественного оформления игр текущего поколения, позволяют достаточно успешно использовать для обработки сцены 16-битовые целочисленные форматы, которые поддерживают фильтрацию на всех Radeon'ах, начиная с 9500. Сразу возникает вопрос: «А достаточно ли 16-битов?» Для скептиков приведу сравнение: динамический диапазон 16-битового целочисленного формата равен 65535, в то время как динамический диапазон человеческого глаза после адаптации к среде составляет порядка 30000. Динамический диапазон камеры, или дисплея намного меньше. Для тех редких случаев, когда динамического диапазона целочисленного формата недостаточно, FP16 фильтрация может быть сэмулирована в шейдере, но это, скорее, исключение из правил.
Мы начали экспериментировать с HDR еще во время выхода Radeon 9700, и за это время накопили много опыта и провели много исследований в области представления HDR данных. Всем интересующимся я советую прочитать статью из последней версии ATI SDK (доступной на нашем сайте под названием «HDR Texturing»). Там рассмотрены интересные методы компрессии HDR текстур и варианты представления данных с очень большим динамическим диапазоном в 16-битовых целочисленных текстурах. Все перечисленные методы успешно работают на широком диапазоне DirectX 9 карточек от ATI и зачастую имеют качество сравнимое с FP16, а иногда и лучше. Кстати, во всех демках от ATI, включая «HDR Rendering With Natural Light», используются исключительно целочисленные форматы. А в последней демке для Radeon X1800 под названием «Toy Shop» вообще используются 10-битовые форматы для HDR. Отсутствие FP16 фильтрации ни в коей мере не сказывается на нашем продвижение HDR. Наоборот, наш большой опыт в этой области поможет разработчикам в их реализации HDR решений, так как наши подходы к имплементации более практичны и нацелены не только на самые последние видеокарты от ATI. Это позволяет разработчикам рассчитывать на поддержку большого парка видеокарт и более быстро и эффективно реализовать HDR технологию. Что касается фильтрации FP16 в будущих решениях, то я не могу прокомментировать функциональность не анонсированных продуктов.
iXBT.com: Чем двунаправленный кольцевой контролер памяти лучше классической топологии кроссбара (звезда), применяемой в других продуктах ATI и NVIDIA? Будет ли схожая архитектура контроллера задействоваться и дальше, в будущих продуктах? Какова степень программируемости этого контроллера, и правда ли, что его гибкость позволяет получать заметные приросты при настройке под конкретные приложения и игры? Насколько сложен такой контроллер с точки зрения числа транзисторов и занимаемого на кристалле места?
Новый контроллер памяти спроектирован с заделом на будущее и может быть легко адоптирован для широкого ряда будущих проектов. Кольцевая топология шины памяти, разведенная по периферии кристалла, позволяет существенно упростить разводку шин внутри чипа, достичь очень высоких частот памяти для текущих решений и гарантировать запас прироста на будущее.
Новый контроллер памяти имеет более гибко программируемую архитектуру, чем все наши предыдущие чипы. Программно-управляемый арбитраж памяти позволяет нам подстраиваться под требования различных приложений, заметно повышая эффективность работы с ними. Это особенно важно для современных приложений, использующих программируемые конвейеры, где требования к полосе пропускания памяти на разных стадиях конвейера могут существенно варьироваться в зависимости от типа выполняемой задачи.
Программируемый контроллер имеет несколько большую сложность, чем более простой контроллер с фиксированной функциональностью, но дополнительное место, занимаемое на кристалле, вполне оправдано и служит общему повышению производительности чипа.
iXBT.com: Есть ли какие-либо новшества и преимущества в плане кэширования данных в новом семействе — новые алгоритмы работы кэшей, их ассоциативность, или размер значительно возросли, или нет? Что еще интересного было сделано в области кэширования и сжатия данных?
Многие кэши (кэши текстур, буфера кадра и т.д.) в новых решениях Х1000 серии стали полностью ассоциативными, что повысило их эффективность. Ранее использовались кэши прямого отображения (direct-mapped cache), или кэши с ограниченной ассоциативностью. Это решение значительно уменьшило промахи кэшей и повысило производительность в пиковых ситуациях на 25%.
В области сжатия данных тоже появились улучшения. Технология 3Dc была расширена новым форматом текстур, и у формата компрессии карт нормалей появился младший братик — ATI1N. Этот формат позволяет сжимать одноканальные текстуры как на пример карты высот, монохроматические карты теней, или света и т.д. Вместе с увеличением видеопамяти, новые форматы позволяют разработчикам создавать виртуальные миры невиданной детализации.
iXBT.com: Почему, реализовав столь эффективную архитектуру с динамическим планированием загрузки исполнительных модулей и отдельно расположенными текстурными блоками, ATI не пошла до логического конца и не сделала в R520 унифицированные шейдерные процессоры, которые мы уже видели в Xenos? Ведь это не потребовало бы существенных изменений — динамическое исполнение хорошо приспособлено к такой архитектуре. Это решило бы вопрос с эффективным доступом к текстурам из вершинных шейдеров и с динамической балансировкой загрузки вершинной и пиксельной части. Когда мы увидим унифицированные шейдерные процессоры на PC — в R6XX? Будет ли следующее поколение WGF 2 решением?
Не все так просто. Высокоэффективные планировщики исполнительных потоков являются только малой частью изменений, необходимых для имплементации архитектуры с унифицированными шейдерными процессорами. Учитывая жесткие графики разработки чипов, в этом поколении графических процессоров было наиболее рационально воспользоваться стандартной архитектурой с разделенными шейдерными конвейерами. Но это не значит, что в будущем не будет перехода на унифицированные шейдерные процессоры. На мой взгляд, такая архитектура очень перспективна.
Мы тесно сотрудничаем с Microsoft над разработкой следующего поколения DirectX API и проектируем «железо» поддерживающее его. К сожалению, я не могу прокомментировать сроки, архитектуру и любые другие детали наших будущих решений.
iXBT.com: Способны ли текущие вершинные процессоры R520 исполнять переходы, и насколько эффективно это происходит (сравнимо с пиксельными, или менее эффективно)?
Да, вершинные процессоры в Radeon X1000 серии чипов поддерживают условные переходы, однако их эффективность не так велика как в пиксельных процессорах. На это есть хорошая причина. Как я уже Вам рассказал, всегда приходится выбирать, на что акцентировать больше внимания во время разработки. На наш взгляд, эффективное ветвление в пиксельных шейдерах намного более важно, чем в вершинных шейдерах. По мере развития графических технологий все больше и больше вычислений перекочевало из вершинных конвейеров в пиксельные. Некоторое время тому назад вершинные шейдеры достигли своего рода «функционального плато»: в основном они отвечают только за анимацию и подготовку различного рода параметров для пиксельных шейдеров (тангенциальное пространство, различные вектора направлений света, обозревателя и т.д.). Вряд ли можно найти игру, где вершинные шейдера будут узким местом; и в большинстве случаев даже без особых архитектурных ухищрений их эффективности и функциональности больше, чем достаточно. Что касается условных переходов в вершинных шейдерах, то, с точки зрения разработчика, наиболее интересно статическое ветвление, позволяющее упростить менеджмент шейдеров в программе.
В современных приложениях вся «красота» рассчитывается в пиксельных шейдерах, которые буквально за несколько лет выросли от дюжины до многих сотен инструкций, и индустрия на этом не останавливается. Эффективные условные динамические переходы в пиксельных шейдерах позволяют существенно оптимизировать многие «узкие места», а также реализовать интересные графические алгоритмы, о которых даже мечтать не приходилось.
iXBT.com: Какие соображения привели к столь странному балансу текстурных блоков и шейдерных процессоров в RV530? Неужели для современных приложений достаточно соотношения 3:1? Ведь каждый пиксельный процессор может выполнять в среднем 1.5-2 операции за такт, а многие шейдеры достаточно часто обращаются к текстурам! Планировалось ли такое соотношение изначально? Была ли подтверждена его эффективность какими-либо тестами?
Это очень интересный вопрос. Еще совсем недавно мы советовали разработчикам использовать соотношение текстурных и арифметических операций в пределах от 1:1 до 1:2 и использовать текстуры как таблицы преобразования значений вместо вычислений в шейдерах. Но в графической индустрии мало, что долго остается на месте и подходит время, когда приходится пересматривать подходы и подстраиваться под требования разработчиков. Во время DirectX 8 и раннего DirectX 9 реальное соотношение операций в пиксельных шейдерах составляло от 1:1.5 до 1:2.5. После всех оптимизаций и с учетом фильтрации достигалось близкое к оптимальному балансирование различных блоков пиксельного конвейера. Если посмотреть на высокотехнологичные игры, вышедшие в прошлом году (Half Life 2, Far Cry) и этом году (Age of Empires 3, FEAR и Splinter Cell), то можно увидеть соотношение текстурных и арифметических операций уже в пределах от 1:3.5 до 1:5. Экстраполируя и дальше, на следующий год или два, можно ожидать еще большего соотношения. Это и не удивительно. Если посмотреть на рост производительности графических конвейеров, то можно увидеть, что он намного опережает рост скорости памяти. Приведу конкретный пример. Если посмотреть на полосу пропускания памяти видеокарт, то она выросла примерно в 16 раз с 1998 по 2004 год. В принципе не так уж мало. Но если сравнить с ростом производительности пиксельных конвейеров, которые по производительности выросли за это же время приблизительно в 84 раза, то память остается далеко позади. Приблизительно такой рост должен сохраниться, по крайней мере, еще несколько лет, и так или иначе разработчикам придется все больше и больше полагаться на арифметические операции в шейдерах, чтобы не упереться в ограничение по памяти.
Radeon X1600 — графический адаптер среднего ценового диапазона и ниже, и обычно пользователи таких карт не меняют их на самые последние решения каждые полгода. Такие карты задерживаются в компьютерах своих владельцев, по крайней мере, несколько лет, и с нашей точки зрения важно предоставить для них решение с заделом на будущее. Да, я соглашусь с тем, что решение несколько неординарное и, может быть, несколько рисковое, но как говорится, кто не рискует, тот не пьет шампанского. Мы уверены, что наши прогнозы верны, и пользователи Х1600 модели не прогадают.
iXBT.com: Почему ATI упоминали GDDR4 в списке поддерживаемых R520 форматов памяти? Это ошибка, или имелась ввиду плановая поддержка в будущем еще не готового стандарта?
На протяжении многих лет ATI тесно сотрудничает с производителями памяти над разработкой новых стандартов. Поэтому не стоит удивляться, что в некоторых чипах может быть поддержка еще только разрабатываемых стандартов. Сам факт означает, что эти чипы используются для верификации и доводки новых технологий. Как только данная технология будет доступна, мы её сможем безболезненно и быстро внедрить в реальные продукты. Гибко программируемая архитектура контроллера памяти позволяет нам поддерживать любой существующий GDDR стандарт, а также те, что в разработке.
iXBT.com: All-in-wonder на базе R520 будет поддерживать вывод звука по DMI интерфейсу?
Боюсь, что Вам придется подождать выхода этой карты, чтобы узнать все, на что она способна.
Мы внимательно следим за требованиями графических приложений и текущая архитектура достаточна гибка, чтобы её подстроить под все необходимые требования. Я обещаю, что будущие решения будут быстрее и лучше, а каким путем это будет достигнуто, я пока раскрыть не могу.
iXBT.com: Есть ли поддержка OpenGL-расширения GL_ARB_texture_non_power_of_two?
Это расширение является составной частью OpenGL 2.0 стандарта, и все карты, начиная с Radeon 9700, хотя бы частично поддерживают это расширение на аппаратном уровне. Но даже на Х1000 картах некоторые возможности этого расширения не поддерживаются в «железе» и это может привести ко временному переключению драйвера в режим программной эмуляции, так как в OpenGL вся объявленная функциональность должна поддерживаться вне зависимости от скорости исполнения. Такое переключение может негативно сказаться на скорости, но это не большая проблема. Мы сотрудничаем со многими разработчиками, и они знают, каким образом они могут выжать максимальную производительности и функциональность из наших продуктов.
iXBT.com: количество зависимых текстурных выборок? И почему для расширения ARB_fragment_program это значение такое: Max. native texture indirections 4?
Я начну сразу со второй части вопроса. Существует несколько способов написания шейдеров. Все началось с появления расширений для программирования на специальном шейдерном ассемблере с набором команд близким к реальным инструкциям воплощенным в «железе». Такой подход был оптимальным для относительно простых и коротких шейдеров, используемых на заре шейдерной эры, и позволял хорошо балансировать затраты на программирование и получаемую производительность. ARB_fragment_program является примером такого расширения. По мере роста сложности шейдеров появилась необходимость использования языков высокого уровня для упрощения разработки. В OpenGL таким языком является GLSL, который стал неотъемлемой частью 2.0 версии API. Языки высокого уровня для программирования современных шейдеров чрезвычайно перспективны и поэтому большинство наших ресурсов по разработке драйверов идет на улучшение GLSL компилятора, а не на «прикручивание» новых возможностей к уже морально устаревшим расширениям. Например, в расширении ARB_fragment_program отсутствуют многие возможности, доступные в семействе Radeon X1000 при программировании на GLSL, — ветвление, задание уровня мип-мапа для выборки текстур, информация об ориентации полигона и т.д. Ассемблерные расширения остаются для обратной совместимости, но вкладывать в них усилия, зная, что новых разработок, требующих новой функциональности, не будет, просто не рационально.
Что касается количества зависимых текстурных выборок, то в семействе Radeon X1000 ограничений по уровню зависимости нет, и можно имплементировать столько уровней зависимости, сколько получится уместить в 512 инструкций.
iXBT.com: За счет чего в демках ToyShop & ParallaxMapping(свежая версия SDK) такой большой выигрыш по сравнению с GF7800? Только ли динамических бранчинг в этом «виноват»?
Как я уже ранее говорил, эффективное динамическое ветвление в пиксельных шейдерах может в значительной степени помочь оптимизировать производительность. Кроме того, динамическое ветвление позволяет имплементировать такие интересные технологии как Parallax Occlusion Mapping. В демке Toy Shop динамическое ветвление используется для обеих целей: оптимизаций и спецэффектов. Вместе с компрессией текстур, ветвление дает нам возможность уйти далеко вперед от конкурентов по производительности. Следуя нашим советам по оптимизации и имплементации графических эффектов, разработчики могут полностью раскрыть потенциал платформы и по-настоящему показать, на что способны наши карточки.
iXBT.com: Насколько хорошо реализован блок аппаратной тесселяции на чипе для Xбокса? Можно ли получить о нем более подробную информацию? И каким образом идет эмуляцию этой функциональности на обычном компьютере?
Я советую со всеми вопросами по приставке Xbox обратиться к Microsoft.
iXBT.com: Что не получилось реализовать в чипах X1000 из первоначально намеченных планов ? И стоит ли эти фичи ожидать в ближайший год?
Мы реализовали все функциональные возможности, которые планировались на данный момент, сохраняя разумный, с нашей точки зрения, баланс между функциональностью и производительностью. Я бы не рассчитывал на какие-то радикальные изменения в архитектуре до выхода DirectX 10.
iXBT.com: Планируется ли выложить в свободный доступ аппаратно-ускоренный DS фильтр под декодинг/обработку видео?
И да, и нет. Все зависит от того, как интерпретировать «свободный доступ». У нас есть специальный SDK под названием «Cobra», который дает доступ к DirectShow фильтрам с аппаратным кодированием/декодированием. С помощью этих фильтров можно сделать транскодер, работающий быстрее, чем в реальном масштабе времени. Мы на данный момент не планируем распространять этот SDK с нашего веб-сайта для разработчиков, но мы предоставляем серьезно заинтересованным разработчикам доступ к этому SDK по мере необходимости.
iXBT.com: Планировалось декодирование H.264 в X1000. Как обстоят дела?
Аппаратное декодирование H.264 встроено в чипы семейства Radeon X1000, и мы уже давно (если мне не изменяет память в мае) продемонстрировали рабочую версию такого решения. Наши разработчики заканчивают отлаживать и оптимизировать драйвера, и в скором будущем у пользователей появится возможность воспользоваться аппаратным декодированием. Мы также ожидаем, что вскоре после появления наших драйверов с поддержкой H.264 выйдут различные мультимедийные приложения от производителей программного обеспечения, которые будут ускорены на наших картах.
iXBT.com: Планируется ли выпуск профессиональных версий X1000?
Уже на протяжении многих поколений графических карт мы вслед за игровыми картами выпускаем профессиональные решения. Я не вижу причины, почему мы это не должны сделать и в случае Radeon X1000 семейства.
iXBT.com: Планируется ли добавление шейдерной модели 3.0 в интегрированное видео?
Я думаю, что в какой-то момент мы придем к интегрированным решениям с SM 3.0 поддержкой, но я затрудняюсь сказать, когда именно это произойдет. Дело в том, что на данный момент SM 3.0 в чипсетах является скорее галочкой в списке маркетинговых излишеств. При чрезвычайно низкой производительности интегрированного видео по сравнению с отдельными видеокартами, исполнение длинных SM 3.0 шейдеров с различными наворотами просто не представляется возможным в режиме реального времени. А для сложности шейдеров, которые реально запустить на современных чипсетах, вполне хватает PS 2.0 и даже PS 1.x. Зачем тогда тратить лишние транзисторы на то, что не может быть реально задействовано? Такое решение может только повысить стоимость чипсета и в конечном итоге снизить его рентабельность и конкурентоспособность.
Мы благодарим Геннадия за любезную возможность выделения в своем плотном графике времени на столь глубокие ответы. А также хотим выразить глубокую признательность Николаю Радовскому (ATI Russia) за помощь в организации данного интервью.
