PC:n komponentit ovat päivittäin enemmän yhteydessä toisiinsa, mikä on epäilemättä etu, koska niitä ei ole eristetty ja latenssi katoaa. Mutta kun puhumme prosessori ja GPU, epäilys herää aina, kun tarkastellaan pelien suorituskykyä. Voiko a suoritin käytä GPU:ta VRAM omaksi hyödykseen? Saako suorituskykyä tällaisessa tapauksessa vai menetätkö sen? Katsotaanpa.
No, se on todella kiistelty aihe, koska on olemassa monia vääriä myyttejä siitä, mitä prosessori voi tehdä tai ei ja miten se voi tehdä sen näytönohjaimen VRAM-muistilla. Yritämme selvittää myytit lopullisesti, jotta ymmärrämme molempien rajat.
Prosessori ja VRAM, rakkaus/viha-suhde?
Ensimmäinen asia, joka meidän on tehtävä selväksi, ovat sellaiset ehdot kuin pääsy ja koulutus. Suorittimella on hyvin rajoitettu pääsy VRAM-muistiin, yksinkertaisesti paljon muistia ja sijainteja sellaisenaan määrittämään, mutta tämän käyttökonseptin sisällä on tarpeen pätevöityä hieman.
Prosessoria ja sen PCIe-ohjainta sekä VRAM-muistia ei ole kytketty suoraan, kuten GPU:n tapauksessa. Sinun on käytettävä PCIe-väylää GPU-ohjaimen, BIOS/Firmwaren kautta, joka puolestaan hoitaa grafiikkasovellusliittymä (tässä tapauksessa DX12) ja sieltä saat rajoitetun pääsyn VRAM:iin, kuten sanomme, lohkoallokoinnin kautta. Ongelma johtuu puskureiden allokoinnista pisteille eli VB:lle, koska ne on päätettävä graafisen API:n toimesta, minne tiedon on mentävä ja miten niitä käytetään.
Tätä varten käytetään vertex- tai VAF-attribuutteja, joita ei yleensä toteuteta hyvin useimmissa peleissä, koska CPU käsittelee GPU:n osoitteet ja tiedot, kulkee välimuistien läpi ja sieltä ne siirtyvät järjestelmä RAM , joka lähettää ohjeet DRAW-tiedostojen lataamisesta PCIe-väylään DDR:stä ja uteliaana sieltä ne menevät GPU-välimuisti .
Tämä säästää edellisen vaiheen, mutta kuten näemme, ohitimme VRAM-muistin kokonaan, joten ohjelmoijat ja Microsoft, kera NVIDIA ja AMD huomasin, että oli olemassa paljon optimaalinen tapa yhdistää VRAM ja CPU.
PCI-SIG ReBar ja VRAM
Kuten varmasti tiedämme, pääsy VRAM:iin tehtiin siihen asti, kunnes kaksi yritystä otettiin käyttöön lohkoissa 256 Mt segmentoitu , mutta näiden piti käydä läpi rakenne, josta olemme aiemmin puhuneet. Hassua on, että se ei ollut välttämätöntä, koska PCI-SIG:llä oli jo ReBar lähtien sen riveissä PCIe 2.0 itse, joten he olivat molemmat jäljessä tästä rajoituksesta.
Muutettava palkki ja Älykäs käyttömuisti poisti ongelman lisäämällä työn kopioimaan tiedot, jotka on määritetty a aliydin , eli prosessoriketjuun (yleensä se on rinnakkaistavissa, mutta sillä on vaikutusta sen suorituskykyyn).
Siksi polku meni nyt kahteen suuntaan. Yhdessä CPU kirjoittaa tiedot RAM-muistiin välimuistin käsittelyn jälkeen, kun taas toisaalta on kopio, joka lähetetään välimuistin kautta. PCIe VRAM:iin ja sieltä se menee välimuistiin päätyykseen VAF:iin sellaisenaan.
Mitä saamme sillä? Että CPU kirjoittaa suoraan kopion tiedoista VRAM-muistiin ja että sitä käsittelee näytönohjaimen välimuisti, jotta silloin kun se on tarpeen ja katsotaan sopivaksi API:n kautta , tiedot saadaan RAM-muistista , jolle se on määritetty jo ennen puhelua, tekstuurit ladataan VRAM:iin (RAMDisk) ja sieltä ne siirretään GPU:lle välimuistin edellisen työn jälkeen, mikä vähentää kokonaiskäyttöaikaa ja parantaa suorituskykyä yleisesti. sääntö.
Viime kädessä suoritin voi käyttää VRAM-muistia, kyllä, mutta vain lähettää sille kopion työtiedoista joten tämä säästää renderöinti- ja väylän purkamisaikaa sekä turhaa edestakaisin CPU:n ja GPU:n välillä, sillä tietysti kaikki GART- ja DMA-asemien ansiosta.
On myös tehtävä selväksi, että CPU ei "näe" VRAM:ia muistiyksikkönä sellaisenaan. Näet laitteen (GPU) kytketty PCIe-väylään ja määritti muistityypin, niin yksinkertaista. Se on API ja ajuri, jotka ovat vastuussa (laiteohjelmiston latauksen jälkeen) työskentelystä suuntaan tai toiseen, koska kuten sanomme, kehittäjällä on myös oltava moottori, joka pystyy suorittamaan nämä lataukset ja kopiot. Tämän vuoksi CPU ja VRAM toimivat tavalla tai toisella tavalla tai toisella.
