Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #2423 > unrolled thread

Very good news from AMD

Back to article view | Back to comp.arch

Contents

  Very good news from AMD Quadibloc <jsavard@ecn.ab.ca> - 2011-07-07 20:14 -0700
    Re: Very good news from AMD Jason Riedy <jason@lovesgoodfood.com> - 2011-07-08 09:37 -0400
      Re: Very good news from AMD "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-08 09:33 -0700
        Re: Very good news from AMD "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-07-08 16:21 -0700
          Re: Very good news from AMD "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-08 17:30 -0700
            Re: Very good news from AMD "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-07-25 20:24 -0700
      Re: Very good news from AMD Robert Myers <rbmyersusa@gmail.com> - 2011-07-08 12:33 -0700
        Re: Very good news from AMD Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-07-08 20:59 +0100
          Re: Very good news from AMD Robert Myers <rbmyersusa@gmail.com> - 2011-07-09 14:57 -0700
      Re: Very good news from AMD "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-08 17:17 -0700
        Re: Very good news from AMD Jason Riedy <jason@lovesgoodfood.com> - 2011-07-09 20:01 -0400
          Re: Very good news from AMD "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-09 23:46 -0700
            Re: Very good news from AMD Jason Riedy <jason@lovesgoodfood.com> - 2011-07-10 13:34 -0400
              Re: Very good news from AMD "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-10 12:23 -0700
      Re: Very good news from AMD Quadibloc <jsavard@ecn.ab.ca> - 2011-07-08 18:14 -0700
      Re: Very good news from AMD Quadibloc <jsavard@ecn.ab.ca> - 2011-07-09 10:19 -0700
    Re: Very good news from AMD Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-07-08 23:11 +0200
    Re: Very good news from AMD "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-07-10 09:39 +0200
      Re: Very good news from AMD "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-07-11 10:37 +0200
        Re: Very good news from AMD "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-07-12 03:55 +0200
          Re: Very good news from AMD "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-07-12 04:05 +0200

Page 1 of 2  [1] 2  Next page →

#2423 — Very good news from AMD

Apparently their new generation of microprocessors with integrated
GPUs will also involve a significant redesign of the GPU so as to make
it more flexible, and thus more useful for assisting with general
floating-point computation.

http://www.theregister.co.uk/2011/07/07/amd_graphics_core_next/

John Savard

[toc] | [next] | [standalone]

#2427

And Quadibloc writes:
> http://www.theregister.co.uk/2011/07/07/amd_graphics_core_next/

Cute.  It's a Cray X1/SV2 on a chip.
-- 
Jason

[toc] | [prev] | [next] | [standalone]

#2430

On 7/8/2011 6:37 AM, Jason Riedy wrote:
> And Quadibloc writes:
>> http://www.theregister.co.uk/2011/07/07/amd_graphics_core_next/
>
> Cute.  It's a Cray X1/SV2 on a chip.


I'vwe been hoping to find time to write an article "AMD's Next 
Generation GPU: Larrabee done right."

They are apparently giving up on VLIW.

They are even giving up on SIMT/CT (Single Instruction Multiple 
Threads/Coherent Threading).

When I asked the architect (I attended the conference) how they compared 
to Larrabee, he said "well, we have 2Kbit entry vectors spread over 4 
clocks, rather than 512b vectors done in exactly one clock".

I would go further: they are a dynamically scheduled vector machine.
Choosing which instructions to dispatch from 10 or 40 threads per 
compute unit (I need to check my notes - I think it is choosing up to 10 
instructions from 10 different threads, which will execute for 4 cycles, 
from a pool off 40 threads per compute unit - but I may have that wrong).

They may have totally given up on SIMT/CT, but I would not be surprised 
to see some ISA support to make it easier to emulate DirectX or OpenGL 
threads per vector lane.

Unfortunately, only high level keynote slides are on web.  The actual 
detail slides, from Mantor and Houston's talk, are not on the web.

[toc] | [prev] | [next] | [standalone]

#2435

