RyZen will get official Windows 7 support

[leadeater]

22 minutes ago, patrickjp93 said:

No they aren't. All the ACPI does is provide a switch to let the OS change from 64-bit mode to 32-bit mode when running 32-bit programs. It's not a driver. Every boot loader out there today just does this in-line at start up to go from 16 to 32 to 64 bit mode. This is hardly a driver in the pure sense of the word.

 

No they aren't. What you've referred to so far are not drivers. They're utility functions. They don't define the interface with the hardware in any way. x86 code will run on ANY x86 processor and later, period, end of story. There is no such thing as a driver for a CPU, and it would make no sense for one to exist. The OS is nothing but x86/64 instructions, and those run natively on the chip already. If there are extra handles for controlling clock speed on a finer grain than the chip's own dynamic clock speed, those still aren't drivers because they don't define any interface with the hardware that is necessary for the OS to function.

 

And you don't get a different driver for a single core machine. You get a different scheduler, because the optimal schedule for a multicore machine is defined by a different algorithm than the greedy one which works for a single-core machine. Just because it's in the form of a dynamically linked library does not mean it's a driver.

Quote

In computing, a device driver (commonly referred to simply as a driver) is a computer program that operates or controls a particular type of device that is attached to a computer.^[1] A driver provides a software interface to hardware devices, enabling operating systems and other computer programs to access hardware functions without needing to know precise details of the hardware being used.

 

The main purpose of device drivers is to provide abstraction by acting as a translator between a hardware device and the applications or operating systems that use it.^[1] Programmers can write the higher-level application code independently of whatever specific hardware the end-user is using.

https://en.wikipedia.org/wiki/Device_driver

 

Please explain to me why you get a literal different driver in Device Manager for all the different hardware configurations I talked about. And that Microsoft themselves says they are a driver, and your OS will not function if you change the backing hardware after install. I'll admit these are edge cases and no relevant now days.

 

And these:

 

 

Spoiler

[Version]
Signature="$WINDOWS NT$"
Class=Processor
ClassGuid={50127DC3-0F36-415e-A6CC-4CB3BE910B65}
Provider=%MSFT%
DriverVer=04/21/2009,10.0.14393.0

[SourceDisksNames]
3426=windows cd

[SourceDisksFiles]
processr.sys    = 3426
intelppm.sys     = 3426
amdk8.sys     = 3426
amdppm.sys    = 3426

[DestinationDirs]
DefaultDestDir = 12

[ControlFlags]
;
; Exclude all devices from Select Device list
;
ExcludeFromSelect = *

[Manufacturer]
%Std%=Std,NTamd64
%Intel%=Intel,NTamd64
%AMD%=AMD,NTamd64

[Std.NTamd64]
%Processor.DeviceDesc% = Processor_Inst,ACPI\Processor

[Intel.NTamd64]
%IntelPPM.DeviceDesc% = IntelPPM_Inst,ACPI\GenuineIntel_-_Intel64

[AMD.NTamd64]
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_4
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_5
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_7
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_8
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_11
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_12
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_14
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_15
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_20
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_21
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_23
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_24
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_27
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_28
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_31
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_36
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_37
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_39
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_40
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_43
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_44
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15_Model_47
%AmdK8.DeviceDesc% = AmdK8_Inst,ACPI\AuthenticAMD_-_AMD64_Family_15
%AmdPPM.DeviceDesc% = AmdPPM_Inst,ACPI\AuthenticAMD_-_AMD64

[Processor_Inst.NT]
Copyfiles = Processor_Copyfiles
AddProperty=WDTFSOCDeviceCategory

[Processor_Inst.NT.Services]
AddService = Processor,%SPSVCINST_ASSOCSERVICE%,Processor_Service_Inst,Processor_EventLog_Inst

[Processor_Copyfiles]
processr.sys,,,0x100 ;COPYFLG_PROTECTED_WINDOWS_DRIVER_FILE

[Processor_Service_Inst]
DisplayName    = %Processor.SvcDesc%
ServiceType    = %SERVICE_KERNEL_DRIVER%
StartType      = %SERVICE_DEMAND_START%
ErrorControl   = %SERVICE_ERROR_NORMAL%
ServiceBinary  = %12%\processr.sys
LoadOrderGroup = Extended Base

