Це насправді купа взаємозалежних питань:
Чи стислі текстури (dxt5 / dxt1 і т. Д.) Завжди повністю стискаються під час проходження конвеєра?
Якщо відповідь на перше питання правдива, то як керується пам'яттю для кількох великих нестиснених текстур?
Чи відрізняється фреймбуфер від VRAM в сучасному графічному процесорі?
Відповіді:
Формати текстур, стиснених для графічного процесора, такі як DXT / BC / ETC , спеціально розроблені для зчитування безпосередньо із стислої форми. Їх не потрібно розпаковувати в сирий буфер RGBA.
Як це працює, кожен блок текселів (часто 4х4) займає певну кількість бітів - тому ми точно знаємо, наскільки далеко в буфері шукати конкретний тексель - і ці блоки можна розпаковувати, не читаючи всіх оточуючих / попередня інформація про текстуру. Графічні процесори містять спеціалізоване обладнання, яке розкладає лише запитувані текстові блоки, як це потрібно для виконання запитів на вибірку текстур з ваших шейдерів.
Це на відміну від форматів, таких як jpg & png, де кількість місця, яке займає кожен тексель, може змінюватись в залежності від зображення (детальні області, які займають більше даних, передбачувані області, що займають менше), тому, щоб знайти конкретний тексель, ви повинні знімати його ціле зображення або принаймні великі / розподілені шматки його. Але оскільки вони можуть вибірково стискати передбачувані ділянки текстури, вони, як правило, стискають зображення менших розмірів для зберігання на диску або для передачі по мережі, ніж те, що ми отримуємо із зручних для GPU форматів. Різні стратегії для різних цілей використання.
Як правило, задавати кілька запитань слід через декілька дописів, але оскільки це досить коротка відповідь, я також потрапив у пункт 3:
" Framebuffer " - це лише певний біт відеопам'яті, який ми вирішили використати для зберігання складеного зображення, яке ми хочемо представити на екрані. Зверніть увагу на деталі у відповіді JarkkoL, де на деякому спеціалізованому обладнання ми можемо вибрати цей буфер у певній частині нашої доступної відеопам'яті, оптимізованої для потреб пропускної здатності в цілях візуалізації.
Відповіді на ваші запитання дійсно залежать від платформи. Як правило, формати BC зберігаються в стислій формі в пам'яті, а декомпресія проводиться в польоті за допомогою текстурних одиниць GPU, але є винятки. А саме Xbox 360, як відомо, декомпресує цілі блоки BC 4х4 пікселя, щоб кешувати, перш ніж TU отримує дані, таким чином збільшуючи використання кешу. Я не знаю жодної платформи, яка б декомпресувала всю текстуру, щоб vram при завантаженні, але я дуже сумніваюся в цьому через додану пам'ять і використання пропускної здатності.
Те ж саме стосується і фреймбуферів - це залежить від платформи. На Xbox 360 у вас було 10 Мб виділеної EDRAM високої пропускної здатності, яку вам довелося використовувати для відображення цілей. У Xbox One у вас все ще є 32 Мб спеціальної ESRAM, яка є кращою для цілей візуалізації через високу пропускну здатність (і її також можна отримати на відміну від Xbox 360), але цілі візуалізації також можуть знаходитись у звичайній пам'яті DDR3.