On Jul 8, 12:33 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:
[snip]
> Unfortunately, only high level keynote slides are on web.  The actual
> detail slides, from Mantor and Houston's talk, are not on the web.

Pictures of some of the slides are at:
http://www.hardware.fr/news/11648/afds-architecture-futurs-gpus-amd.html

(I think this link was presented at the Real World Technologies
forum.)

I do hope that the presentation will be posted with the others from
the
AFDSummit.


Paul A. Clayton

[toc] | [prev] | [next] | [standalone]

#2438

On 7/8/2011 4:21 PM, Paul A. Clayton wrote:
> On Jul 8, 12:33 pm, "Andy \"Krazy\" Glew"<a...@SPAM.comp-arch.net>
> wrote:
> [snip]
>> Unfortunately, only high level keynote slides are on web.  The actual
>> detail slides, from Mantor and Houston's talk, are not on the web.
>
> Pictures of some of the slides are at:
> http://www.hardware.fr/news/11648/afds-architecture-futurs-gpus-amd.html
>
> (I think this link was presented at the Real World Technologies
> forum.)
>
> I do hope that the presentation will be posted with the others from
> the
> AFDSummit.
>
>
> Paul A. Clayton




Demers presentation, with a few pictures of the Next GPU architecture, 
is at

http://developer.amd.com/documentation/presentations/assets/6-Demers-FINAL.pdf

Some other good keynotes at
http://developer.amd.com/afds/pages/keynote.aspx

But AFAIK no slides from the sessions.  Which is where the real detail was.

[toc] | [prev] | [next] | [standalone]

#2719

On Jul 8, 8:30 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:
[snip]
> Some other good keynotes athttp://developer.amd.com/afds/pages/keynote.aspx
>
> But AFAIK no slides from the sessions.  Which is where the real detail was.

PDFs for the session presentations are now available:
http://developer.amd.com/afds/pages/sessions.aspx

The Mike Houston & Mike Mantor presentation "AMD Graphics Core Next":
http://developer.amd.com/afds/assets/presentations/2620_final.pdf

[toc] | [prev] | [next] | [standalone]

#2432

On Jul 8, 9:37 am, Jason Riedy <ja...@lovesgoodfood.com> wrote:
> And Quadibloc writes:
> >http://www.theregister.co.uk/2011/07/07/amd_graphics_core_next/
>
> Cute.  It's a Cray X1/SV2 on a chip.

Minus the bandwidth.

Robert.

[toc] | [prev] | [next] | [standalone]

#2433

In article <e30d9cbc-1637-41f6-b83e-85ee2ac4a162@c41g2000yqm.googlegroups.com>,
Robert Myers  <rbmyersusa@gmail.com> wrote:
>On Jul 8, 9:37=A0am, Jason Riedy <ja...@lovesgoodfood.com> wrote:
>> And Quadibloc writes:
>> >http://www.theregister.co.uk/2011/07/07/amd_graphics_core_next/
>>
>> Cute. =A0It's a Cray X1/SV2 on a chip.
>
>Minus the bandwidth.

Probably 200GB/second, which is the bandwidth that a four-processor X1
module had.

Tom

[toc] | [prev] | [next] | [standalone]

#2449

On Jul 8, 3:59 pm, Thomas Womack <twom...@chiark.greenend.org.uk>
wrote:
> In article <e30d9cbc-1637-41f6-b83e-85ee2ac4a...@c41g2000yqm.googlegroups.com>,
> Robert Myers  <rbmyers...@gmail.com> wrote:
>
> >On Jul 8, 9:37=A0am, Jason Riedy <ja...@lovesgoodfood.com> wrote:
> >> And Quadibloc writes:
> >> >http://www.theregister.co.uk/2011/07/07/amd_graphics_core_next/
>
> >> Cute. =A0It's a Cray X1/SV2 on a chip.
>
> >Minus the bandwidth.
>
> Probably 200GB/second, which is the bandwidth that a four-processor X1
> module had.
>
Let's wait and see how that bandwidth looks on anything but graphics
and trivial "nearest neighbor" calculations.

Robert.

[toc] | [prev] | [next] | [standalone]

#2436