[Processor_EventLog_Inst]
AddReg = Processor_EventLog_AddReg

[Processor_EventLog_AddReg]
HKR,,EventMessageFile,0x00020000,"%%SystemRoot%%\System32\IoLogMsg.dll;%%SystemRoot%%\System32\drivers\processr.sys"
HKR,,TypesSupported,0x00010001,7

[IntelPPM_Inst.NT]
Copyfiles = IntelPPM_Copyfiles
AddProperty=WDTFSOCDeviceCategory

[IntelPPM_Inst.NT.Services]
AddService = intelppm,%SPSVCINST_ASSOCSERVICE%,IntelPPM_Service_Inst,IntelPPM_EventLog_Inst

[IntelPPM_Copyfiles]
intelppm.sys,,,0x100 ;COPYFLG_PROTECTED_WINDOWS_DRIVER_FILE

[IntelPPM_Service_Inst]
DisplayName    = %IntelPPM.SvcDesc%
ServiceType    = %SERVICE_KERNEL_DRIVER%
StartType      = %SERVICE_DEMAND_START%
ErrorControl   = %SERVICE_ERROR_NORMAL%
ServiceBinary  = %12%\intelppm.sys
LoadOrderGroup = Extended Base

[IntelPPM_EventLog_Inst]
AddReg = IntelPPM_EventLog_AddReg

[IntelPPM_EventLog_AddReg]
HKR,,EventMessageFile,0x00020000,"%%SystemRoot%%\System32\IoLogMsg.dll;%%SystemRoot%%\System32\drivers\intelppm.sys"
HKR,,TypesSupported,0x00010001,7

[AmdK8_Inst.NT]
Copyfiles = AmdK8_Copyfiles
AddProperty=WDTFSOCDeviceCategory

[AmdK8_Inst.NT.Services]
AddService = AmdK8,%SPSVCINST_ASSOCSERVICE%,AmdK8_Service_Inst,AmdK8_EventLog_Inst

[AmdK8_Copyfiles]
amdk8.sys,,,0x100 ;COPYFLG_PROTECTED_WINDOWS_DRIVER_FILE

[AmdK8_Service_Inst]
DisplayName    = %AmdK8.SvcDesc%
ServiceType    = %SERVICE_KERNEL_DRIVER%
StartType      = %SERVICE_DEMAND_START%
ErrorControl   = %SERVICE_ERROR_NORMAL%
ServiceBinary  = %12%\amdk8.sys
LoadOrderGroup = Extended Base

[AmdK8_EventLog_Inst]
AddReg = AmdK8_EventLog_AddReg

[AmdK8_EventLog_AddReg]
HKR,,EventMessageFile,0x00020000,"%%SystemRoot%%\System32\IoLogMsg.dll;%%SystemRoot%%\System32\drivers\amdk8.sys"
HKR,,TypesSupported,0x00010001,7

[AmdPPM_Inst.NT]
Copyfiles = AmdPPM_Copyfiles
AddProperty=WDTFSOCDeviceCategory

[AmdPPM_Inst.NT.Services]
AddService = AmdPPM,%SPSVCINST_ASSOCSERVICE%,AmdPPM_Service_Inst,AmdPPM_EventLog_Inst

[AmdPPM_Copyfiles]
amdppm.sys,,,0x100 ;COPYFLG_PROTECTED_WINDOWS_DRIVER_FILE

[AmdPPM_Service_Inst]
DisplayName    = %AmdPPM.SvcDesc%
ServiceType    = %SERVICE_KERNEL_DRIVER%
StartType      = %SERVICE_DEMAND_START%
ErrorControl   = %SERVICE_ERROR_NORMAL%
ServiceBinary  = %12%\amdppm.sys
LoadOrderGroup = Extended Base

[AmdPPM_EventLog_Inst]
AddReg = AmdPPM_EventLog_AddReg

[AmdPPM_EventLog_AddReg]
HKR,,EventMessageFile,0x00020000,"%%SystemRoot%%\System32\IoLogMsg.dll;%%SystemRoot%%\System32\drivers\amdppm.sys"
HKR,,TypesSupported,0x00010001,7

