1樓：H博士
RTX I/O is here!
但是用的是Windows的DirectStorage介面，加快遊戲素材檔案的讀取和解壓。希望以後能有更廣泛的應用。
2樓：饃饃黑
這個問題感覺以後會火，占個坑。
目前來看ps5的GPU IO解決方案或許就是AMD SSG的低成本加強版，通過硬體CU和軟體API的綜合作用。
具體如何實現的，得看明年的詳細技術分析了。
3樓：採石工
可以試一下:
1) dali (NVIDIA Data Loading Library)[1], 它把資料載入, 解碼, 增強等預處理操作放到 GPU 上.
2) 谷歌最近提出來的 "資料回波" (Data Echoing)[2].
4樓：Charlie憨哦哦
簡要回答一下。
因為題主並沒有說自己的GPU的數量是多少，不同數量的的GPU針對IO瓶頸的策略也側重不同。
如果是在GPU程式設計實踐的話，那應該是PC上接著的GPU，那麼最主要的操作乙個是I/O和計算的並行overlap，這裡看演算法的特點，可以考慮非同步演算法的進一步加持。
還有就是對多層memory的使用和你的演算法match，能夠重複計算獲取的資訊就不用讀寫來耗費時間。
還有就是你的資料能否表示成能佔據稠密連續的記憶體的結構，以避免隨機讀寫，資料本身的特點的影響也很重要。
在談兩點有意思的，可能在HPC規模上的應用更廣，乙個是資料的量化壓縮，這個和低精度計算支援的加速器相關，以及多節點中選取節點作為偽快取的方式在多節點計算中更進一步釋放I/O壓力。
上面都是隨腦子想到的提速點（溜了
但是我說的多也沒有你針對自己的計算做profiling感受到的準確
5樓：陶巴馬
Nvidia最近推出了I/O加速庫， magnum IO， 還未正式發布，https://www.
把I/O與計算並行化可解決部分問題
6樓：譚偉
首先，這個「瓶頸」（暫且這麼稱呼它）因為物理極限而無法解決。目前NVLink （40GB雙向per link）和PCIe （32GB雙向per gen3 16x link），都比GPU內部的記憶體頻寬（300--700GB）要小得多。這個物理極限可能會在下一代硬體得到突破。
其次，這個問題到底是不是「瓶頸」？一次從CPU移入GPU的資料，通常會被重用多次，這使得較慢的移入的代價，仍然是值得的。例如深度學習裡的dense gemm A（m*f）×B(f*n)，矩陣A的每一行要被重用f次--當f很大的時候，緩慢的移入就很值得了。
如果你的應用只把資料讀一次，那麼你要考慮移入GPU是否值得 -- 可能在CPU上做SIMD，而避免傳輸到GPU會有更好的效果。
另外， @謝小龍 提到了，很多時候你可以邊計算邊傳輸下一步計算需要的資料 -- 在深度學習的mini-batch training中這是標準方式，這樣這種「瓶頸」就被隱藏了。
7樓：doonny
注意有乙個前提是，用GPU是要幹計算密集型應用，資料量很大而不怎麼需要計算的事用GPU不合適，用專用晶元更合適，比如有種應用叫萬兆網絡卡。
8樓：Velaciela
不是CUDA的問題，是硬體的問題，受限於PCI-E頻寬。
CUDA這邊的乙個解決辦法如下，不知道題主注意到沒有：
CUDA涉及的主機端儲存主要有分頁記憶體（pageable memory）和鎖頁記憶體（pinned memory）。分頁記憶體使用malloc()和free()分配釋放（通常情況），記憶體頁可能被換出磁碟，無法使用DMA傳輸。而鎖頁記憶體將一直存在於記憶體空間中，支援DMA訪問和與GPU非同步通訊，通過cudaHostAlloc()和cudaFreeHost()分配釋放。
在主機端使用鎖頁記憶體比使用分頁記憶體的PCI-E傳輸速度快一倍左右，效果明顯。
在考慮用GPU加速演算法時，可以先做benchmark，估計整套演算法的訪存時間，再看是不是需要更多的時間來計算。計算時間=訪存時間的話，可以相互掩蓋，計算時間》訪存時間的話，就是受限於計算能力的演算法，更適合用GPU來做（根據演算法數值計算過程不同，不一定都適合，一些演算法還要深度優化才行）。
盡可能跑一套演算法，而不是只簡單計算。資料傳過來以後進行多次運算，再傳出去。
9樓：liu robert
I/O問題一直就是nvidia這樣的discrete GPU的短板，但是AMD的APU那種CPU和GPU共享DRAM的GPU的計算能力又太弱。
首先如果你的資料大量存在磁碟（包括SSD）上，GPU沒有處理磁碟I/O的能力，即使有，SSD的頻寬也遠遠比不上GPU device memory的頻寬。
如果你的資料已經快取在host的DRAM上，需要在host和GPU之間做data transfer，16 lane PCIe 3.0的頻寬可以達到16GB/s，但是也還是遠低於 device memory的頻寬。
可行的解決辦法就是看你的應用input能不能被分成小塊（chunking），如果可以的話，就可以用多個streams來overlap data transfers和compute。或者就是看你的input能不能被什麼解壓速度特別的快的壓縮演算法壓縮，減少data transfer的量，然後在GPU上解壓，用計算換I/O。
機器學習的話，一般training的data set都不是很大吧，主要還是train model的計算量比較大。如果是test的話，我記得有個文章分析過，通過overlap data transfer和compute，即使是普通的硬碟的頻寬（只要》65MB）應該就足夠撐滿K20了。
10樓：Feynman
頂 @叛逆者 的答案。如果IO出現了問題，很大可能是你現在的演算法並不適用GPU加速。
請問現在常用的GPU程式設計架構，如CUDA是否已經解決了這個問題？額，在考慮是否有更好的用法之前還是不要考慮底層架構的事情，除非你有足夠的證據。
你可以嘗試一下下面幾個方法：
1. 是否用滿了GPU的運算能力？
答案可以通過你的資料和GPU計算能力比較得到。
2. 是否IO次數過多？
每次IO都會消耗一定的時間，IO次數越多，消耗時間越多。
3. 演算法中是否包含了過多的if/else等邏輯跳轉？
GPU適用於平行計算，而不適用於邏輯判斷。
11樓：
對於CUDA來說，解決的方法就是shared memory，儘量減少對 global memory部分的訪問，把每乙個block需要的資料一次載入儲存到block內，利用cache，其實IO效能瓶頸的解決無論CPU還是GPU思路是都是接近的就是不斷增加快取，因為離計算單元越遠效能越差，還有合理的控制分配資料的讀寫，前者是硬體架構只要你的環境支援就可以利用，後者就需要你考慮如何你的資料讀寫了，這些都是可以計算出來能夠提公升多少效能的，也是可以利用不同點策略改進的，還是拿CUDA舉例，你可以使用TILE來把要處理的影象或者其他資料來分割開來，每乙個小塊載入他們所需要的資料，這樣他們就可以各幹各的了，不需要大家都跑去global那裡討要資料，畢竟global的頻寬提公升幅度是有限的。
小白學習python遇到瓶頸如何解決？
如果以後不打算從事遊戲方向的，可以跳過pygame，直接去下一步 如果以後打算玩玩遊戲的，還是硬著頭皮往下看吧，或者換個同類的demo去看 我個人建議你，先把這個飛機大戰的小遊戲，乙個字乙個字的，自己碼一遍，不求馬上看懂。在碼字和除錯的過程中，會慢慢明白的 joy 關鍵還是要帶著問題，學以致用！這樣...
高中化學學習遇到瓶頸期如何解決？
如果說，沒有不會的知識點 卻在大題丟分，應該是 解題思維 的問題。可以思考一下平時寫題目的時候，看到題目給出的條件時能不能立刻想到這個條件是做什麼用的，接下來要怎麼寫。看到題目要求的東西時，能不能很快想到要如何去求，要用到什麼東西去求。至於怎樣做 只能說多刷題。同時要知道，刷題不是把題目寫完對個答案...
如何解決Python語言沒有和其他程式語言類似的for語句造成的不方便？
freeman 主要還是習慣問題。傳統C的for大部分都可以轉化為範圍遍歷處理，實在不行還可以用while替代。只是for使用多，產生了習慣依賴，這需要一些時間改變。傳統的C迴圈 for 初始化語句 條件判斷式 遞增語句 迴圈體while 條件 迴圈體 python的for for i in 範圍 ...