Das würde ich so nicht schreiben case..
. Man nutzt eher was brach liegt. Letztlich ist rBAR ein GPUMmu (WDDM2) Feature, dass man in Software und Hardware unterstützen kann, es ist optional (daher muss man Nvidia auch keine Schuld geben, wenn es eben nicht so ist) und wenn man es in Hardware unterstützen will erfordert das einige Register mehr. Die werden benötigt, um der Software in Hardware auch mitzuteilen, welche Ressource wo verfügbar ist, wobei die Software dann der größten Ressource zuweisen kann.
Da sich ein paar der Partner für Nvidia aus dem Fenster gelehnt haben (Asus mal wieder vorne weg), sind sie nun in der Bringpflicht obwohl sie diese Register in Hardware wahrscheinlich auf Gamerhardware nicht unterstützen.
rBAR war dazu gedacht bestimmten Impact bei großen Speicherkonfigurationen abzufedern und auf feste Größen von Systemressourcen zu programmieren, wenn Dynamic nicht erforderlich ist weil Poole groß genug sind. Die PCI Sig schrieb aber nie vor es in Hardware unterstützen zu müssen und an deiner Auflistung erkennt man das Kleinvieh auch Mist machen kann.
Natürlich kann Software bei der Ressourcenzuweisung einen Overhead erzeugen, wie das bei Treibern (bzw. den genannten Dienstprogrammen) auch schon erkennbar war. Das Nvidia gerne was an der Hardware vorbei scriptet ist ja auch bekannt. AMD tut sicher nichts anderes, wenn's drauf ankommt. War ja bei den ACE auch schon so.
Da kommunizieren einfach zwei I/O Die direkt, was klar schneller funzt. Nur muss die Software es zulassen, wie man an den APIs (Spiele) gut erkennt, unterstützen es nicht alle gleich gut.
Die ursprünglichen Ideengeber (Sponsoren) waren HP in Zusammenarbeit mit AMD. Nur logisch das sie dann irgendwann damit kommen.