Hi,
I have been reading the ongoing discussion about what to do about AMD DC
(Display Core) with great interest since I have started to put more time into
developing OpenChrome DRM for VIA Technologies Chrome IGP.
I particularly enjoyed reading what Tony Cheng wrote about what is going on
inside AMD Radeon GPUs.
As a graphics stack developer, I suppose I am still someone somewhat above a
beginner level, and Chrome IGP might be considered garbage graphics to some (I
do not really care what people say or think about it.), but since my background
is really digital hardware design (self taught) rather than graphics device
driver development, I will like to add my 2 cents (U.S.D.) to the discussion.
I also consider myself an amateur semiconductor industry historian, and in
particular, I have been a close watcher of Intel's business / hiring practice
for many years.
For some, what I am writing may not make sense or even offend some (my guess
will be the people who work at Intel), but I will not pull any punches, and if
you do not like what I write, let me know. (That does not mean I will
necessarily take back my comment even if it offended you. I typically stand
behind what I say, unless it is obvious that I am wrong.)
While my understanding of DRM is still quite primitive, my simplistic
understanding of why AMD is pushing DC is due to the following factors.
1) AMD is understaffed due to its precarious financial condition it is in right
now (i.e., < $1 billion CoH and losing 7,000 employees since Year 2008 or so)
2) The complexity of the next generation ASIC is only getting worse due to the
continuing process scaling = more transistors one has to use (i.e., TSMC 28 nm
to GF 14 nm to probably Samsung / TSMC 10 nm or GF 7 nm)
3) Based on 1 and 2, unless the design productively can be improved, AMD will
be late to market, and this can be the possible end to AMD as a corporation
4) Hence, in order to meet TtM and improve engineer productivity, AMD needs to
reuse the existing pre-silicon / post-silicon bring up test code and share the
code with the Windows side of the device driver developers
5) In addition, power is already the biggest design challenge, and very precise
power management is crucial to the performance of the chip (i.e., it's not all
about the laptop anymore, and desktop "monster" graphics cards also need power
management for performance reasons, in order to manage heat generation)
6) AMD Radeon is really running an RTOS (Real Time Operating System) inside the
GPU card, and they want to put the code to handle initialization / power
management closer to the GPU rather than from the slower response x86 (or any
other general purpose) microprocessor
Since I will probably need to obtain "favors" down the road when I try to get
OpenChrome DRM mainlined, I probably should not go into what I think of how
Intel works on their graphics device driver stack (I do not mean to make this
personal, but Intel is the "other" open source camp in the OSS x86 graphics
world, so I find it a fair game to discuss the approach Intel takes from
semiconductor industry perspective. I am probably going to overly generalize
what is going on, so if you wanted to correct me, let me know.), but based on
my understanding of how Intel works, Intel probably has more staffing resources
than AMD when it comes to graphics device driver stack development. (and on the
x86 microprocessor development side)
Based on my understanding of where Intel stands financially, I feel like Intel
is standing on very thin ice due to the following factors, and I will predict
that they will eventually adopt AMD DC like design concept. (i.e., use of a HAL)
Here is my logic.
1) PC (desktop and laptop) x86 processors are not selling very well, and my
understanding is that since Year 2012 peak, x86 processor shipment is down 30%
as of Year 2016 (I will say around $200 ASP)
2) Intel's margins are being propped up by the unnaturally high data center
marketshare (99% for x86 data center microprocessors) and very high data center
x86 processor ASP (Average Selling Price) of $600 (Up from $500 a few years ago
due to AMD screwing up the Bulldozer microarchitecture. More on this later.)
3) Intel did a significant layoff in April 2016 where they targeted older (read
"expensive"), experienced engineers
4) Like Cisco Systems (notorious for their annual summer time 5,000 layoff),
Intel then turns around and goes in a hiring spree hiring from many graduate
programs of U.S. second and third tier universities, bringing down the overall
experience level of the engineering departments
5) While AMD is financially in a desperate shape, it will likely have one last
chance in Zen microarchitecture to get back into the game (Zen will be the last
chance for AMD, IMO.)
6) Since AMD is now fabless due to divestiture of the fabs in Year 2009
(GLOBALFOUNDRIES), it no longer has the financial burden of having to pay for
the fab, whereas Intel "had to" delay 10 nm process deployment to 2H'17 due to
weak demand of 14 nm process products and low utilization of 14 nm process (Low
utilization delays the amortization of 14 nm process. Intel historically
amortized the given process technology in 2 years. 14 nm is starting to look
like 2.5 to 3 years due to yield issues they encountered in 2014.)
7) Inevitably, the magic of market competition will drag down Intel ASP (both
PC and data center) since Zen microarchitecture is a rather straight forward
x86 microarchitectural implementation (i.e., not too far apart from Skylake),
hence, their low 60% gross margin will be under pressure from AMD starting in
Year 2017.
8) Intel overpaid for Altera (a struggling FPGA vendor where the CEO probably
felt like he had to sell the corporation in order to cover up the Stratix 10
FPGA development screw up of missing the tape out target date by 1.5 years) by
$8 billion, and the next generation process technology is getting ever more
expensive (10 nm, 7 nm, 5 nm, etc.)
9) In order to "please" Wall Street, Intel management will possibly do further
destructive layoffs every year, and if I were to guess, will likely layoff
another 25,000 to 30,000 people over the next 3 to 4 years
10) Intel has already lost the experienced engineers over the past layoffs,
replacing them with far less experienced engineers hired relatively recently
from mostly second and third tier U.S. universities
11) Now, with 25,000 to 30,000 layoff, the management will force the software
engineering side to reorganize, and Intel will be "forced" to come up with ways
to reuse their graphics stack code (i.e., sharing more code between Windows and
Linux)
12) Hence, maybe a few years from now, Intel people will have to do something
similar to AMD DC, in order to improve their design productivity since they no
longer can throw people at the problem (Their tendency to overhire new college
graduates since they are cheaper, and this allowed them to throw people at the
problem relatively cheaply until recently. High x86 ASP also allowed them to do
this as well, and they got too used to this for too long. They will not be able
to do this in the future. In the meantime, their organizational experience
level is coming down due to hiring too many NCGs and laying off too many
experienced people at the same time.)
I am sure there are people who are not happy reading this, but this is my
harsh, honest assessment of what Intel is going through right now, and what
will happen in the future.
I am sure I will be effectively blacklisted from working at Intel for writing
what I just wrote (That's okay since I am not interested in working at Intel.),
but I came to this conclusion based on various people who used to work at Intel
told me and observing the hiring practice of Intel for a number of years.
In particular, one person who worked on Intel 740 project (i.e., the long
forgotten discrete AGP graphics chip from 1998) on the technical side has told
me that Intel is really terrible at IP (Intellectual Property) core reuse, and
Intel frequently redesigns too many portions of their ASICs all the time.
Based on that, I am not too surprised to hear that Intel does Windows and Linux
graphics device driver stack development separately. (That's what I read.)
In other words, Intel is bloated from a staffing point of view. (I do not
necessarily like people to lose jobs, but compared to AMD and NVIDIA, Intel is
really bloated. The same person who worked on the Intel 740 project told me
that Intel employee productivity is much lower than their competitors like AMD
and NVIDIA on a per employee basis, and they have not been able to fix this for
years.)
Despite the constant layoffs, Intel's employee count has not really gone down
for the past few years (it is staying around 100,000 for the past 4 years), but
eventually Intel will have to get rid of people in absolute numbers.
Intel also heavily relies on its "shadow" workforce of interns (from local
universities, especially the foreign master's degree students desperate to pay
off part of their high out of state tuition) and contractors / consultants, so
their "real" employee count is probably closer to 115,000 or 120,000.
I get Intel related contractor / consultant position "unsolicited" e-mails from
recruiters possibly located 12 time zones away from where I reside (please do
not call me a racist for pointing this out since I find this so weird as a U.S.
citizen) almost every weekday (M-F), and I am always surprised at the type of
work Intel wants contractors to work on.
Many of the positions they want people to work are highly specialized stuff (I
saw a graphics device driver contract position recently.), and they have been
like this for several years already.
I no longer bother with Intel anymore based on this since they appear to not
want to commit to proper employment of highly technical people.
Going back to the graphics world, my take is, Intel will have to get used to
doing the same with far fewer people, and they will need to change their
corporate culture of throwing people at the problem very soon since their x86
ASP will be crashing down fairly soon, and AMD will likely never repeat the
Bulldozer microarchitecture screw up again. (Intel got lucky when former IBM
PowerPC architects AMD hired around Year 2005 screwed up the Bulldozer. Speed
Demon design is a disaster in a power constrained post-90 nm process node. They
tried to compensate for Bulldozer's low IPC with high clock frequency. Intel
learned a painful lesson about power with NetBurst microarchitecture between
Year 2003 to 2005. Also, then AMD management seem to have really believed in
the many-core concept too seriously. AMD had to live with the messed up
Bulldozer for 10+ years with disastrous financial results.)
I do understand that what I am writing isn't terribly technical in nature
(it is more like corporate strategy stuff business / marketing side people
worry about), but I feel like what AMD is doing is quite logical. (i.e., using
higher abstraction level for initialization / power management, and code reuse)
Sorry for the off topic assessment of Intel (i.e., hiring practice stuff, x86
stuff), and based on the subsequent messages, it appears that DC can be
rearchitected to satisfy Linux kernel developers, but overall, I feel like
there is a lack of appreciation for the concept of design reuse in this case
even though in ASIC / FPGA design world, this is very normal. (It has been like
this since the mid-'90s when ASIC engineers had to start doing this regularly.)
AMD side people appeared to have been trying to apply this concept to the
device driver side as well.
Considering AMD's meager staffing resources (currently approximately 9,000;
less than 1/10 of Intel although Intel owns many fabs and product lines, so the
actual developer staffing disadvantage is probably more like 1:3 to 1:5 ratio),
I am not too surprised to read that it is trying to improve their productivity
where they can, and combining some portions of Windows and Linux code makes
sense.
I would imagine that NVIDIA is going something like this already. (but closed
source)
Again, I will almost bet that Intel will adopt AMD DC like concept in the next
few years.
Let me know if I was right in a few years.
Regards,
Kevin Brace
The OpenChrome Project maintainer / developer
