This happens everywhere, unfortunately. I work for that other x86 CPU vendor that isn't Intel or AMD. Even though there are CPUID feature flags that identify which features a processor implements, many developers determine compatibility from the vendor ID. If we're lucky, we'll be treated as some generic 386 and we'll get to run some horribly unoptimized code [1]. In many cases, the driver, platform, or OS will error out and die [2].

[1] http://arstechnica.com/gadgets/2008/07/atom-nano-review/6/. Scroll down to the third graph, if you want the tl;dr.

[2] http://code.google.com/p/nativeclient/issues/detail?id=2508. I don't post that because it's a particularly egregious example. Even though I don't think the reply makes sense, it's actually more reasonable than most responses. It just happens to be public, because the exchange happened on a public bug tracker.

It's fairly easy to fix this sort of thing with a patch, à la Raymond Chen [3], but, for legal reasons, we can't just hand out patches to every program that incorrectly determines features from the vendor string. It often takes over a year to convince a vendor to issue a patch for its driver or OS, even when we have a benign patch we're using in lab to work around the issue, so we can do compatibility testing (we test pretty much everything) [4]. That's if we're lucky enough to get a vendor that wants to fix it; we often just get the runaround indefinitely. I can recall one case when no printer driver from a certain manufacturer would install on a machine with one of our CPUs, even though that same vendor was selling multiple models that used our CPU.

[3] http://blogs.msdn.com/b/oldnewthing/archive/2012/11/13/10367...

[4] I haven't done lab debug for a while, but the last bug I can recall hearing about was a case where, if you had two webcams recording and playing back to the screen while watching a Blu-ray DVD and running an obscure benchmark from the 90s that wasn't even used in the 90s, the machine would hang approximately once every three days. I don't know where we find the mandmen who come up with these tests.

The funny thing is, we had a feature in our part that we suspected was buggy, and disabling that feature caused the fail to go away (or at least occur incredibly infrequently), but you can't ship a part unless you're really absolutely sure it's not going to hang on real customers, so someone had to track down to the root cause and capture it simulation. Just because disabling that feature meant the bug didn't show up didn't mean that feature was the cause. It could have been that disabling the feature just changed the conditions so that bug became less likely, and only popped up once a year, or maybe needed five webcams to expose, or who knows what? IIRC, it took someone two months to find the exact issue.