I doubt that graphics is the primary issue driving the new device driver API. Either portability ( iPad iOS and macOS driver portability ) , shifting to Swift ( or some narrowed C derivative ) language or object bindings, and/or new enhanced security modifications.
For example, there is this recent rumor (
https://www.macrumors.com/2019/04/23/ipad-usb-mouse-support-accessibility-rumor/ ). USB mouse ( and presumably trackpads) added to support in addition to the rest of the USB-C devices added with the iPad Pro adopting that socket type. ( That new driver API could be used to more easily add new devices to the iPad Pro from the base of existing Mac devices. That is at least as likely as some supposed Nvidia only issue. ) .
You can tell from the Nvidia language quoted in the article that is more along the lines of "Apple is stopping us from distributing our driver [ because they won't sign it. ] ' . That is all you need to see there are huge holes in the "Apple alone writes the drivers" issue.
On the Swift front, it will now be a stable binary API. So it would now be a possible candidate for inclusion at the kernel level. Current I/O kit is object oriented. So is Swift. If not Swift then perhaps something with an even more stricter semantics than generic C++ ( a subset of C++ is the foundation for I/O Kit. Apple could be modifying that to an even more strict subset. Perhaps coupled to making it a security model closer to iOS at the driver level. ) . I/O kit was originally composed with GCC in mind. Apple has dumped GCC at this point. The device driver API quite possibly may be catching up with that move at this point.
Security hardening at the kernel level... wouldn't be surprising. Apple has added OS security enhancements for the last several iterations.