[WDTFSOCDeviceCategory]
{5D078032-6378-437B-8DA5-9B32B7CA3FDD},2,7,,2

[strings]
;Localizable Strings
MSFT                  = "Microsoft"
Std                   = "(Standard processor types)"

Processor.SvcDesc     = "Processor Driver"
Processor.DeviceDesc  = "Processor"

Intel                 = "Intel"
IntelPPM.SvcDesc      = "Intel Processor Driver"
IntelPPM.DeviceDesc   = "Intel Processor"

AMD                   = "Advanced Micro Devices"
AmdK8.SvcDesc         = "AMD K8 Processor Driver"
AmdK8.DeviceDesc      = "AMD K8 Processor"
AmdPPM.SvcDesc        = "AMD Processor Driver"
AmdPPM.DeviceDesc     = "AMD Processor"

;Non-Localizable Strings
SPSVCINST_ASSOCSERVICE= 0x00000002
SERVICE_KERNEL_DRIVER = 1
SERVICE_ERROR_NORMAL  = 1
SERVICE_DEMAND_START  = 3

Weird how these are all drivers

[patrickjp93]

11 minutes ago, leadeater said:

https://en.wikipedia.org/wiki/Device_driver

 

Please explain to me why you get a literal different driver in Device Manager for all the different hardware configurations I talked about. And that Microsoft themselves says they are a driver, and your OS will not function if you change the backing hardware after install. I'll admit these are edge cases and no relevant now days.

 

And these:

 

Weird how these are all drivers

They AREN'T! They're just customized schedulers. That they are just tossed under the "drivers" umbrella in Windows itself doesn't mean anything. They don't define the communication interface between the OS and the hardware. Therefore, they're not drivers (taken directly from your link btw).

 

All they are are schedulers or extra utilities for when you can make extra clock boosts or stream flushes with a special switch. Anything that worked on older hardware will work on newer. Intel doesn't break forwards compatibility with x86_64, so seriously, why do you think I need a driver to be able to use, say AVX? Hint hint, I don't. If I write a boot loader that gets a machine up to 64-bit mode I can run any instruction I want that is available on that CPU.

 

There is no such thing as a driver for the CPU, because all it could be is native code to that CPU anyway. Proof by construction.

 

Quote

A driver communicates with the device through the computer bus or communications subsystem to which the hardware connects.

You can't do that to the CPU itself. If you had to at all it would mean no boot loader would even be possible. It would also mean that driver would have to live on the BIOS chip and would be the biggest security vulnerability in modern history.

 

Just use your head!

[dfsdfgfkjsefoiqzemnd]

1 hour ago, Drak3 said:

I wouldn't know, I'm ignoring him from hereon out

Ignoring is only a partial solution, people have a tendency to quote nonsense and those quotes are still shown. 

[leadeater]

51 minutes ago, patrickjp93 said:

They AREN'T! They're just customized schedulers. That they are just tossed under the "drivers" umbrella doesn't mean anything. They don't define the communication interface between the OS and the hardware. Therefore, they're not drivers (taken directly from your link btw).

 

All they are are schedulers or extra utilities for when you can make extra clock boosts or stream flushes with a special switch. Anything that worked on older hardware will work on newer. Intel doesn't break forwards compatibility with x86_64, so seriously, why do you think I need a driver to be able to use, say AVX? Hint hint, I don't. If I write a boot loader that gets a machine up to 64-bit mode I can run any instruction I want that is available on that CPU.

 

There is no such thing as a driver for the CPU, because all it could be is native code to that CPU anyway. Proof by construction.

I don't think you need a driver for that, nor did I mention instruction sets anywhere. Those are drivers and are required to properly talk to your hardware which is why Windows looks at your hardware during install and loads the appropriate ones so your system will work. These provide the proper interfaces to your hardware which is what a driver is for and is what the OS is even calling them.

 

Basic functionality and fully supported full functionality are different, and there are drivers that Windows installs to achieve the second one. These are CPU related drivers, they have a real purpose and your more than welcome to try and remove them and see how your Windows user experience turns out. After Ryzen is released go look at those files again after running Windows Update, they'll be updated.

 

