GPGPUs

[luminousone]

On Saturday, 17 August 2013 at 20:17:17 UTC, Atash wrote:
> On Saturday, 17 August 2013 at 15:37:58 UTC, deadalnix wrote:
>> Unified memory have too much benefice for it to be ignored. 
>> The open questions are about cache coherency, direct 
>> communication between chips, identical performances through 
>> the address space, and so on. But the unified memory will 
>> remains. Even when memory is physically separated, you'll see 
>> an unified memory model emerge, with disparate performances 
>> depending on address space.
>
> I'm not saying 'ignore it', I'm saying that it's not the least 
> common denominator among popular devices, and that in all 
> likelihood it won't be the least common denominator among 
> compute devices ever. AMD/ATi being 'right' doesn't mean that 
> they'll dominate the whole market. Having two slots on your 
> mobo is more limiting than having the ability to just chuck 
> more computers in a line hidden behind some thin wrapper around 
> some code built to deal with non-uniform memory access.
>
> Additionally, in another post, I tried to demonstrate a way for 
> it to target the least common denominator, and in my (obviously 
> biased) opinion, it didn't look half bad.
>
> Unlike uniform memory access, non-uniform memory access will 
> *always* be a thing. Uniform memory access is cool n'all, but 
> it isn't popular enough to be here now, and it isn't like 
> non-uniform memory access which has a long history of being 
> here and looks like it has a permanent stay in computing.
>
> Pragmatism dictates to me here that any tool we want to be 
> 'awesome', eliciting 'wowzers' from all the folk of the land, 
> should target the widest variety of devices while still being 
> pleasant to work with. *That* tells me that it is paramount to 
> *not* brush off non-uniform access, and that because 
> non-uniform access is the least common denominator, that should 
> be what is targeted.
>
> On the other hand, if we want to start up some sort of thing 
> where one lib handles the paradigm of uniform memory access in 
> as convenient a way as possible, and another lib handles 
> non-uniform memory access, that's fine too. Except that the 
> first lib really would just be a specialization of the second 
> alongside some more 'convenience'-functions.

There are two major things, unified memory, and unified virtual 
address space.

Unified virtual address will be universal within a few years, and 
the user space application will no longer manage the cpu/gpu 
copies anymore, this instead will be handled by the gpu system 
library, hMMU, and operating system.

Even non-uniform memory will be uniform from the perspective of 
the application writer.