ATi/AMD Southern Islands (HD 7xxx) - informace, spekulace

[del42sa]

del42sa: No-Xovi sice věřím, ale pamatuješ jak se tu někde před časem řešil problém s SB, kde L3+ringbus při grafických operacích zjevně nestíhal?

to si nějak nevybavuju, můžeš mi to to připomenout ?

[webwalker]

del42sa: Ono toho bylo o tomhle problému SB po internetu více, ale tady je třeba:
http://pctforum.tyden.cz/viewtopic.php? ... &start=220

[del42sa]

díky, kouknul jsem na to a našel jsem pouze toto vysvětlení :

L3 memory cache is now called LLC (Last Level Cache), it is not unified anymore, and is shared by the CPU cores and the graphics engine

Also, each last level cache isn’t tied to a particular CPU core. Any core can use any of the caches. For example, in Figure 5, we have a quad-core CPU with four last level caches. Core 1 isn’t linked to cache 1; it can use any of the caches. This also means that any CPU core can access data that is stored in any of the caches.

jedno vysvětlení je, že se jádra CPU bijí o LLC (L3cache) v přístupu.

Another important innovation is that the graphics engine can use the Last Level Cache (LLC, formerly known as L3 memory cache) to store data, especially textures. This improves 3D performance, as the graphics engine doesn’t need to go to the RAM to fetch for data, it can load data directly from the cache (if it is already there, of course)

v podstatě tentýž problém jako nahoře, buď jsou v paměti textury nebo jiná data a dochází ke konfliktu CPU/GPU.

The graphics integration in Sandy Bridge is particularly novel as Intel is sharing the LLC with the GPU. The driver allocates regions of the cache at way granularity (128KB) – and can actually request the whole cache. Each thread can spill 32KB of data back to the LLC, for a total of nearly 2MB in the larger 12 shader core variants. Almost any GPU data can be held in the LLC, including vertices, textures and many other types of state.

The Sandy Bridge LLC and ring interconnect can rapidly pass data from the GPU back to the CPU – AMD’s Fusion is a far higher performance GPU, but that particular style of communication is discouraged. Since the GPU has a weaker ordering model, a flush command is needed to force data to be written back to the LLC prior to the CPU reading it. The driver can also allocate a portion of the LLC as a non-coherent cache for display data and other uses. For example, the results of transcoding might be written out to the the non-coherent region.

While this excellent system integration promises many benefits, at present it is restricted mainly to multimedia workloads. For graphics, it is largely an academic advantage to any but Intel’s driver team. The GPU is exposed through graphics APIs; yet neither OpenGL nor DirectX programs can interact with coherent memory and bypass I/O copies (let alone use the LLC). AMD has introduced an OpenCL extension for a zero copy mechanism on Windows systems already, and presumably Intel will follow once they have OpenCL and DirectCompute capable hardware. Intel’s graphics driver can take advantage of fast CPU/GPU communication, but that is only because it has raw access to the GPU hardware. These advances pave the way for Ivy Bridge and certainly promise good things in the future, but also serve to point out some of the deficiencies in the current generation.
There is a down side to this arrangement though. The GPU is so tightly integrated into the system that it relies on the ring interconnect, LLC and memory controller for operation. But the frequency for the ring and LLC is determined by the cores, which may be running at a lower P-state than the GPU. For example, if the CPU cores are lightly loaded and the PCU switches them to a reduced voltage and frequency, then the bandwidth across the ring decreases as well – negatively impacting the performance of the GPU. This will almost certainly be fixed in Ivy Bridge by separating out the clock trees for the ring.

třetí možnost...

[webwalker]

Výkon kolem HD6990 ale vydání až v 2012
http://www.xbitlabs.com/news/graphics/d ... layed.html

[no-X]

Sice to možná bude působit trochu jako reklama, ale myslím, že o tomhle by se mělo vědět...

http://www.diit.cz/clanek/readovi-se-pr ... vih/39053/

[del42sa]

Sice to možná bude působit trochu jako reklama, ale myslím, že o tomhle by se mělo vědět...

http://www.diit.cz/clanek/readovi-se-pr ... vih/39053/

myslím že o tomhle by se mělo vedět také: http://semiaccurate.com/2011/11/03/amd- ... ment-11876

[ArgCZ]

http://www.diit.cz/clanek/radeony-hd-70 ... ani/39097/

[semmtex]

na tom diit.cz je nak moc informací nicméně zajmavých-uvidíme jak jsou pravdivé...

[DOC_ZENITH]

Protože tam dělá články No-X, což je člověk s asi největšim rozhledem a znalostma co se GPU týče, alespoň z těch co znám tady v čechách.

[Krteq]

Vyděleno OT + Unlock

Představení řady HD 7000 už 5. prosince v Londýně? -> NordicHardware - Radeon HD 7000 presenteras i London 5 december [Extra]

[del42sa]

Vyděleno OT + Unlock

Představení řady HD 7000 už 5. prosince v Londýně? -> NordicHardware - Radeon HD 7000 presenteras i London 5 december [Extra]

http://www.fudzilla.com/processors/item ... ses-gddr-5

Radeon HD 7000 uses GDDR 5 ,No XDR2 memory

[Krteq]

NordicHardware uveřejnil možné specifikace řady HD 7900 (Tahiti, New Zealand)



NordicHardware - Radeon HD 7000 series revealed, GCN, Tahiti, 2 048 cores at 1 GHz

[beardie]

preco ma Pro vyssiu frekvenciu ako XT?
vzdy to bolo naopak

[Riku]

to bude asi "chyba tisku"

[Krteq]

preco ma Pro vyssiu frekvenciu ako XT?
vzdy to bolo naopak

Protože Pro a XT jsou u označení čipu prohozeny. Vycházej z modelového označení.

[Riku]

preco ma Pro vyssiu frekvenciu ako XT?
vzdy to bolo naopak

Protože Pro a XT jsou u označení čipu prohozeny. Vycházej z modelového označení.

Vážně? všude jinde jsou značeny normálně... 7970 jako XT a 7950 jako PRO

[Krteq]

Však jo, ale ve té tabulce z NH jsou ty čipy u karet prohozené

[Riku]

Sorry, pochopil jsem tě špatně
nicméně jsem zvědavej zda ty specifikace budou opravdu takový

[Ache]

Hmm... Jakpak se asi soudruzi z Kalifornie vypořádají s 384bit sběrnicí vs. 64 ROPs?

[DOC_ZENITH]

Kdyby byl použit Ringbus, neni pak sběrnice vázána na ROPs. U R600 si taky mohl mít různé šířky sběrnice aniž by to ovlivňovalo chod zbytku čipu.

Nicméně já osobně v 384-bit stále nevěřím.