Intel pushing Larrebee console deal with Microsoft

[MfA]

This alone would save on coherency traffic to and from the data-caches. The next step is to make a special chunk of logic to handle these loads and stores, ie a subset of the L2 with much faster access times to lower communication latencies

Seems a rather roundabout way of doing things, making remote access to the producer's L2 subset faster ... even though the moment you store the data you already know where the consumer is going to be. The consumer already has a subset of cache to which it has fast access, it's own L1 cache and L2 subset.

PS. of course even ignoring that, there is already a subset of the local cache with much faster access times ... even though it's not a subset of L2 Just keep it there then, yet another cache doesn't make a whole lotta sense to me.

 

[Fafalada]

Unless Intel provides a scenegraph API that means you "need to manually tile" ... where it happens is irrelevant.

Even Sony provides API for hiearchical display lists with GPU tested bounding volumes on PSP - and they are notorious for not caring about devs

Given how much Intel has got hanging on this they better provide some useful extensions in the base API that highlight why their architecture should be used over others, and this would be one of the obvious highlights.

Question is only whether devs wold be more willing to embrace full-blown scenegraph API or just the display list extensions. Then again they could be nice and provide both (with former being built on top of the latter as a practical example).

 

[MfA]

Even Sony provides API for hiearchical display lists with GPU tested bounding volumes on PSP

I didn't know that, good for them ... they should have gone with a PowerVR chip in that case though

 

[Fafalada]

I didn't know that, good for them ... they should have gone with a PowerVR chip in that case though

Yea... the closest we've got is SBDR on that other handheld.

 

[Gubbi]

Seems a rather roundabout way of doing things, making remote access to the producer's L2 subset faster ... even though the moment you store the data you already know where the consumer is going to be. The consumer already has a subset of cache to which it has fast access, it's own L1 cache and L2 subset.

Only if the producer and consumer have a one-to-one relationship. If you have multiple producers and multiple consumers queueing and dequeueing a FIFO, you don't know where any particular message ends up.

Anyway, even in the one-to-one case you don't want a producing context putting data into the consumer's L1, big can of worms there.

PS. of course even ignoring that, there is already a subset of the local cache with much faster access times ... even though it's not a subset of L2 Just keep it there then, yet another cache doesn't make a whole lotta sense to me.

Cheers