I hope I'm not the only one who finds this article poorly written; I got a better understanding from the list of bullet points on the slide than I did trying to follow the rambling paragraphs below them.
AMD and ARM's new CPU/GPU virtual ISA
21–27 of 27 posts
Re: AMD and ARM's new CPU/GPU virtual ISA
#22Earlier quoted context omitted.
You can find the whole main presentation here: http://developer.amd.com/documentation/presentations/assets/... I'm presuming stuff coming from amd.com is confirmation. It should certainly include future products, what I would worry about is to what extent existing graphics cards will be able to take advantage of this. Generally, I'd say this looks a lot like Clang but with better ways to express memory parralelism at…
I think it's bigger than that - the idea that a GPU can execute syscalls is pretty crazy if you really buy into it (i.e. the entire OS is running using this heterogenous environment)
This is possible now [1]. FSA will (hopefully) make it significantly more efficient.
[1] http://www.idav.ucdavis.edu/publications/print_pub?pub_id=10...
Re: AMD and ARM's new CPU/GPU virtual ISA
#23Earlier quoted context omitted.
One word. Microsoft, if them AMD and ARM are onboard that's it. Remember nVidia is an ARM licensor/developer
AMD is definitely not on board with Microsoft taking over the scene. AMD is 100% behind standards, standards like OpenCL. Look at the way MS implemented their AMP C++ GPU story, http://herbsutter.com/2011/06/16/c-amp-keynote/ that looks to me like it targets and has all the limitations of DirectCompute (MS specific GPGPU). If MS really wants to make this a standard then most likely AMD will implement that standard us…
Think of it this way. OpenCL like OpenGL is an API that says you can build it however you want so long as it comply's with this standard. DirectX and DirectCompute are the same. Despite their vast architectural difference both AMD and nVidia GPU's work on them just fine, All FSAIL does is bring it all closer to the metal and encompasses the CPU as well, (instead of just GPU alone). You're telling me Microsoft (still OS marketshare leader) want's to split arch dev teams between x86,ARM or whatever else the future brings. They'll probably come up with their own version of FSAIL but I think they'd be stupid if they weren't on board (at least with their own version).
Re: AMD and ARM's new CPU/GPU virtual ISA
#24Earlier quoted context omitted.
Even NVIDIA isn't crazy enough to try to get everyone to use the same ISA again; they're trying to get you to buy into their compiler chain, not into the architecture of a particular generation of GPU.
Is PTX really ISA? It's also virtual, but very limited ... Unlike PTX, FSAIL will work on both CPUs and GPUs and even will allow system calls from discrete GPUs.
PTX seems quite reasonable to me, but I don't think it's really intended to be a programmer-facing abstraction. NVIDIA wants you to target CUDA, and they'll (try to) ensure that CUDA has sufficient performance advantages to make it worth your while to do so.
Re: AMD and ARM's new CPU/GPU virtual ISA
#25Earlier quoted context omitted.
One word. Microsoft, if them AMD and ARM are onboard that's it. Remember nVidia is an ARM licensor/developer
AMD is definitely not on board with Microsoft taking over the scene. AMD is 100% behind standards, standards like OpenCL. Look at the way MS implemented their AMP C++ GPU story, http://herbsutter.com/2011/06/16/c-amp-keynote/ that looks to me like it targets and has all the limitations of DirectCompute (MS specific GPGPU). If MS really wants to make this a standard then most likely AMD will implement that standard us…
MS has money, which most people accept.
https://secure.wikimedia.org/wikipedia/en/wiki/File:AMD_K5_P...
btw: there is a story about a company committed to Open stuff (Linux, Qt), just to [d|b]itch it.
Re: AMD and ARM's new CPU/GPU virtual ISA
#26Earlier quoted context omitted.
AMD is definitely not on board with Microsoft taking over the scene. AMD is 100% behind standards, standards like OpenCL. Look at the way MS implemented their AMP C++ GPU story, http://herbsutter.com/2011/06/16/c-amp-keynote/ that looks to me like it targets and has all the limitations of DirectCompute (MS specific GPGPU). If MS really wants to make this a standard then most likely AMD will implement that standard us…
MS has money, which most people accept. https://secure.wikimedia.org/wikipedia/en/wiki/File:AMD_K5_P... btw: there is a story about a company committed to Open stuff (Linux, Qt), just to [d|b]itch it.
We are nearly in a post MS reality. It is like 1988 all over again. DR Dos, DESQview, GEOS they are all back in way with iOS, Android (which oddly enough is more Newton influenced than iOS).
The Win95 logo on a K5 doesn't bother me, Nokia doing really stupid stuff is indicative that they didn't have any solid competition for a great long while and went batshit insane. I had reports from Finnish friends that claimed that Nokia acted like they owned the whole damn country and make or break any law it pleased. When that kind of hubris implodes you best not be standing too close. They could have made a tidy sum selling well built yet simple Android powered phones to the worlds bottom 2 Billion People while attacking the verticals underserved by Nextel and Blackberry's gaffs. HTC owns the mainstream sexy-as-hell phone market. I would not try or want to compete with HTC.
AMD is above all this buffoonery, they are about to license their IP and throw it to the wind. And ARM might just end up managing the portfolio.
Re: AMD and ARM's new CPU/GPU virtual ISA
#27Holy crap, memory barriers! It's a modern architecture that's finally caught up to where Symbolics was at in the '80s. Seriously though, this is good news for concurrent garbage collected languages.
Barriers are slow, and the more cores are hitting the barrier the slower it will be. The best news on that front was from the new GPU architecture parts, where they admitted that they're still going to expose the relaxed consistency memory model.
"Barriers are slow" in what way? Azul was hitting 10-20ms pauses while successfully garbage collecting 500GB+ heaps using hardware memory barriers on their Vega architecture, which had up to 768 CPUs.
Cliff Click, Azul's principal JVM architect, seemed somewhat ambivalent about how much hardware transactional memory actually helped them hit those targets (i.e. it's not a silver bullet), but he chided Sun for not including it on their Niagra chips when they were providing both the language runtime and the hardware platform.
I'll say it again: Getting them on a commodity architecture is a great thing for concurrent garbage collected languages.