AMD Radeon HD 7970 – новият властелин на графичния небосклон

януари 27th, 2012

Кеш архитектура

Промяната на архитектурата и силната наосченост към общи изчисления е довела и до още една сериозна промяна – цялостно преконфигуриране на архитектурата за работа с паметта. За първи път в модел на AMD разполагаме с пълноценна, кохерентна кеш организация на няколко нива както при съвременните процесори. На първо място, всеки от векторните блокове разполага с по 64 КБ локална регистрова памет, като скаларния АЛУ разполага с отделен 4 КБ регистров файл. Целия изчислителен блок разполага с 64 КБ софтуерно управлявана споделена памет (Local Data Share) и отделно 16 КБ L1 кеш текстури и данни, който поддържа както четене, така и запис, за разлика от предишните поколения. Достъпа до тази памет е по шина с ширина 64 байта (512 бита). След това изчислителните блокове са групирани по 4, като за всяка такава група има 16 КБ L1 инструкционен кеш (16 байта за такт), както и 32 KB кеш само за четене за скаларни данни (32 байта за такт), като и двата са с поддръжка от L2  кешовете (по същество би трябвало да работят както кеш от първо ниво) . Накрая чипът разполага и с няколко дяла L2 кеш, които вече не са обвързани с ROP дяловете, но остават свързани с контролерите на паметта. Обемът от 128 КБ на дял се запазва както в предходното поколение. Отново – това е кеш за четене и запис, като всеки дял има максимална пропускателна способност 64 байта на такт (512-битова шина). Накрая, чипа разполага със блок от софтуерно управлявана памет за глобално споделяне на данни (Global Data Share).

Докато ROP дяловете в предишното поколение бяха обвързани по 2 към един контролер и един L2 кеш блок, в новата архитектура те са отделени като всеки дял може да се свърже с всеки контролер. Това повишава сериозно ефективността на работата, тъй като в предишните случаи често пропускателната способност на един канал не е стигала да обслужи ефективно и двата дяла. Възможностите им се запазват непроменени – по 4 пиксела на такт или 16 Z/stencil отчета за блок.

Това обаче не е всичко. GCN разполага с пълноценен IOMMU (Input/Output Memmory Maping Unit) блок и може да работи съвместно в споделено общо адресно пространство с x86 процесор! На пръв поглед това може и да не ви изглежда като кой знае каква особеност, но всъщност е от изключителна важност за бъдещето. На практика нито една архитектура на AMD или NVidia до момента, включително и Fermi, не може да се похвали с такива способности. А прехвърлянето на адресните пространства между графичния и централния процесор е бавна и времеемка задача. Общото адресно пространство позволява значително да се опрости комуникацията между двата процесора, както и да споделят изпълнението на програмите. Както казах – това ще е от изключителна важност за в бъдеще, когато неизменно се очаква GCN  да бъде използвана в рамките на интегрираните процесори на AMD, като заедно с пълноценната C++ поддръжка може да позволи съвместното изпълнение на дадена програма между процесора и изчислителните блокове и потенциално – превеждането на различните процесорни векторни инструкции за изпълнение върху векторните SIMD блокове на графичното ядро.

Заедно с това GCN добавя и поддръжка на ECC като възможност, което макар да не е от особена полза за графичните изчисления, може да се окаже сериозен коз при изчислителните ускорители FireStream. ECC поддръжката покрива както вътрешните регистри и кешове, така и локалната памет на адаптера, като в последния случай ще се наложи да се жертва част от паметта за съхранване на ECC кодовете, подобно на реализацията на тази функционалност при Fermi.

И накрая нещо в добавка за графичните възможности на чипа. Става дума за новата технология Partially Residential Textures. В известен смисъл това е хардуерна реализация на технологията Megatexture на id Software. PRТ позволява на чипа да поддържа текстури с размер до 32 ТБ, като се разбиват на блокове от 64 КБ и в локалната памет се зареждат само нужните за текущия кадър блокове. Всичко това обаче се управлява изцяло хардуерно. Лошото с PRT е, че тази функционалност не се поддържа нито от DX11/11.1, нито от текущите версии на ОpenGL, така че е малко съмнително доколко ще е полезна на този етап, но пък може да се окаже полезна за бъдещите реализации на архитектурата.

Страници: Предишна 1 2 3 4 5 6 7 8 9 10 Следваща