DIRECTX 11: багатопотоковий рендеринг

| Нет комментариев

DirectX-11.jpg

Повертаючись до нашої розмови про новий в DIRECTX 11, який, як багато хто з вас відмітив, вже присутній в збірці Windows 7 build 6956, варто відзначити, що Microsoft спростувала заяву Бена Базаріка (Ben Basaric), продукт-менеджера Windows, який не так давно сказав, що Microsoft не встигає завершити роботу над DIRECTX 11 до релизу Windows 7. Ну а сьогодні ми поговоримо про ще одну ключову особливість нового API - багатопотокового рендеринга.

Хоча багатопотоковий рендеринг складно назвати новою частиною графічного конвеєра, це неймовірно важлива особливість DIRECTX 11. Вона стає ще важливішою, якщо ви поглянете на її потенціал з розрахунком на портирование цих удосконалень на апаратні засоби класу DIRECTX 10 за допомогою оновлення драйверів.

Сьогодні на ринку переважають двуядерные CPU, хоча чотириядерні моделі стають усе більш доступними для геймеров і ентузіастів, тому в найближчому майбутньому чотириядерні процесори замінять своїх двуядерных побратимів, ставши в області процесорів стандартом де-факто. Враховуючи цей факт, виникає резонне питання, чому DIRECTX до цих пір не підтримує багатопотоковий рендеринг. Справедливості ради варто відзначити, що і AMD, і Nvidia вже працювали над багатопотоковими драйверами, проте успіх цих починів був обмежений тим, що API кінець кінцем зводив все до одного потоку.

Ми поговорили на цю тему з багато розробниками - деякі з них придумували способи використання додаткових ядер, тоді як інші щодуху намагалися витягувати більше продуктивності і часто залишали простоювати ці додаткові ядра. Сьогодні такі проблем стає все менше, оскільки розробники стали думати з приводу розпаралелювання потоків, але все ще є такі сценарії, коли додаток сильно обмежується можливостями CPU.

На щастя, з приходом DIRECTX 11 ситуація повинна корінним чином зміниться, і Microsoft зробить можливим здобуття вигоди від використання цих функцій на апаратному забезпеченні DIRECTX 10. Команди розробників відповідних драйверів в AMD і Nvidia повинні будуть виконати певний комплекс робіт, аби здійснити підтримку цих функцій в своїх драйверах, але як тільки вони це зроблять для DX11, їм не складе великих труднощів перенести цю підтримку і в DX10.

Microsoft удалося досягти цього шляхом розбиття пристрою Direct3D на три окремі інтерфейси: Device, Immediate Context (прямий контекст) і Deferred Context (відкладений контекст). Кожен з них призначається на потік, тому завдяки інтерфейсам Device і Deferred Context на завдання, що стоять в черзі Immediate Context або потоку обробки, може бути призначений більше одного потоку.

Рекламная пауза: В краснодар после протезирования в германии.

Перемикання між потоками легко контролювати, так що розробник повинен буде сам вирішувати, як і в якому порядку операції поміщатимуться в чергу для інтерфейсу Immediate Context. Кожен інтерфейс Device може завантажувати потокові ресурси як і коли завгодно в той час, як інтерфейс Deferred Context служить як контекст пристроїв, що працює з потоками, для майбутніх операцій рендеринга - він організовує чергу із запитів промальовування (або списків команд Display List) перш, ніж передати їх інтерфейсу Immediate Context, коли він буде готовий.

Для графічних карт покоління DIRECTX 10 інтерфейс Deferred Context повинен реалізуватися на програмному, а не апаратному, рівні, оскільки в новому апаратному забезпеченні будуть зроблені відповідні оптимізації для багатопотокового рендеринга. Через це інтерфейси Deferred Context не зможуть самостійно розподілятися по потоках на апаратному забезпеченні DX10 і це доведеться робити на рівні API.

Комментировать

Об этой записи

Сообщение опубликовано October 6, 2008 10:29 PM. Автор — софт.

Следующая запись — Microsoft підтвердила, що MinWin присутній у Windows 7

Смотрите новые записи на главной странице или загляните в архив, где есть ссылки на все сообщения.