When you say "driver" you mean UEFI right?
No, I mean 'driver' as in 'device driver', as in that piece of software which tells the computer how to properly access a piece of hardware.
I realize it seems weird to think of a CPU as needing a 'device driver', but with modern CPUs that is in fact necessary, due to the varying internal architectures.
While it is obvious to most that an x86 CPU is not the same thing as a PowerPC or ARM CPU, and it is even fairly obvious that an 80286 is not the same thing as a Core i7, it's not necessarily obvious that Intel and AMD CPUs are in fact very different critters despite the fact that they run the same software and execute (mostly) the same instruction set.
The significant differences between the Intel and AMD CPUs (and indeed between e.g. an Intel PIII and an Intel P4) are due to the design tradeoffs made internally in the CPU. These design tradeoffs affect how quickly instructions are executed, to be sure, but (particularly when dealing with multiple CPU cores on the same die) can also impact how efficient it is to schedule a thread on CPU 1 vs. CPU2.
As far as I know, this first started to really become apparent in mainstream operating systems (i.e. Windows) when the first Core Duo chips from Intel became available and people started experimenting with putting multiple chips on a motherboard. Performance would quickly deteriorate because the computer couldn't differentiate between two cores on the same chip and two cores on different chips.
Generally speaking, you try to schedule a thread to run on the same core it ran on previously when dealing with multithreaded applications. You do this because the CPU caches will typically still contain instructions and data from the last execution of the thread and thus you don't end up doing a cache 'flush', which is horribly time-consuming and inefficient. However, you can end up in situations where one CPU core is idle while there is work to do, because the core a thread was scheduled to run on is busy running another thread (the core is already busy).
So now, the scheduler has to make a decision; take the resource hit to move the thread to another core, or wait for the current thread to finish so the waiting thread can run.
But what if you could schedule that thread to run on another core on the SAME CHIP? And what if that core could share things like the cache, making it a much less expensive proposition to move the thread to another core?
That's where the CPU driver comes in; it helps the scheduler make the decision, because it knows about the internals of the CPU, and what things can positively or negatively affect performance.
In the case of the AMD Zen CPUs and the Intel Kaby Lake CPUs, Microsoft have basically said "We aren't supporting these CPUs on anything older than Windows 10. If you want to write a driver for it, any problems are YOURS to deal with." Intel and AMD have both said, "Ah, OK, we'll do it your way". So, no driver for versions before Windows 10.
This absolutely does NOT mean these CPUs won't work on Windows 10 (Hell, you can run Windows NT 4 on a current-generation Skylake processor and it will work just fine, despite the fact that Windows NT 4 doesn't support the CPU). In other words, all this furor of "OMG, Kaby Lake isn't supported on Win 7 or Win 8) is just a bunch of fear mongering from people who should really know better. This isn't anything new, nor is it part of some nefarious plan on the part of Microsoft (well, any more than normal, anyway). Windows 10 has been out now for over a year, and the vast, VAST majority of people who are likely to get anything with a Kaby Lake processor are going to be buying a new machine anyway, which means it will be coming with Windows 10.
You know me, you know I'm a Linux head, and that I pretty passionately hate Windows. I use it every day, under protest, because there some things I HAVE to do for work that I simply CAN'T do under Linux (the software just won't work). That said, this whole uproar is just completely idiotic, IMO.
]
