Xbox One Worldwide Sales At 26 Million

26 million is still pretty good for only 3 years, especially when you realize that the xboxone is only available for 2 years without a kinect.

That's not how cache coherency work. A 30 GB/s cache coherence works with up to 30 GB/s and it's NOT static 30 GB/s memory bandwidth consumption allocation.

If CPU writes 1 GB of data to main memory (trigging memory data change event) with cache coherence requirement, only 1 GB of data is required to be updated. 1 GB write is only ~0.03 percent of 30 GB/s cache coherence capability. This is why CPU and GPU main memory bandwidth usage dynamically changes depending on workloads.

Lowest common denominator for any CPU workload is PS4 and XBO would be following it's limits i.e. 30 GB/s cache coherence is nearly pointless with multiplatform games when PS4's CPU cache coherence capability is lower.

GPU read from main memory doesn't trigger cache coherence update.

CPU read from main memory doesn't trigger cache coherence update.

Modern CPU cache was designed to minimise main memory access until other DMA cache coherency client end points (e.g. other CPU, GPU, DSP, micro-controllers) needs the updated data i.e. snoop request from DMA cache coherency client end points (Note 1).

Read https://en.wikipedia.org/wiki/Cache_(computing)#Writing_policies for basics on cache writes.

When a system writes data to cache, it must at some point write that data to the backing store as well. The timing of this write is controlled by what is known as the write policy.

There are two basic writing approaches:

• Write-through: write is done synchronously both to the cache and to the backing store.
• Write-back(also called write-behind): initially, writing is done only to the cache. The write to the backing store is postponed until the cache blocks containing the data are about to be modified/replaced by new content.

A write-back cache is more complex to implement, since it needs to track which of its locations have been written over, and mark them as dirty for later writing to the backing store. The data in these locations are written back to the backing store only when they are evicted from the cache, an effect referred to as a lazy write. For this reason, a read miss in a write-back cache (which requires a block to be replaced by another) will often require two memory accesses to service: one to write the replaced data from the cache back to the store, and then one to retrieve the needed data.

From http://www.realworldtech.com/jaguar/6/

AMD Jaguar's L2 cache has write back policy.

For AMD64 CPU cache protocol, read https://en.wikipedia.org/wiki/MOESI_protocol

As discussed in AMD64 Architecture Programmer's Manual Vol 2 'System Programming',^[1] each cache line is in one of five states:

Modified

This cache has the only valid copy of the cache line, and has made changes to that copy.

Owned

This cache is one of several with a valid copy of the cache line, but has the exclusive right to make changes to it. It must broadcast those changes to all other caches sharing the line. The introduction of owned state allows dirty sharing of data, i.e., a modified cache block can be moved around various caches without updating main memory. The cache line may be changed to the Modified state after invalidating all shared copies, or changed to the Shared state by writing the modifications back to main memory. Owned cache lines must respond to a snoop request with data (Note 1).

Exclusive

This cache has the only copy of the line, but the line is clean (unmodified).

Shared

This line is one of several copies in the system. This cache does not have permission to modify the copy. Other processors in the system may hold copies of the data in the Shared state, as well. Unlike the MESI protocol, a shared cache line may be dirty with respect to memory; if it is, some cache has a copy in the Owned state, and that cache is responsible for eventually updating main memory. If no cache hold the line in the Owned state, the memory copy is up to date. The cache line may not be written, but may be changed to the Exclusive or Modified state after invalidating all shared copies. (If the cache line was Owned before, the invalidate response will indicate this, and the state will become Modified, so the obligation to eventually write the data back to memory is not forgotten.) It may also be discarded (changed to the Invalid state) at any time. Shared cache lines may not respond to a snoop request with data.

Invalid

This block is not valid; it must be fetched to satisfy any attempted access.

This protocol, a more elaborate version of the simpler MESI protocol (but not in extended MESI - see Cache coherency), avoids the need to write a dirty cache line back to main memory when another processor tries to read it. Instead, the Owned state allows a processor to supply the modified data directly to the other processor. This is beneficial when the communication latency and bandwidth between two CPUs is significantly better than to main memory. An example would be multi-core CPUs with per-core L2 caches.

While MOESI can quickly share dirty cache lines from cache, it cannot quickly share clean lines from cache. If a cache line is clean with respect to memory and in the shared state, then any snoop request to that cache line will be filled from memory, rather than a cache.

If a processor wishes to write to an Owned cache line, it must notify the other processors that are sharing that cache line. Depending on the implementation it may simply tell them to invalidate their copies (moving its own copy to the Modified state), or it may tell them to update their copies with the new contents (leaving its own copy in the Owned state).

You are assuming AMD engineers are rookies at modern CPU design.

Modern X86 CPUs can reduce their main memory access rates when programmed in a certain way i.e. this is called software optimisations.

CELL SPU programming tricks to fit within 256KB local storage can be applied for modern X86 CPUs.

As an example

Software like Swiftshader (LLVM JIT based software Direct3D9c renderer) has a config file that lets the end user configure Swiftshader's CPU cache size limits.

Setting the correct CPU cache size setting maximises data processing within the CPU's cache, hence minimise spill over to main memory hence reducing main memory access which speeds up Direct3D9c CPU rendering.

If you recall, Vega and Maxwell also has micro tile cache render feature which maximises render processing to stay within the GPU, hence reduces external memory access and minimises high TFLOPS capability being bound by external memory bandwidth.

XBO is mostly GPU ALU bound.

@tormentos said:

The PS4 has no backward compatibility,so yeah something is better than nothing,but from there to stupidly claim that the xbox one increase the xbox 360 users base is a joke,you don't have an argument there is a pathetic and by your shitty logic the PS1 sold 347 million consoles,so how come the media only say 104 every time they talk about it?

Who cares! PS4 doesn't have free PS1, PS2 and PS3 software support.

PS4 doesn't freely expand PS3, PS2 and PS1 runtime install base.

1000 games on the 360 and lems only bought HaloGearsForza. No wonder M$ doesn´t care about gaming anymore.

Meanwhile PS4 = 4000 games and counting.

Quantity =/= Quality, but I get that you wouldn't understand that. Your replies on SW suffer from the same problem.

Quantity =/= Quality, but I get that you wouldn't understand that. Your replies on SW suffer from the same problem.

@Blazed: false