Virtu MVP有別於SLI/CrossFireX架構，捨棄把兩顆GPU（內建與獨立顯示）的效能整合，而是用分工的。

主要是三個概念：
1. 讓iGPU(內建顯示)跟dGPU(獨立顯示卡）同時共存，並將標準畫面成像方式分為兩個主區塊：
(i) 繪圖運算，全部都放在dGPU內執行。
(ii) dGPU運算出來的畫面放在iGPU端進行畫面緩衝。

2. Virtual V-sync：一般使用的螢幕都會訂一個螢幕更新率的上限，超過該上限後，一般的處理方式是會繼續運算，繼續把更新的畫面往螢幕丟。此時就可能會出現畫面撕裂現象。Virtu MVP的作法只是單純在此狀況下，就讓dGPU暫停運算，然後讓iGPU直接把緩衝區的畫面持續傳送到螢幕端，因此可以避免這種情況下的畫面撕裂情形。

3. HyperFormance：一般而言，在進行3D繪圖運算時，多少都會有個最大需求張數的上限，基本上也是以每秒多少張為單位進行計算。超過這個上限就可能會要GPU進行重複運算，也就是說，明明下一張圖跟目前已經運算好的是同一張圖，卻仍需要重新進行運算，因此造成不必要的運算效能浪費，當然，如果剛好來不及算完一張圖，哪怕跟上一張是一模一樣的圖，也會出現畫面撕裂情形。Virtu MVP的作法是在這種情況下，只要目前需要運算的圖跟上一張相同，就會讓dGPU暫停運算，然後讓iGPU直接把緩衝區的畫面持續傳送到螢幕端，直到程式要求運算的圖與上一張不同為止。這樣，就可以讓dGPU的運算能力全部都被用在實際不同的畫面上，減少資源浪費，並可藉此讓運算效能最佳化。

以上是運作原理，以這個邏輯而言，單純計算輸出到螢幕張數的運算效能測試軟體會看到較優的效能是完全合理的，因為很多情況下Virtu MVP會讓dGPU在根本沒進行畫面運算的前提下就把存在iGPU內的暫存畫面輸出到螢幕上了。

但由於Virtu MVP是一個透過攔截DirectX封包進行資源再分配處理純軟體功能，因此會有一些小限制：
1. 在i-Mode，也就是硬體上將螢幕接在內建顯示上時，只要需要進行繪圖運算就必須以軟體的方式將封包傳遞給dGPU，因此在繪圖運算效能上會稍劣於將螢幕接在獨立顯示卡的d-Mode。優點是只要HyperFormance的效益越大，整體效能就會越高。

2. 在d-Mode，也就是硬體上將螢幕接在獨立顯示卡上時，由於已繪製好的畫面都緩衝在iGPU上，所以每次要檢查畫面是否相同，以及輸出畫面前都必須再跟iGPU溝通，以取得畫面，因此在運作的延遲上會較i-Mode都來得高些。優點則是因為dGPU運算效能跟單用獨立顯示是相同的，在HyperFormance效益較小時仍可以將運算效能作到最佳化。

也是因上述原因，才會讓Virtu MVP有別於Virtu，d-Mode並非在所有的使用情境下效能都會優於i-Mode。

從原文的敘述來看，Virtu MVP的確有作到他白皮書內提到的這層運作，所以才會有部份畫面反映速度爆快的情況（因為不需要重新運算），也的確有排除掉畫面撕裂問題（沒畫完的畫面不丟到螢幕上）。換句話說：
1. 如果在i-Mode下透過這層技術帶來的效益大於透過軟體讓獨立顯示進行運算的效能折損，則i-Mode下效能會優於單用獨立顯示。
2. 如果透過這層技術在d-Mode下的效益大過透過軟體去call內建顯示存放的圖造成的延遲的話，則d-Mode效能會優於單用獨立顯示卡。
因此在評測此技術時必須同時測過i-Mode與d-Mode才能下結論。

原文中指出較有問題的是Lucid常犯的兩個問題，分別是：
1. 去擴大宣染自己技術的好處。白皮書中提到，透過此技術可以改善遊戲反應速度，這點老實說跟他們之前在原始Virtu上宣稱的i-Mode可以省電是同樣的情況。
2. 因為這是純軟體功能，效果會因為顯示卡，驅動程式，甚至遊戲特性而有所差異，因此「一定要搭配可支援的顯示卡跟可支援的顯示驅動程式版本，以及應用在可支援的軟體」，否則不排除會有問題。

感覺就只是這樣而已，應該稱為優化，講成作弊是有點過火了。個人是覺得如果有辦法把類似的架構包在同一顆GPU內，甚至包進DirectX指令集的話，應該就會有機會看到明顯的效能提昇了。

另外，這只是一支軟體，不相信他有用，不想用的話，甭灌了就只會以標準DirectX方式運作。