On 7/8/2011 6:37 AM, Jason Riedy wrote:
> And Quadibloc writes:
>> http://www.theregister.co.uk/2011/07/07/amd_graphics_core_next/
>
> Cute.  It's a Cray X1/SV2 on a chip.

By the way, I don't think that the Cray X1/SV2 did dynamic thread 
scheduling.  Did it?

The Tera machines did have dynamic hardware thread scheduling.  But I 
think they were less dynamic than AMD's GPUs are.

[toc] | [prev] | [next] | [standalone]

#2450

And Andy Glew writes:
> By the way, I don't think that the Cray X1/SV2 did dynamic
> thread scheduling.  Did it?

Not that I recall.  That would be a difference, depending on how
it really plays out.  I suspect the first generation won't have
much support for rescheduling, but hopefully I'm wrong.  I'd bet
the pressure from the graphics side will prefer using space for
execution units over saved contexts.

> The Tera machines did have dynamic hardware thread scheduling.
> But I think they were less dynamic than AMD's GPUs are.

Do you mean the MTA seems less dynamic than the GPUs?  No.  Far
more so simply by working only with single streams (one-wide
wavefronts).  But if you mean the X1's less dynamic than the
GPUs, then almost definitely so long as AMD actually implements
the possibility.

I'm more curious to see what they learned from the Cray software
environment, given that the X1 had one somewhat underpowered
sequential CPU coupled to the vector units.  I don't expect
direct cross-pollination considering Cray's chosen nVidia as
their partner in GPU-ish work.
-- 
Jason

[toc] | [prev] | [next] | [standalone]

#2451

On 7/9/2011 5:01 PM, Jason Riedy wrote:
> And Andy Glew writes:
>> By the way, I don't think that the Cray X1/SV2 did dynamic
>> thread scheduling.  Did it?
>
> Not that I recall.  That would be a difference, depending on how
> it really plays out.  I suspect the first generation won't have
> much support for rescheduling, but hopefully I'm wrong.  I'd bet
> the pressure from the graphics side will prefer using space for
> execution units over saved contexts.
>
>> The Tera machines did have dynamic hardware thread scheduling.
>> But I think they were less dynamic than AMD's GPUs are.
>
> Do you mean the MTA seems less dynamic than the GPUs?  No.  Far
> more so simply by working only with single streams (one-wide
> wavefronts).

Memory may be failing me, but I think that the MTA was a fixed barrel 
scheduled machine.  Did thy not have a fixed 128 threads per node, and 
always switch from thread to thread, every cycle, with no variation in 
the schedule?

The GPUs, on the other hand, are not fixed barrel schedules.  Not in the 
past few years, at least - they may have started as simple barrel 
schedules.  It seems that the AMD Next has generation has the ability, 
on a every 4 cycle basis, to select 10 threads from a pool of 40. 
Dynamic, not a fixed schedule.

[toc] | [prev] | [next] | [standalone]

#2455

And Andy Glew writes:
> Memory may be failing me, but I think that the MTA was a fixed
> barrel scheduled machine.  Did thy not have a fixed 128 threads
> per node, and always switch from thread to thread, every cycle,
> with no variation in the schedule?

It switched to the next *ready* stream.  If a stream is waiting
for memory, it isn't ready and is skipped by scheduling.
Similarly, if a stream already has an instruction in the pipe,
it's skipped.

My old micro-benchmarks made the scheduling look a bit more
dynamic than a simple barrel even without memory interaction.
There was a large variation in the number of cycles between
consecutive instructions in a single stream.
-- 
Jason

[toc] | [prev] | [next] | [standalone]

#2459

On 7/10/2011 10:34 AM, Jason Riedy wrote:
> And Andy Glew writes:
>> Memory may be failing me, but I think that the MTA was a fixed
>> barrel scheduled machine.  Did thy not have a fixed 128 threads
>> per node, and always switch from thread to thread, every cycle,
>> with no variation in the schedule?
>
> It switched to the next *ready* stream.  If a stream is waiting
> for memory, it isn't ready and is skipped by scheduling.
> Similarly, if a stream already has an instruction in the pipe,
> it's skipped.
>
> My old micro-benchmarks made the scheduling look a bit more
> dynamic than a simple barrel even without memory interaction.
> There was a large variation in the number of cycles between
> consecutive instructions in a single stream.


