DegustatoR
Veteran
I think it does so only in the presence of Windows Hello compatible h/w like a fingerprint scanner.
DirectStorage GPU Decompression, RTX IO, Smart Access Storage
- Thread starter DavidGraham
- Start date
For the record, Bitlocker enforcement (or the attempt) is where the mandate for TPM comes from in Win11.
The out of box experience wizard very well may squash the function due to the lack of MS sign on integration. I'm not sure of its linked to Hello per-se... I'd have to investigate.
The prior point still stands, raw DMA from storage block device to VRAM isn't something you can "just do" with modern file systems.
The out of box experience wizard very well may squash the function due to the lack of MS sign on integration. I'm not sure of its linked to Hello per-se... I'd have to investigate.
The prior point still stands, raw DMA from storage block device to VRAM isn't something you can "just do" with modern file systems.
That diagram is a little misleading. In order to use BypassIO, you start with a standard file handle. Standard file handles are obtained by walking that entire stack, including Partition Magement, Volume Management, the file system, all the filter managers (eg antivirus, for example) and then the IO Manager. Once the handle is obtained, you can then leverage BypassIO to attempt to interact with it. There are a number of reasons why BypassIO can still fail to work, in which case Windows rolls back to using standard file IO for your file handle.
Notice what BypassIO cannot bypass: the filesystem, which is the bulk of the CPU work for transactional access. Gaining the file handle did the work to figure out which physical storage device, partition, and volume we're targeting, which are relatively simple memory page table lookups. The big CPU consumer still exists in the BypassIO chain pictured above: filesystem semantics such as metadata, permissions, compression, multi-user lock controls, and EFS.
BypassIO isn't the big performance driver in the new IO stack. Rather, the huge winner for disk performance is the new IORing, a pretty obvious ripoff of io_uring from Linux parlance. Good for Microsoft for finally ripping off what they couldn't figure out on their own (and I"m one of the regular forum Microsoft apologists...) It's a deeply threaded, asynchronous IO queue system which can group hundreds of thousands of I/Os into a single API submission. This is truly what allows app devs to completely pack the multiple NVMe disk I/O queues completely full, finally taking advantage a hardware capability which never existed in prior disk types.
Notice what BypassIO cannot bypass: the filesystem, which is the bulk of the CPU work for transactional access. Gaining the file handle did the work to figure out which physical storage device, partition, and volume we're targeting, which are relatively simple memory page table lookups. The big CPU consumer still exists in the BypassIO chain pictured above: filesystem semantics such as metadata, permissions, compression, multi-user lock controls, and EFS.
BypassIO isn't the big performance driver in the new IO stack. Rather, the huge winner for disk performance is the new IORing, a pretty obvious ripoff of io_uring from Linux parlance. Good for Microsoft for finally ripping off what they couldn't figure out on their own (and I"m one of the regular forum Microsoft apologists...) It's a deeply threaded, asynchronous IO queue system which can group hundreds of thousands of I/Os into a single API submission. This is truly what allows app devs to completely pack the multiple NVMe disk I/O queues completely full, finally taking advantage a hardware capability which never existed in prior disk types.
Similar threads
