News for hackers. Stuff that matters.
Re:Cray, AMD to Extend DOE’s Exascale Frontier by tntn on Tuesday May 07, 2019 @09:38AM (#19849162)
IMO the coolest thing about Summit/Sierra is that the GPUs and CPUs have a fully coherent single address space with all memory available to the GPUs by default, meaning that your stack- and malloc-allocated variables can be used directly from the GPUs.

I wonder if that will be the case on Frontier.

Re:Cray, AMD to Extend DOE’s Exascale Frontier by eslaught on Tuesday May 07, 2019 @04:24PM (#19853116)
Yes: https://www.olcf.ornl.gov/wp-content/uploads/2019/05/frontie...

However, maybe this is just me, but I don't completely trust this to work without losing a certain amount of peak memory performance. I hope they at least leave the option to turn it off, so we can verify the impact it has on a per-application basis.

Re:Cray, AMD to Extend DOE’s Exascale Frontier by vvanders on Tuesday May 07, 2019 @11:30AM (#19850421)
That's basically the entire state of mobile(minus a few weird SoCs) and many game consoles, makes for a much more convenient development platform.
Re:Cray, AMD to Extend DOE’s Exascale Frontier by tntn on Tuesday May 07, 2019 @12:06PM (#19850770)
I'm not familiar with mobile / APUs, but I was under the impression that it was still necessary to do clCreateBuffer (or similar). I could only find old slides (https://developer.amd.com/wordpress/media/2013/06/1004_final...), though.

Would you mind pointing me in the right direction to learn about how to do this? (something equivalent to slide 2 of https://www.olcf.ornl.gov/wp-content/uploads/2018/12/summit_... but for mobile/APU)?

Re:Cray, AMD to Extend DOE’s Exascale Frontier by vvanders on Tuesday May 07, 2019 @01:30PM (#19851566)
https://www.khronos.org/registry/OpenGL/extensions/OES/OES_E... is the basic entry point on most the OpenGL ES platforms, elsewhere you get into platform-specific APIs.

Mostly my point was the unified system/gpu memory is pretty common outside of the desktop space.

Re:Cray, AMD to Extend DOE’s Exascale Frontier by jacobush on Tuesday May 07, 2019 @10:20AM (#19849602)
Amiga 500 all over again. :)

I feel these things always go back and forth in cycles in the industry.

Re:Cray, AMD to Extend DOE’s Exascale Frontier by tntn on Tuesday May 07, 2019 @10:36AM (#19849805)
I think you'd have a hard time making a case that Summit is a cyclical return to any part of the Amiga 500 :)

"fully coherent single address space with all memory available to [all processors]" is a lot easier if there is no virtual memory, no caching, and all processors are on a single shared bus to the same memory chips.

Re:Cray, AMD to Extend DOE’s Exascale Frontier by wahern on Tuesday May 07, 2019 @10:56AM (#19850042)
You left out the qualifier "Single-socket nodes". It's much easier when all the components are on the same die.
Re:Cray, AMD to Extend DOE’s Exascale Frontier by jacobush on Wednesday May 08, 2019 @09:24AM (#19858568)
Which system are you referring to here?
Re:Cray, AMD to Extend DOE’s Exascale Frontier by wahern on Thursday May 09, 2019 @02:02AM (#19865781)
From the article,

> Single-socket nodes will consist of one CPU and four GPUs, connected by AMD’s custom high bandwidth, low latency coherent Infinity fabric.

The article, at least, only describes coherency in the context of single-socket nodes. I suppose it's ambiguous whether Infinity fabric only connects components on the node or connects nodes to each other, but in fact Infinity fabric is the interconnect used with Zen CPUs, so I think it's pretty clear that in this case it only connects and provides memory coherency for 1xCPU and 4xGPUs.

Performant memory coherency across nodes would be quite an achievement, but not one they seem to have achieved. Rather, it seems they've simply revived the PS4 model.

Re:Cray, AMD to Extend DOE’s Exascale Frontier by jacobush on Thursday May 09, 2019 @08:53AM (#19867807)
So the comparison to an Amiga 500 maybe wasn't so crazy after all. :)