The AMD Execution Thread [2007 - 2017]

Status
Not open for further replies.
I doubt it's really all that big, to be honest. Most companies are happy with VS.
Er, you know you can use ICC in conjunction with VS, right? Any performance-critical stuff on x86 for commercial apps is almost certainly compiled with ICC.
 
Yes, but Microsoft's bread-and-butter business is Software. And to sell the maximum amount of software possible, your software should run on as many platforms as possible.

They have no vested business interest in pushing one CPU hardware provider over another. And in fact, if push came to shove, they'd likely want to have less hardware options to support versus more -- that makes debugging far easier.

So the chances of Microsoft making any sort of wide sweeping change to support (or not support) a major CPU vendor is pretty low at this point. At least IMO...

Except that this is just what they did when they pushed Windows XP 64 bit to AMD X86-64 processors.

One supposes they "could" have gone with Intels IA64 architechture but that would have required more work.

AMD made things easier for Microsoft and thus MS went with their architecture and in the end forcing Intel to adopt the x64 extensions to x86.

I'm sure Intel could have just ignored it in any case, but considering IA64 wasn't making significant penetration except in relatively small niche markets, it faced losing rather large chunks of the server market if it didn't respond.

Does this mean Microsoft can always influence the hardware vendors? No. But it does mean they have significant clout. And it does mean that while they can be slow to move (as are any large corporations) that they can and do adapt to changes that they didn't plan for.

Computer gaming wouldn't be anywhere near the state it's in now for example without Microsoft basically forcing and in turn enforcing a graphics and sound standard to which all hardware vendors MUST adhere.

Which in turn means that software developers can concentrate resources on developing to a relative fixed platform that can still sustain MANY hardware vendors.

Some would paint this as evil and monopolistic. I paint this as the only way and the only reason computing is as commercially successful as it is today.

Anyway, the point here is. That Hardware influences what Microsoft can and does do. BUT, Microsoft also influences what hardware can and does do. It's a symbiotic relationship.

And thus MS can shape to an extent how well AMD does. But isn't stupid enough to rely SOLELY on AMD and ignore Intel.

Regards,
SB
 
Er, you know you can use ICC in conjunction with VS, right? Any performance-critical stuff on x86 for commercial apps is almost certainly compiled with ICC.

Of course. I have ICC. But that doesn't mean I use it all the time or that its performance is even better than MSVC in many cases.
 
Well as I said professional SW, not consumer stuff. Surely VS is everywhere, I use it too.

I guess it depends on your definition of professional. If you mean niche scientific applications, then perhaps. If you are talking about the majority of commerically available software on Windows (including all of Microsoft's software and most PC games), then MSVC rules the roost.
 
Except that this is just what they did when they pushed Windows XP 64 bit to AMD X86-64 processors. <snip>

No, that's an incorrect comparison. There are no IA64 platforms for home desktop usage, so making a version of Windows XP just for the IA64 architecture would be a completely worthless endeavor, as XP is a desktop operating system.

You also seem to forget that XP64 is built on the Server 2003 operating system platform, and Server 2003 also has full support for IA64. Thus, it's would be quite easy for Microsoft to build an IA64 flavor of XP64, but again, why?

There's no choosing of favorites that I can see.
 
No, that's an incorrect comparison. There are no IA64 platforms for home desktop usage, so making a version of Windows XP just for the IA64 architecture would be a completely worthless endeavor, as XP is a desktop operating system.
Well technically there was a version of XP supporting IA64. As of today it is discontinued, though.
 
No, that's an incorrect comparison. There are no IA64 platforms for home desktop usage, so making a version of Windows XP just for the IA64 architecture would be a completely worthless endeavor, as XP is a desktop operating system.

You also seem to forget that XP64 is built on the Server 2003 operating system platform, and Server 2003 also has full support for IA64. Thus, it's would be quite easy for Microsoft to build an IA64 flavor of XP64, but again, why?

There's no choosing of favorites that I can see.

Which is incorrect that it would be easy.

As Microsoft was at the time already laying the groundwork for merging the server and consumer kernel.

This would have been a nightmare supporting both x86 and IA64 for both consumer and server markets. Considering x64 was just an extension to x86 this made MS's job considerably easier than it otherwise would have been.

And in this case AMD was smart, it wasn't a secret that MS wanted to do this. While Intel was dead set on pushing IA64, AMD saw an opportunity to design a 64 bit processor that would be Windows friendly (as well as upgrade migration friendly other OS's and business sectors) and was in turn rewarded by MS for developing the x64 extensions.

