Зміст вступ
першоквітневий матеріал
Сподіваємося, ви вдосталь повеселилися над нашим жартівливим оглядом граненого склянки . А тепер серйозно.
Теорія говорить, що конкуренція - благо для споживача, механізм, який змушує виробників підвищувати якість і знижувати вартість своєї продукції. На практиці, як відомо, не існує такого злочину, на який не піде капіталіст заради хоча б ста відсотків прибутку. І жертвою цього злочину найчастіше виявляється сам споживач, який не здатний розібратися у всіх тонкощах роботи товару, який він купує.
Не є винятком з правила і відеокарти. З десятка з зайвим компаній, присутніх на ринку п'ятнадцять років тому, залишилися лише одиниці, а розробників високопродуктивних рішень тільки два. І боротьба за гаманець споживача між NVIDIA і AMD (в дівоцтві ATI) триває всі ці роки. У хід йдуть як об'єктивні технічні переваги і досягнення, так і маркетинг. Для того щоб оцінити продуктивність відеокарти, існує безліч інструментів, але не завжди кількість означає якість.
На початку минулого десятиліття, в самий розпал боротьби між ATI і NVIDIA, співтовариство ентузіастів було здивоване, що розкрилися масштабами махінацій з якістю картинки на догоду продуктивності в обох вендорів. Стало ясно, що це не випадкові помилки і прорахунки виробників, а заздалегідь сплановані зміни в апаратне і програмне забезпечення, здатні забезпечити приріст продуктивності на шкоду якості побудованого зображення.
Перш, ніж перейти до порівняння якості рендеринга сучасних відеокарт, згадаємо, з чого починалася нечесна боротьба за швидкість, які механізми використовували виробники, ніж всі в підсумку закінчилося, і закінчилося? Ми вирішили не давати молодому поколінню фанатів нових аргументів для своїх священних воєн, тому не будемо згадувати, хто з розробників використовував ту чи іншу технологію. А старе покоління і так все пам'ятає, тому хіба що посміхнеться, або змахне ностальгічну сльозу. Приступимо.
способи оптимізацій
Фільтрація текстур, підміна рівнів текстур
Вважається, що початок махінацій з якістю картинки було покладено на зорі DirectX 8 відеокарт, з виходом GeForce3 і Radeon 8500. В той час, основна маса додатків використовувала DirectX 7, який недалеко пішов за своїми можливостями від простого 3D прискорення. Робота графічного процесора, переважно, зводилася до вибірці текстур і закраске сцени. Швидкість виконання даних операцій дуже швидко росла, подвоюючи практично кожне покоління, так що вже з виходом GeForce 2 GTS і Radeon 7500 виробники зіткнулися з надлишковою продуктивністю в ряді завдань і вирішили зробити акцент на якість картинки.
Нові відеокарти і додатки почали активно використовувати замість білінійної фільтрації текстур анізотропну, яка значно покращувала якість картинки на далеких планах сцени. Трилинейная фільтрація дозволяла згладжувати переходи між рівнями текстур. Природно, ці механізми почали використовувати і в тестах продуктивності відеокарт, оскільки дані алгоритми були ресурсоємними і давали істотне зниження продуктивності. В умовах невисокої продуктивності центральних процесорів, часто нездатних прогодувати графічні, це був хороший спосіб розміняти теоретичну продуктивність на практичне поліпшення якості картинки.
Але дуже швидко розкрився ряд нюансів. Зокрема, відеокарти одного виробника демонстрували помітну перевагу над конкурентом в ресурсномістких режимах з використанням анізотропної фільтрації. Але все дуже швидко стало на свої місця. Лідерство в швидкості було наслідком агресивних оптимізацій алгоритму згладжування, який працював тільки на поверхнях під кутами 0 та 90 градусів, а на похилих поверхнях, наприклад 45 градусів, не працював зовсім. Крім того, при використанні анізотропної фільтрації, відключалася трилинейная, і переходи між рівнями текстур ставали помітні.
Але на цьому гри з текстурами не закінчилися, в справу пішли маніпуляції рівнями текстур. У кожної текстури в грі є кілька рівнів, призначених для зафарбовування сцени на різній відстані від спостерігача. Максимальна якість і деталізація під ногами персонажа, мінімальне - далеко.
Таким чином, трохи спрощується робота графічного процесора по отрисовке далеких планів і економиться місце в відеопам'яті. Драйвер відеокарти підміняв рівні текстур на більш високі, тобто замість нульового, найякіснішого, використовувався перший, замість першого - другий, і т.д. Якість картинки практично не страждало, а ось продуктивність виростала на десяток відсотків, а то і більше, що в умовах жорсткої конкурентної боротьби нерідко ставало аргументом для споживача.
Але рано чи пізно, таємне завжди стає зрозумілим. Ентузіасти вивели виробників на чисту воду, замовчувати і приховувати проблеми стало безглуздо. Виробники, в свою чергу, знайшли спосіб вийти з положення з вигодою для себе. Вони дозволили користувачам самим вибирати між якістю, швидкістю, або компромісним режимом відтворення сцени, додавши відповідні органи управління в панель налаштувань драйвера. Зрештою, якість картинки страждало незначно, а зайвий десяток відсотків продуктивності міг виявитися зовсім не зайвим.
Даний механізм управління якістю зберігся до сих пір в панелі управління драйвера, хоча і неабияк еволюціонував, розширивши сфери застосування, оскільки ATI і NVIDIA знаходили все нові і нові способи підвищувати продуктивність на шкоду якості.
Маніпуляції з шейдерами
Додавши в панель управління драйвером механізм, що дозволяє управляти оптимізаціями якості текстур, виробники вирішили лише частина проблем, адже крім програмних маніпуляцій були і апаратні, зокрема вищезгаданий алгоритм анізотропної фільтрації тільки горизонтальних і вертикальних текстур. Виправити ситуацію можна було тільки випустивши нові GPU, що не було в ті часи великою проблемою, лінійки відеокарт оновлювалися кожні півроку. Технології не стояли на місці і можливості програмування заліза росли. На зміну DirectX 8 прийшла його оновлена версія, DirectX 8.1, який приніс підтримку піксельних шейдеров версії 1.4.
Зрозуміло, обидва виробники наввипередки почали розповідати про те, що їх графічні процесори підтримують даний API в повній мірі, але один з них злукавив. Можливості підтримувалися в повному обсязі, частина функціоналу не було реалізовано в залозі, але виробник бадьоро рапортував про успіхи освоєння нової версії API від Microsoft. На жаль, перші ж додатки з підтримкою PS 1.4 розкрили неспроможність цих заяв, і для досягнення необхідної якості сцени доводилося використовувати піксельні шейдери версії 1.3 в кілька проходів, що фатально позначалося на продуктивності. Але сумувати з цього приводу довго не стали, наступала епоха DirectX 9, епоха, коли напруження боротьби за швидкість і гаманці споживачів досяг свого піку.
З виходом легендарних Radeon 9700 Pro і GeForce FX 5800 Ultra різниця в підходах до реалізації можливостей нового API стала видна неозброєним оком. Один з виробників пропонував швидкий, але не дуже гнучкий в плані програмування графічний процесор. Другий виробник заклав в свій продукт вражаючі можливості програмування, значно перевищують вимоги Microsoft, але розплачуватися за це довелося швидкістю роботи в DirectX 9 додатках. Відставання від конкурента було настільки значним, що компанія не могла на це закрити очі.
Незабаром з помпою був випущений драйвер, радикально підвищує продуктивність нових відеокарт в основних додатках, які використовувалися для оцінки продуктивності, зокрема, 3D Mark. Науково пояснити такі прирости було неможливо, а в магію ентузіасти не вірили, так що довелося в черговий раз розбиратися з нововведеннями ефективних менеджерів і програмістів. З'ясувалося, що драйвер відеокарти визначав додаток і підміняв код шейдера на більш простий, що дає схожу, але не тотожну картинку. Знешкодити дану оптимізацію можна було простим перейменуванням виконуваного файлу з, наприклад, 3dmark.exe в 3dmrak.exe. Драйвер не впізнавав програму без підміняв код шейдера, і швидкість опускалася до старих, вже звичних значень.
Втім, згодом виробник знову зумів витягти для себе вигоду і підняти продуктивність, на цей раз чесно. Драйвер навчився оптимізувати код шейдеров для виконання без втрати якості, тобто змінювати і переставляти інструкції оптимальним, для виконання на своєму графічному процесорі, чином, але без будь-яких відмінностей в якості сцени.
Подальший розвиток змінило виробників місцями. Потужна, але негнучка графічна архітектура однієї фірми виявилася нездатна зігнутися під вимоги DirectX 9c і піксельні і вершинні шейдери версії 3.0. Другому виробнику виявилося простіше наростити м'язи своїм графічним процесорам в новій лінійці, а за можливостями програмування довелося внести дуже незначні зміни, завдяки закладеному в минулу лінійку фундаменту. Це було пекло, як для користувачів, так і для програмістів. Фактично співіснувало кілька лінійок адаптерів з різними можливостями, DirectX 9, 9a, 9b і 9с. Тобто при написанні гри, необхідно було враховувати всі ці відмінності між родинами і використовувати ті функції, які вміло кожне конкретне сімейство.
Але нюансів було багато, а люди були схильні помилятися, так що все це різноманіття породило безліч помилок і артефактів в іграх, які виправлялися все новими і новими патчами. Порівнювати між собою різні сімейства відеокарт по продуктивності стало практично неможливо. Через відмінності в залозі, ігрові движки давали різні картинки на різних підверсії API, а спроби вручну виставити ідентичні налаштування якості часто приводили до появи артефактів. Не обійшлося і без заяв виробників про підтримку тих API, які графічні процесори підтримували лише частково, але це вже пройдений етап.
Варто згадати і про точність обчислень. Виробники часто декларували вищі точності, ніж вміло їх залізо. Наприклад, замість заявлених 24-бітних обчислень, були тільки 16-бітові. Замість 32-бітних, 24-бітна, а то і ті ж 16 біт. Це додало безліч безсонних ночей і сивого волосся програмістам, які чесно намагалися розібратися, чому на виході виходить зовсім не те, що повинно. А користувачі отримували нові веселі артефакти в іграх.
На щастя, Microsoft і вендори зробили для себе висновки, і з приходом DirectX 10 вимоги до «заліза» стали жорсткіше, а можливості практично зрівняли. Нове «залізо» було значно більш гнучким в програмному плані, так що без особливих проблем могло виконувати код всіх подверсий DirectX 9.
алгоритми згладжування
Здавалося б, з виходом DirectX 10 мало настати довгоочікуване щастя, і воно настало, але не для всіх. Відкрите вийшли задовго до операційної системи та ігор з підтримкою нового API. Вони мали величезну математичної продуктивністю, яку нікуди було дівати. Так що боротьба знову перемістилася на поле якості зображення. До вже відомих алгоритмів суперсемплінгового і мультісемплінгового додалися методи крайового згладжування і згладжуючи напівпрозорих текстур. Це дозволило значно підвищити якість картинки ціною несуттєвого падіння підсумкової продуктивності. Користувачі були щасливі, а нещасними у всій цій історії в черговий раз виявилися тестери відеокарт.
Адже алгоритми згладжування в панелі управління множилися як кролики в хороший рік, і не завжди було зрозуміло, чим метод згладжування 4xQ відрізнявся від 6x, які алгоритми були більш якісними і як вони комбінували в різних настройках. З'ясувалося також і те, що один з виробників обійшов конкурента на поле якості і мав більш розвиненими алгоритмами згладжування. Але тут постала інша проблема, як порівнювати між собою відеокарти різних виробників при настройках високої якості. Виставляти максимальну якість? Некоректно, адже більш якісна картинка вимагала більше потужності, що позначалося на продуктивності. Призводити до спільного знаменника? Теж некоректно, адже в такому разі не використовувалися нові прогресивні алгоритми, на які виробник витратив транзисторний бюджет GPU.
Але ці питання пройшли повз більшості користувачів, мало хто вдавалися в такі подробиці, та й того напруженої боротьби, що кілька років тому, вже не було.
фіктивні кадри
Окремої згадки заслуговують і відносно недавні дослідження методу підрахунку кадрів. Один з виробників заявив, що випустив спеціальний набір для тестування продуктивності відеокарт, який здатний чесно рахувати кількість отрісованих кадрів. Особливості та звивистість шляху кадру від ігрового движка до зображення на моніторі дозволяли некоректно підраховувати кількість кадрів в секунду, відрендерене відкритий. Адже кадром могло вважатися лише кілька рядків, замість цілої картинки. Виробник, таким чином, підкреслював, що його рішення дають не тільки чесніші показники швидкості, але і більш плавний відеоряд. Згодом, другий виробник випустив оновлення драйверів, в якому підвищив плавність виведеного відеоряду, але це далося очікуваним падінням продуктивності. Так чи інакше, в цей раз у виграші опинилися, нарешті, все.
Які можна зробити висновки з написаного вище? Обидва виробники неодноразово використовували різні хитрощі, щоб підвищити привабливість своїх продуктів. І ця боротьба триває вже більше десяти років. Дивно думати, що ентузіасти здатні виявити всі механізми обману споживача, адже справа давно поставлено на потік і лише вдосконалюється з плином часу. Значна частина оптимізацій вже давно легалізована і може бути налаштована в панелі управління драйвера. Апаратних оптимізацій вже не залишилося, все налаштовується програмно. Кожен сам може вибрати, що для нього важливіше, шашечки, чи їхати.
Але вибір цей непростий. Чи варто пожертвувати продуктивністю заради якості картинки? Наскільки важлива якість картинки і положення окремих пікселів для ігрового процесу? Чи готові користувачі миритися з тим, що виробники будуть мовчки застосовувати агресивні оптимізації, незначно, але все ж змінюють картинку? Нехай з цим розбираються диванні теоретики і філософи, а ми приступимо до тестування сучасних відеокарт з метою виявлення відмінностей в якості зображення.
Виставляти максимальну якість?Призводити до спільного знаменника?
Які можна зробити висновки з написаного вище?
Чи варто пожертвувати продуктивністю заради якості картинки?
Наскільки важлива якість картинки і положення окремих пікселів для ігрового процесу?
Чи готові користувачі миритися з тим, що виробники будуть мовчки застосовувати агресивні оптимізації, незначно, але все ж змінюють картинку?
