PCTuning fórum

webwalker píše: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?

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.

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)

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.

no-X píše: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/

Krteq píše: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]

beardie píše:preco ma Pro vyssiu frekvenciu ako XT?
vzdy to bolo naopak

Krteq píše:

beardie píše: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í.