Article: Impressions of Kepler
By: David Kanter (dkanter.delete@this.realworldtech.com), April 9, 2012 2:51 pm
Room: Moderated Discussions
EduardoS (no@spam.com) on 4/4/12 wrote:
>AMD did a really good work on keeping the same compute density without VLIW but
>this won't magically made all other problems disappear (the copmpiler problem were
>reduced since a VLIW design requires some optimizations they weren't doing), now,
>that the scapegoat is gone maybe they will be more serious about the compute performance...
>
>But this doesn't explain why the hardware wasn't used for GPGPU, when selling a
>completly new idea wich poses a risk to the constumers being incredible fast on
>a few things is much better than being avarage on everything since for the former
>there will be cases where the benefits are bigger than the risks.
>
>The public relations team play a big role on this and >nVidia did well there.
There are a number of factors:
1. Software - AMD's software has always been weaker than Nvidia, as they have fewer people, etc.
That's a huge problem in workstation and in HPC. In graphics, if the developer encounters a bug it has a good chance of not being important. In HPC, it's going to be noticed. Moreover, GPUs have a long history of shipping broken hardware without anyone noticing because of the driver. You simply cannot get away with that kind of stuff. On top of that you need to constantly reach out to major software developers - something AMD has historically had problems with.
Nvidia was happy to throw out their own proprietary standard, push it, support it, etc. That's just not in AMD's DNA, since they cannot push their own standards. They tend to piggyback on work from other larger companies (e.g. MS).
2. Consistent performance. AMD's GPUs had highly varied performance due to VLIW. That makes #1 worse.
3. Focus on graphics - that's the high volume and AMD wasn't interested in getting distracted. That means no ECC, etc. which are nice marketing check points.
4. Strategic problems - At one point Opteron was the platform of choice for HPC, and even up until 2010 it was a solid platform there. Why would you want to cannibalize your high margin server CPUs with lower margin GPUs? That logic doesn't apply now, but remember GPUs probably take 3-5 years start to finish.
There are a huge number of issues. But perhaps the biggest is #1. If AMD had a nice GPU available in 2010, what would you program it with?
David
>AMD did a really good work on keeping the same compute density without VLIW but
>this won't magically made all other problems disappear (the copmpiler problem were
>reduced since a VLIW design requires some optimizations they weren't doing), now,
>that the scapegoat is gone maybe they will be more serious about the compute performance...
>
>But this doesn't explain why the hardware wasn't used for GPGPU, when selling a
>completly new idea wich poses a risk to the constumers being incredible fast on
>a few things is much better than being avarage on everything since for the former
>there will be cases where the benefits are bigger than the risks.
>
>The public relations team play a big role on this and >nVidia did well there.
There are a number of factors:
1. Software - AMD's software has always been weaker than Nvidia, as they have fewer people, etc.
That's a huge problem in workstation and in HPC. In graphics, if the developer encounters a bug it has a good chance of not being important. In HPC, it's going to be noticed. Moreover, GPUs have a long history of shipping broken hardware without anyone noticing because of the driver. You simply cannot get away with that kind of stuff. On top of that you need to constantly reach out to major software developers - something AMD has historically had problems with.
Nvidia was happy to throw out their own proprietary standard, push it, support it, etc. That's just not in AMD's DNA, since they cannot push their own standards. They tend to piggyback on work from other larger companies (e.g. MS).
2. Consistent performance. AMD's GPUs had highly varied performance due to VLIW. That makes #1 worse.
3. Focus on graphics - that's the high volume and AMD wasn't interested in getting distracted. That means no ECC, etc. which are nice marketing check points.
4. Strategic problems - At one point Opteron was the platform of choice for HPC, and even up until 2010 it was a solid platform there. Why would you want to cannibalize your high margin server CPUs with lower margin GPUs? That logic doesn't apply now, but remember GPUs probably take 3-5 years start to finish.
There are a huge number of issues. But perhaps the biggest is #1. If AMD had a nice GPU available in 2010, what would you program it with?
David
Topic | Posted By | Date |
---|---|---|
First impressions of Nvidia's Kepler | David Kanter | 2012/03/22 06:00 PM |
First impressions of Nvidia's Kepler | fellix | 2012/03/23 01:25 AM |
First impressions of Nvidia's Kepler | Mike | 2012/03/23 08:24 AM |
First impressions of Nvidia's Kepler | David Kanter | 2012/03/23 09:02 AM |
First impressions of Nvidia's Kepler | Mike | 2012/03/23 09:34 AM |
First impressions of Nvidia's Kepler | David Kanter | 2012/03/23 12:15 PM |
First impressions of Nvidia's Kepler | anon | 2012/03/23 11:37 AM |
I use ALUs | Mark Roulo | 2012/03/23 12:59 PM |
I use ALUs | anon | 2012/03/23 02:07 PM |
I use ALUs | Mark Roulo | 2012/03/23 03:12 PM |
I use ALUs | anon | 2012/03/23 04:08 PM |
Makes no sense... | EduardoS | 2012/03/23 05:30 PM |
Makes no sense... | anon | 2012/03/23 06:14 PM |
Makes no sense... | David Kanter | 2012/03/25 10:45 AM |
Makes no sense... | fellix | 2012/03/24 05:41 AM |
Comparing against the 560 | Cat | 2012/03/26 08:51 AM |
Comparing against the 560 | David Kanter | 2012/03/26 09:24 AM |
Shuffle Instruction | Martin | 2012/03/27 06:17 AM |
Shuffle Instruction | David Kanter | 2012/03/27 08:47 AM |
Shuffle Instruction | Martin | 2012/03/27 10:52 AM |
.msi unarchiver? | hobold | 2012/03/28 10:20 AM |
.msi unarchiver? | Joe | 2012/03/28 12:55 PM |
.msi unarchiver? | Martin | 2012/03/29 12:53 AM |
Shuffle Instruction | Rohit | 2012/03/27 12:04 PM |
Workgroups vs. warps/wavefronts | Andrew McDonald | 2012/03/28 02:31 PM |
Workgroups vs. warps/wavefronts | David Kanter | 2012/03/28 03:14 PM |
Workgroups vs. warps/wavefronts | Rohit | 2012/03/28 08:53 PM |
Workgroups vs. warps/wavefronts | Lee Howes | 2012/03/29 06:38 AM |
Threads | David Kanter | 2012/04/09 11:36 AM |
Fixed (NT) | David Kanter | 2012/04/09 11:37 AM |
Heterogeneous GPUs | Oscar Eddington | 2012/03/28 07:41 PM |
Heterogeneous GPUs | Gary M. | 2012/04/06 04:35 PM |
Different shader cores | David Kanter | 2012/04/09 11:29 AM |
Different shader cores | Tom | 2012/04/11 02:36 PM |
Nope... | David Kanter | 2012/04/12 01:10 AM |
Nope... | Tom | 2012/04/13 03:58 PM |
Nope... | David Kanter | 2012/04/14 12:24 PM |
Load balancing between Tesla and graphics boards | Tom | 2012/04/15 06:11 PM |
Load balancing between Tesla and graphics boards | David Kanter | 2012/04/15 10:11 PM |
Load balancing between Tesla and graphics boards | Anon | 2012/04/16 05:05 PM |
Why isn't AMD hardware used for GPU computing? | Richard G. | 2012/04/03 07:39 PM |
Why isn't AMD hardware used for GPU computing? | anon | 2012/04/04 03:11 AM |
Why isn't AMD hardware used for GPU computing? | Soupdragon | 2012/04/04 05:24 AM |
Why isn't AMD hardware used for GPU computing? | Groo | 2012/04/04 08:41 AM |
Why isn't AMD hardware used for GPU computing? | Michael S | 2012/04/04 06:24 AM |
Why isn't AMD hardware used for GPU computing? | Alexko | 2012/04/04 08:43 AM |
Why isn't AMD hardware used for GPU computing? | EduardoS | 2012/04/04 03:37 PM |
Why isn't AMD hardware used for GPU computing? | David Kanter | 2012/04/09 02:51 PM |
Why isn't AMD hardware used for GPU computing? | Ricardo B | 2012/04/04 12:57 PM |
Why isn't AMD hardware used for GPU computing? | Tom | 2012/04/04 05:36 PM |
Why isn't AMD hardware used for GPU computing? | Brett | 2012/04/04 06:55 PM |
Why isn't AMD hardware used for GPU computing? | David Kanter | 2012/04/09 02:55 PM |
Predictions about Kepler | Russell Baker | 2012/04/18 02:09 PM |
Predictions about Kepler | 0100010 | 2012/04/18 03:14 PM |
Predictions about Kepler | EduardoS | 2012/04/18 03:38 PM |
Predictions about Kepler | Anon | 2012/04/18 08:48 PM |
Predictions about Kepler | EduardoS | 2012/04/19 03:03 PM |
Predictions about Kepler | Meeps | 2012/04/19 03:39 PM |
Predictions about Kepler | John P. | 2012/04/18 06:13 PM |
Predictions about Kepler | Foo_ | 2012/04/19 12:15 PM |
Predictions about Kepler | EduardoS | 2012/04/19 03:07 PM |
Predictions about Kepler | Groo | 2012/04/19 09:13 AM |
Predictions about Kepler | anon | 2012/04/19 03:26 PM |
Predictions about Kepler | Groo | 2012/04/20 08:01 AM |
Predictions about Kepler | Alex L. | 2012/04/20 03:41 PM |
Predictions about Kepler | Anon | 2012/04/21 09:34 AM |
Predictions about Kepler | mpx | 2012/04/21 11:23 PM |
Predictions about Kepler | ac | 2012/04/22 01:49 AM |