With Microsoft firmly behind the x64 extensions, Intel had no choice but to also follow suit. Development of their own 64 bit extension would have been far costlier and taken far longer than just licensing the tech from AMD. AMD of course, seeking access to Intel patents was more than willing to enter into a cross-licensing deal.

Just as MS dropped support for Alpha DEC and PowerPC (was that correct nomenclature of that CPU) from the NT kernel, they were also more than willing to drop IA64 due to difficulty in keeping multiple code paths and continuing development on said paths.

Regards,
SB
 
Oh, you mean like... OpenGL? ;)

And just what is the state of OpenGL now? Hasn't version 3.0 been delayed yet again?

I don't think anyone will argue that OpenGL isn't more flexible than DirectX in that it's an open standard. However, that very fact makes it slow to change and relatively messy.

DirectX took a different approach by trying to standardize and increase the ease of development rather than trying to support EVERYTHING.

While OpenGL (as I understand it) must be ratified by a board, thus meaning there must be compromises, deal brokering, and a consensus before a standard can be ratified...

DirectX talks to IHVs and ISVs, takes recommendations, listens to all parties, then implements that it thinks is best from a software developer's point of view. Change is fast, but relatively inflexible... IE - you get what you get, no if's, and's or but's.

There's a reason that the vast majority of computer games are developed on DX now. While OpenGL has the potential to be far better than DX ever could (in features supported) the very openness means change and adoption is relatively slow for a standard to be implemented. As well that any sweeping changes must be arrived at a consensus which isn't easy to come by.

So, while I'll more than agree that OpenGL kickstarted (Although I think Glide had more of an impact in the early days) 3D gaming. DirectX has been the driving force behind computer gaming (including 3D gaming) the past few years.

IE - Meaning DirectX and thus Microsoft have far more clout in deciding the direction Hardware companies (ATI/Nvidia) go than OpenGL does.

Regards,
SB
 
SB, check your facts on OGL. You're talking total nonsense. OGL was on the level of DX8-9 some 5 years earlier and performed way better. If the IHV's supported it better or made a common spin-off, it would have been THE standard and DX would have died.

Now it doesn't really matter since DX cought on, but the problem is that it's windows-only, thanks to Microsoft. OGL was a perfect candidate for multiplatform development since every OS out there had it in some form.
 
If the IHV's supported it better or made a common spin-off, it would have been THE standard and DX would have died.

If 3DFX hadn't tried to kill off all their 3rd party board manufacturers, they'd still be here. If NVIDIA had never made the FX series, they'd be even bigger. If S3 could've ever made a full-speed part with fully functional drivers, they'd be way into the game too.

I guess what I'm getting at is, if the world was flat, we'd all be dead. There's lots of "ifs", but those don't reflect reality. The reality is that OpenGL had lots of chances, and yet really nobody went down that road from an IHV perspective. We can sit here all day and lob "what if's" at eachother and pander on about how our favorite (insert API, hardware manufacturer, or OS) would be SO much more awesome and would be taking over the world IF ONLY it got support.

IA64 could have been awesome IF Microsoft wrote an OS entirely for it -- maybe. They already had OS support, even for XP as we have now been told, but nobody was using it. Why was nobody using it? Why should MS be expected to maintain a desktop codebase for a piece of hardware that effectively nobody uses in desktops? (Same goes for DEC Alpha and MIPS -- when was the last time you saw a DEC or MIPS desktop?)

OpenGL could have been awesome IF all the IHV's supported it -- maybe. But Windows application developers paid it no mind, especially back in the DX5 days when it was so obviously superior. The IHV's would rather build their own API language (GLIDE, MetAL, et al) than support OGL. There's got to be an obvious reason for this...

I can guess where a few people are pushing the discussion: because MS is evil, right? That's pretty much the party line that a few of you seem to pull into every conversation, so let's just go ahead and get it stated already so we can all begin our inevitable slide to :rolleyes:
 
OpenGL could have been awesome IF all the IHV's supported it -- maybe. But Windows application developers paid it no mind, especially back in the DX5 days when it was so obviously superior. The IHV's would rather build their own API language (GLIDE, MetAL, et al) than support OGL. There's got to be an obvious reason for this...