OK, that is pretty much what the GPUs do.  With the addition that they 
operate on SIMT.  AMD's next geberation may be getting rid of the 
coherent threading, and be a more classsic vector archittecture, 
although picking a 10 instructions, each from 1 thread out of 40, per cycle.

[toc] | [prev] | [next] | [standalone]

#2439

On Jul 8, 7:37 am, Jason Riedy <ja...@lovesgoodfood.com> wrote:

> Cute.  It's a Cray X1/SV2 on a chip.

In searching for information about that computer, I found that while
its official name is the Cray X1, at first when Cray was planning the
design, it referred to it as the SV2, because it was considered a
successor to the SV1.

Some sites erroneously convey the impression that "SV2" was an NSA
codename for the machine.

John Savard

[toc] | [prev] | [next] | [standalone]

#2442

On Jul 8, 7:37 am, Jason Riedy <ja...@lovesgoodfood.com> wrote:
> And Quadibloc writes:
> >http://www.theregister.co.uk/2011/07/07/amd_graphics_core_next/
>
> Cute.  It's a Cray X1/SV2 on a chip.

Although someone else already put a (slow, incomplete) Cray-I on a
chip using an FPGA, I would have been happy with some next-generation
version of SSE finally, in effect, putting a vector architecture of
the Cray-I kind in chips.

If this really does go even beyond that, yes, it will be very good.

John Savard

[toc] | [prev] | [next] | [standalone]

#2434

Quadibloc wrote:
> Apparently their new generation of microprocessors with integrated
> GPUs will also involve a significant redesign of the GPU so as to make
> it more flexible, and thus more useful for assisting with general
> floating-point computation.
>
> http://www.theregister.co.uk/2011/07/07/amd_graphics_core_next/

This was a very obvious development, AMD just had to look at Intel's LRB 
(excuse me, MIC) to see that they needed something which is closer to a 
general cpu as seen by the programmers.

On the other hand we have the latest SSE addition to regular x86 cpus 
which includes scatter/gather borrowed directly from LRB, i.e. all the 
various cpu versions seem to converge towards a platform which allows 
relatively easy short vector programming.

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#2452

"
Apparently their new generation of microprocessors with integrated
GPUs will also involve a significant redesign of the GPU so as to make
it more flexible, and thus more useful for assisting with general
floating-point computation.

http://www.theregister.co.uk/2011/07/07/amd_graphics_core_next/

John Savard
"

What I would like to know is:

How many (random) memory transaction per second can it do ? ;) :)

Also further thoughts:

1. Hanging on to old graphics technology is probably not wise.

I would recommend AMD to look at what the "offline rendering crowd" is 
doing.

What they are doing will be the future of realtime graphics in 5 to 15 years 
or so.

Some of those guys are using "global illimination/light casting" for nice 
glass effects.

For example iRay seems nice. There are others too like LuxRender or 
something like that...
I am not into that because I am not a graphics guy... but holding on to 
"texture mapping, bump mapping and shaders" is probably old and will 
probably die out soon enough...

Nothing mentioned in the article about instruction set... how is all of this 
to be programmed ?

Bye,
  Skybuck ;)

P.S.: I am getting close to finishing my first cuda benchmark/test program 
to see how many random memory transactions it can do... in a certain fashion 
but close enough... quite interesting, it will probably be done tomorrow or 
the day after that and then I will probably re-do the test as well for cpu 
which will be a snap and then compare results.

I will probably also ask some questions about how to best optimize memory 
layout for cpu... for now I assume sequential layout is good and will now 
lead to any weird banking conflicts or so ;) 

[toc] | [prev] | [next] | [standalone]

#2464

(Not my subject description)

Status of my benchmarking of cuda, more will follow soon:

Well, time for some numbers...

