GPGPUs

[Atash]

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.