Actually, the problem wasn't so much the IHVs but developer support for the API. NVidia for the longest time was the best card to use when it came to OGL for games, Matrox, 3dWildcat and 1 other company I believe for professionals. 3DFX was second as Glide was so closely similar to OGL the worked better than on ATI which was a distant third here and everyone else brought up the rear. The problem resulted because back then you had 3 true competing APIs, Glide(3DFX), DX and OGL. Anyone who didn't have a 3DFX card and wanted to play a game writen first in glide can atest to the horrid support those developers gave to DX and OGL. UT anyone? 45 patches before the game would work at all good in DX or OGL? Thats is just one of many games that had issues and needed more than 2 patches to fix major bugs because of the lack developer support. DX games were not much better but bugs were usually fixed within 2-4 patches depending on the severity of the bugs. OGL was great as games that were writen in it, for the most part, simply worked when you played them. A patch might have come out here or there for a game to fix an issue with some IHVs hadware because of the way they rendered things which wasn't normal to everyone else. But for the most part the games simply worked out of the box with little issues. Bear in mind this is all pre 2002.

Since 2002, the IHVs are now down to 2 compteing companies, Nvidia and ATI and OGL has taken a hard hit in the nuts because DX has matured so much while OGL stayed stagnated for so long that devolpers who for the longest time had used it had moved on to DX. It wasn't because DX was all that better to code for and that it could do things OGL couldn't(I'm not a programmer but I'm sure here might be a few things you could do in DX8,9 or 10 that you couldn't in OGL), but because DX had matured and OGL was slow moving and changes to the API seemed to take the act of gods to get them done. Hell, when the big daddy JC, the longest supporter of OGL starts to move his programming from OGL to DX, that got to tell you that even he was tired of the lack of inovation from those in control of OGL body.
 
Heh, why am I not surprised! Very good strategy for all parties involved if it happens though, IMO, so we'll see.

Except perhaps for the government of Saxony, whose officials are the ones who balked in the first place, if this story turns out to be substantiated.

Considering how much of the bill they've footed in the form of loans and subsidies, they probably have issues with AMD flipping said fab over to another company that may not want to abide by some of the terms of AMD's agreement.

The fate of a number of german engineers at Dresden and the future payoff for paying so much to woo AMD's expanded presence may be affected.
 
Considering how much of the bill they've footed in the form of loans and subsidies, they probably have issues with AMD flipping said fab over to another company that may not want to abide by some of the terms of AMD's agreement.
That doesn't seem right to me. AFAIK, AMD would give up these subsidies if they sold the fab to TSMC without the approval of the state.

So chances are, for the deal to happen, TSMC will have to agree to certain conditions and Saxony will be just as happy, because it's another big player entering the region and the number of jobs generated will most likely not be any lower. We'll see, though.
 
That doesn't seem right to me. AFAIK, AMD would give up these subsidies if they sold the fab to TSMC without the approval of the state.

So chances are, for the deal to happen, TSMC will have to agree to certain conditions and Saxony will be just as happy, because it's another big player entering the region and the number of jobs generated will most likely not be any lower. We'll see, though.

The blog post mentioned that officials had balked once, which would be consistent with the possibility that TSMC did not want to abide by the same provisions as AMD.

I'm willing to bet that AMD would also try to keep some of the benefits it accrued from the fab deal even after selling fab 38. It would be a piss-poor company that didn't try.

If there was uncertainty over whether this transfer will lead to reduced employment of German engineers and possibly scaling back on any long-term comittments made by AMD (I don't know German and I know little of the terms, other than the requirement that the Dresden fabs employ a certain amount German engineers), Saxony's interest may be best served to instead block any transfer to increase pressure.

I'm sure the officials want stronger assurances that the void produced by AMD's reduced footprint (or the prospect of a complete pullout down the line, if AMD won't commit to something long-term) is filled by an equal comittment by TSMC.
 
OpenGL could have been awesome IF all the IHV's supported it -- maybe. But Windows application developers paid it no mind, especially back in the DX5 days when it was so obviously superior. The IHV's would rather build their own API language (GLIDE, MetAL, et al) than support OGL. There's got to be an obvious reason for this...
IMO the main reason for slow OpenGL uptake way back when was because most of the IHVs didn't have OpenGL compliant HW. Mainstream 3D chips went through an iterative process, improving features with each new chip. In order to be fully OpenGL compliant, you have to have fallbacks for features you don't support and that usually means software rendering... not exactly ideal for performance.

OpenGL conformance tests aren't too hard to pass and for WHQL you were allowed to fail a certain number of tests and still get a passing score. However, for high-end CAD apps that's not enough.

OpenGL may be too much API for games. There are lots of features that games will never use. Hence, it was easier to create an IHV-specific API that was very light-weight and only exposed features that you supported.
 
Status
Not open for further replies.
Back
Top