Exact measurements must still be done, but so far I am counting the seconds 
myself for a somewhat estimation of what's going on.

Settings tested:

mElementCount.Value := 8000;
mBlockCount.Value := 10000;
mLoopCount.Value := 80000;

This means there are 10.000 blocks each containing 8.000 elements. An 
element is a 32 bit integer so that's 4 bytes.

For a total of: 10.000 x 8.000 x 4 = 320.000.000 bytes (300 in the mega 
range)

The loop count represents the number of times each block performs a memory 
lookup within it's element array of 8000.

This is done 80.000 times.

So number of bytes transferred: 80.000 x 10.000 x 4 bytes = 3.200.000.000 (3 
in the giga range)

It does all of this in approximately 16 to 20 seconds or so depending on 
some minor kernel and/or launch tweaks.

So that's about 160 MB per second or so...

I am more interested in how many integers it could lookup, which is about 
80.000 x 10.000 in 20 seconds = 800.000.000 in 20 seconds.

So that's roughly: 40.000.000 in one second.

These are just estimates for now...

I haven't done the same benchmark yet on the cpu, but the corewar simulator 
was similiar and did even much more processing with branches and such and it 
could do 160.000.000 in 1.5 seconds or so or 1.0 second or so...

So things are starting to look a bit bad for cuda and the gt 520 ;)

However more exact measurements and comparisions need to be done... but 
based on these first observations... the cuda memory lookup performance is 
probably sucky and worse than cpu, I could be wrong though, but I don't 
think so, but I will continue with benchmarking it a bit more properly.

Some factors of influence:

For gpu:

1. The more memory it can use the faster it will probably be, but I am not 
sure, the current benchmark has troubles allocating "test memory" on host 
which needs to be transferred to cuda/device... so this is a bit of a nasty 
situation. Perhaps a kernel could be written which initializes the memory... 
so far this is done on host to be sure it's done somewhat correctly.

For cpu:

1. The cpu has a very fast local cache where the problem size can probably 
fit in quite well, this allows cpu to spin real fast over that memory.


CPU has about 16 GB/sec cache or so per core.

GPU has about 12 GB/sec at least it said some on some chart, in reality it 
seems to be lower close to 9 GB/sec according to visual profiler which is a 
bit weird...

Anyway it could be interesting if other people could run my cuda benchmark 
on their graphics card to see what they get for a results...

So I will probably release my test program in the near future, few days from 
now or so, and the kernel in ptx form or maybe even cu form so people can 
test it out ;)

Consider this posting an "approximation" ;) :)

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

#2468

Well now, time for some real numbers.

The numbers are fluctuating a little bit depending on the settings.

So far my prediction that more memory usage would lead to better gpu results 
seems to be true.

Yesterday after I wrote the posting and went to bed I also thought to myself 
that the results should probably be similiar since they are probably both 
using the same kind of memory technology, so it's the memory technology 
itself that is limiting both systems.

That will probably need to change in the future... they way they interact 
with the memory, the memory would need to be split up into multiple 
independent sections with their own lanes somehow... that's what I am 
thinking.

Anyway now let's go analyse the results:

Settings where:

20.000 blocks
8.000 elements per block.
80.000 loops per block.

So 20.000x80.000 memory transactions were performed each on GPU and CPU.

First numbers:

Kernel execution time in seconds: 25.0861718750000000
CPU execution time in seconds   : 31.0449578088835310

The CPU is 6 seconds slower.

In other words:

(new - old)/old * 100 = 24%.

So the GPU is just 24% faster, it's a cheap GPU though ;)

However please keep in mind that this test only uses one core of the CPU.
So what remains to be explored is how the CPU would perform if it was 
multi-threaded. That in itself would be an interesting test to see if 
multi-cores can somehow increase mts or not.
My expecting would probably be not, unless it's the memory controller itself 
that's leading to slow down.

Other numbers from this test:

Cuda memory transactions per second: 63.780.157
CPU memory transactions per second : 51.538.159

Cuda/gpu does about 64 million per second.
CPU does about 51 million per second. (one core).

Interesting results, but not really.

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch

csiph-web