Maybe there's confusion around if you think I'm saying there needs to be a driver to actually execute code on the CPU which I'm not, that wouldn't even work else how is the driver loaded in the first place. But these are drivers, they are called drivers, they are driver files, they are in the driver repo, they tell the OS how to properly interact with the CPU which by the definition of a driver qualifies them as such.

[Drak3]

4 minutes ago, Captain Chaos said:

Ignoring is only a partial solution, people have a tendency to quote nonsense and those quotes are still shown. 

Yes, but reading a reasonable response from someone of a rational mentality (such as Leadeater's) makes me happy. I'm just not in the mood to waste my time, and my system's precious resources to Pat's nonsense.

[patrickjp93]

7 minutes ago, leadeater said:

I don't think you need a driver for that, nor did I mention instruction sets anywhere. Those are drivers and are required to properly talk to your hardware which is why Windows looks at your hardware during install and loads the appropriate ones so your system will work. These provide the proper interfaces to your hardware which is what a driver is for and is what the OS is even calling them.

 

Basic functionality and fully supported full functionality are different, and there are drivers that Windows installs to achieve the second one. These are CPU related drivers, they have a real purpose and your more than welcome to try and remove them and see how your Windows user experience turns out. After Ryzen is released go look at those files again after running Windows Update, they'll be updated.

 

Maybe there's confusion around if you think I'm saying there needs to be a driver to actually execute code on the CPU which I'm not, that wouldn't even work else how is the driver loaded in the first place. But these are drivers, they are called drivers, they are driver files, they are in the driver repo, they tell the OS how to properly interact with the CPU which by the definition of a driver qualifies them as such.

*facepalm*

 

You don't need a driver to tell the OS how to talk to the CPU. Period. A CPU driver is a contradiction. Period.

 

The only things you need drivers for are the busses EXTERNAL to the CPU, and the devices which are on the other sides of those busses.

 

Your OS can function perfectly fine without them (just see Linux where you can actually remove all of these special utilities and nothing bad happens). Now, if you tell the OS that some extra handles are there which it includes in its scheduling and clock controls when they aren't ACTUALLY there, OF COURSE you're gonna crash, but that's not a driver! It's a utility!

 

No, the OS interacts with the CPU out of the box of its own accord. If it didn't no one could even write a boot loader.

[leadeater]

31 minutes ago, patrickjp93 said:

Now, if you tell the OS that some extra handles are there which it includes in its scheduling and clock controls when they aren't ACTUALLY there, OF COURSE you're gonna crash, but that's not a driver! It's a utility!

 

Quote

Under certain circumstances with a Windows XP / 2003 operating system – intelppm.sys and processr.sys can cause a virtual machine running under Virtual PC / Virtual Server to crash (by default this will cause the Windows guest operating system to reboot automatically – but if you have changed this setting you will see a blue screen).  The reason for this crash is because these drivers are attempting to perform an unsupported operation inside of the virtual machine (like upgrading the physical processors microcode, changing power state on the physical processor).

 

In the mean time we have made some subtle changes to the way our hardware exposes the processor in Virtual Server R2 so that in future products these drivers should never get loaded inside of virtual machines.

https://blogs.msdn.microsoft.com/virtual_pc_guy/2005/10/25/problems-with-intelppm-sys-and-processr-sys-under-virtual-pc-virtual-server/

https://www.linkedin.com/in/benjamin-armstrong-38263221

 

If you have an issue with these being called drivers that is a person you can start with to make Microsoft change what they are calling them, until then I'll call them what Microsoft calls them.

[patrickjp93]

17 minutes ago, leadeater said:

 

https://blogs.msdn.microsoft.com/virtual_pc_guy/2005/10/25/problems-with-intelppm-sys-and-processr-sys-under-virtual-pc-virtual-server/

https://www.linkedin.com/in/benjamin-armstrong-38263221

 

If you have an issue with these being called drivers that is a person you can start with to make Microsoft change what they are calling them, until then I'll call them what Microsoft calls them.

Those are memory sandboxing routines which were buggy to begin with. That's actually an emulation layer to let a virtual machine emulate an NT thread team within a the NT thread(s) the VM runs on. It doesn't define any hardware interface, and therefore it's not a driver. Intel's virtualization instructions themselves do all the heavy lifting and work out of the box.

 

It's not a driver. Driver is just a convenient name for the non-tech-savvy.

[leadeater]

37 minutes ago, patrickjp93 said:

Those are memory sandboxing routines which were buggy to begin with. That's actually an emulation layer to let a virtual machine emulate an NT thread team within a the NT thread(s) the VM runs on. It doesn't define any hardware interface, and therefore it's not a driver. Intel's virtualization instructions themselves do all the heavy lifting and work out of the box.

 

It's not a driver. Driver is just a convenient name for the non-tech-savvy.

No they aren't, the change is to not load them when the OS is in a virtual machine. All other times they are loaded. A technet article is not for non tech savvy and that is the program leader for Hyper-V. It's a driver, shall be a driver until Microsoft says it's not a driver.

 

Your computer right now has them loaded, just like mine which I showed in this very thread earlier.

 

The issue shown is also just the OS trying to change the CPU frequency which obviously a VM shouldn't be allowed to do, only the hypervisor/host should do that. By not loading the drivers the OS is no longer able to control that part of the CPU.

 

Virtualization and Windows has moved a long way since XP/Server 2003 but that isn't the point of what is being shown. This shows exactly what can happen if you don't have the proper information on how to talk to your hardware, the CPU in this case and is what this thread is about. AMD will be ensuring that these drivers will be updated so you can expect full and proper support of a Ryzen CPU on Windows 7.

[patrickjp93]

37 minutes ago, leadeater said:

No they aren't, the change is to not load them when the OS is in a virtual machine. All other times they are loaded. A technet article is not for non tech savvy and that is the program leader for Hyper-V. It's a driver, shall be a driver until Microsoft says it's not a driver.

 

Your computer right now has them loaded, just like mine which I showed in this very thread earlier.

 

The issue shown is also just the OS trying to change the CPU frequency which obviously a VM shouldn't be allowed to do, only the hypervisor/host should do that. By not loading the drivers the OS is no longer able to control that part of the CPU.

 

Virtualization and Windows has moved a long way since XP/Server 2003 but that isn't the point of what is being shown. This shows exactly what can happen if you don't have the proper information on how to talk to your hardware, the CPU in this case and is what this thread is about. AMD will be ensuring that these drivers will be updated so you can expect full and proper support of a Ryzen CPU on Windows 7.

Again, it's not a driver. It's a utility.

 

And you can guarantee the same for Kaby Lake (apart from the iGPU), because there is no difference between it and Skylake other than even more finely tuned CPU boost. Everything else will work just fine, so it's a moot point!

[MageTank]

4 minutes ago, patrickjp93 said:

Again, it's not a driver. It's a utility.

 

And you can guarantee the same for Kaby Lake (apart from the iGPU), because there is no difference between it and Skylake other than even more finely tuned CPU boost. Everything else will work just fine, so it's a moot point!

So... no IPC boost, right? Just want to make sure that horse is extra dead while I am here. 

[Space Reptile]

1 hour ago, leadeater said:

If you have an issue with these being called drivers

he only has an issue w/ being proven wrong 

[patrickjp93]

14 minutes ago, MageTank said:

So... no IPC boost, right? Just want to make sure that horse is extra dead while I am here. 

Eyeroll* No instruction set changes. The AVX/2 uplift has been proven both by Agner Fog and by Linpack results.

7 minutes ago, Space Reptile said:

he only has an issue w/ being proven wrong 

Nope, but he hasn't proven jack crap. I'm happy to be proven wrong. I learn that way. The problem is you're assuming I'm wrong instead of actually looking at the arguments. I provided a proof by contradiction and proof by construction. Just because a piece of software is labeled as a driver does not make it a driver, even if Microsoft does the labeling. Believing otherwise is called an appeal to authority fallacy.

[Space Reptile]

1 minute ago, patrickjp93 said:

I provided a proof by contradiction and proof by construction.

so it was a delidded sandy xeon? 

[patrickjp93]

1 minute ago, Space Reptile said:

so it was a delidded sandy xeon? 

Yes.

[leadeater]

4 minutes ago, patrickjp93 said:

Just because a piece of software is labeled as a driver does not make it a driver, even if Microsoft does the labeling. Believing otherwise is called an appeal to authority fallacy

Quote

A driver provides a software interface to hardware devices, enabling operating systems and other computer programs to access hardware functions without needing to know precise details of the hardware being used

So without the utility it cannot control a hardware feature of the CPU, hmm sounds a heck of a lot like a driver. You know some hardware can function without drivers with limited functionality right?

 

Microsoft has much more right to decide what they define as a driver for Windows than you do.

[patrickjp93]

55 minutes ago, leadeater said:

So without the utility it cannot control a hardware feature of the CPU, hmm sounds a heck of a lot like a driver. You know some hardware can function without drivers with limited functionality right?

 

Microsoft has much more right to decide what they define as a driver for Windows than you do.

Of course, but to say Ryzen has full support is meaningless. So does Skylake, and so does Kaby Lake. Just drop in the configs from Skylake and you'll get all the same functionality but with a faster chip.

 

Of course, but that doesn't change the fact it flies in the face of the definition.

 

What these functions do is describe exactly how to interface with the hardware. They're utilities, not drivers. There is no abstraction.

[leadeater]

8 hours ago, patrickjp93 said:

What these functions do is describe exactly how to interface with the hardware. They're utilities, not drivers. There is no abstraction.

Quote

The main purpose of device drivers is to provide abstraction by acting as a translator between a hardware device and the applications or operating systems that use it

These drivers are providing the abstraction between the hardware features and the OS. It's not abstracting the entire CPU that is impossible. Without these drivers the OS could not change the P states of the CPU and it doesn't directly know how, that is what the drivers are for.

 

These meet every single definition of a driver, all your stuck on is not realizing that you don't have to abstract the entire hardware.

 

If this isn't true then my GPU displaying video during boot up is witchcraft and shouldn't be possible, how dear my screen show picture in the bios and before OS boot. Oh wait that's right GPUs don't need drivers and your installing utilities in Windows, maybe Nvidia and AMD should change the names of those too?

[Drak3]

54 minutes ago, MageTank said:

So... no IPC boost, right? Just want to make sure that horse is extra dead while I am here. 

No IPC boost, no optane, no 4K 10bit HVEC codec support, and no reworking under the hood that seems to give Kaby better OC ability (has the extent of stability on Kaby even been tested that well?) or slightly better power efficiency, all according to Pat. It's just Sky with a better iGPU and Turbo Boost 2.0.1.

 

/s

[patrickjp93]

1 hour ago, leadeater said:

These drivers are providing the abstraction between the hardware features and the OS. It's not abstracting the entire CPU that is impossible. Without these drivers the OS could not change the C states of the CPU and it doesn't directly know how, that is what the drivers are for.

 

These meet every single definition of a driver, all your stuck on is not realizing that you don't have to abstract the entire hardware.

 

If this isn't true then my GPU displaying video during boot up is witchcraft and shouldn't be possible, how dear my screen show picture in the bios and before OS boot. Oh wait that's right GPUs don't need drivers and your installing utilities in Windows, maybe Nvidia and AMD should change the names of those too?

Except they provide no abstraction in this case. They're just in-line functions that directly talk to the hardware. They're not their own system the way a GPU or USB driver is. Also, the OS can know how to change C states. It can be built directly into the kernel and scheduler as it is on Linux. Intel provides documentation on how to do it. You could generate your own program to do this of its own accord just as you can write a boot loader to go from 16 to 32 to 64-bit mode and back. It's not a driver. There's no abstraction. It's just a fixed function that could be directly baked into the OS if Microsoft wasn't so lazy. Code multiversioning exists after all. Linux doesn't require any of this because it's all baked directly into it and just has a dispatcher based on the architecture generation. Otherwise the communication never goes through any abstraction at all.

 

GPUs all have a basic command set any OS can use to display things, but those things are never very complex. I wonder why...

 

No, as Nvidia and AMD's drivers meet the definition. These CPU utilities don't. They're not abstraction layers at all.

1 hour ago, Drak3 said:

No IPC boost, no optane, no 4K 10bit HVEC codec support, and no reworking under the hood that seems to give Kaby better OC ability (has the extent of stability on Kaby even been tested that well?) or slightly better power efficiency, all according to Pat. It's just Sky with a better iGPU and Turbo Boost 2.0.1.

 

/s

The 4K 10-bit HEVC is all in the iGPU. Also the reworking under the hood is purely a change in process allowing for higher clocks due to more robust FETs as Intel has already stated.

 

As for the new clock boost, that is the only new feature on Kaby Lake wrt the CPU side of things.

[leadeater]

10 minutes ago, patrickjp93 said:

They're just in-line functions that directly talk to the hardware

Correct that is what a driver is for, talking directly to the hardware.

 

11 minutes ago, patrickjp93 said:

Except they provide no abstraction in this case.

The driver is changing the CPU power states on behalf of the OS, therefore abstraction.

 

Sorry but no, you have provided no evidence that these are not drivers. They are driver files, they show in device manager, Microsoft calls them drivers, they are required for the OS to use a hardware feature and the OS itself does not change the power state.

 

Just because something is small and not complex doesn't change what it is.

 

If nothing was required AMD wouldn't need to say that they will provide official support for Window 7, it'll be a redundant statement. That's enough of this conversation, just check those driver files after Ryzen is launched and they will be updated ensuring full and complete support which otherwise would not be the case.

 

P.S. I know you still don't believe it and I the reverse, there is little point replying to this. A debate doesn't have to end with one party accepting the others argument, happens a lot. But when it is clear this is the case it's time to end it and move on.

[patrickjp93]

19 minutes ago, leadeater said:

Correct that is what a driver is for, talking directly to the hardware.

 

The driver is changing the CPU power states on behalf of the OS, therefore abstraction.

 

Sorry but no, you have provided no evidence that these are not drivers. They are driver files, they show in device manager, Microsoft calls them drivers, they are required for the OS to use a hardware feature and the OS itself does not change the power state.

 

Just because something is small and not complex doesn't change what it is.

 

If nothing was required AMD wouldn't need to say that they will provide official support for Window 7, it'll be a redundant statement. That's enough of this conversation, just check those driver files after Ryzen is launched and they will be updated ensuring full and complete support which otherwise would not be the case.

 

P.S. I know you still don't believe it and I the reverse, there is little point replying to this. A debate doesn't have to end with one party accepting the others argument, happens a lot. But when it is clear this is the case it's time to end it and move on.

No, a driver is its own runtime. See your USB or GPU drivers for that.

 

Except it doesn't do it on behalf of the OS. It's part of the OS. By your definition any function called in a program is a driver, and that's ludicrous. The OS might be built to be modular, but that doesn't make every tiny utility a driver, sorry. It does not fit the definition.

 

A DLL is not a driver file. It's just a programming library called at runtime which isn't injected directly into your program. Now, a DLL may very well contain all the functionality to be used as a driver. Nvidia's and AMD's drivers are generally made this way, but they don't have to be.

 

No, AMD would still say it to drum up business and appear more consumer-friendly than Intel, which is fair play, but it's meaningless and frankly deceptive.

[leadeater]

7 minutes ago, patrickjp93 said:

A DLL is not a driver file. It's just a programming library called at runtime which isn't injected directly into your program. Now, a DLL may very well contain all the functionality to be used as a driver. Nvidia's and AMD's drivers are generally made this way, but they don't have to be.

 

Where is the dll, I don't see any? These are driver files.

[Delicieuxz]

12 minutes ago, patrickjp93 said:

Except it doesn't do it on behalf of the OS. It's part of the OS. By your definition any function called in a program is a driver, and that's ludicrous.

While reading this and the previous page, that was the argument that came to my mind: If a driver is any medium of code that conveys operational information between parts, then, essentially, everything would be a driver.

 

I can see both sides of this, and I think that one expression is casual and convenient, while one is more technical and specific in what it indicates.

[patrickjp93]

8 minutes ago, leadeater said:

 

Where is the dll, I don't see any? These are driver files.

All they are are dynamically linked libraries, file extension/suffix aside. They can't be executed on their own and don't have their own runtime. You can verify this with a simple binary analyzer.