Näinkin joskus videon aiheesta, mutta tokkopa enää sitä löydän. Tuo scheduler on myös yksi syy AMD:n korkeampaan virran kulutukseen. Nvidia luopui rautatason schedulerista GTX 480-mallin jälkeen, joka ilmeisesti on melkoinen virtasyöppö myös. Ajuri schedulerilla Nvidia tosiaan lisää prosessorin käyttöä, mikä periaatteessa on siirtänyt hieman virrankäyttöä näyttikseltä preosessorille.
edit: tämä meni ehkä vähän asian vierestä:
Fixed function-rauta tekee saman asian tyypillisesti monta kertaa energiatehokkaammin kuin pieni energiatehokas ohjelmoitava prosessori, ja toisaalta se pieni energiatehokas ohjelmoitava prosessori tekee tyypillisesti saman asian monta kertaa energiatehokkaammin kuin sarjamuotoiseen suorituskykyyn optimoitu CPU
, joten en oikein usko tähän teoriaan.
Ja tarkkaan ottaen, minkä asioiden skeduloinnista tässä teoriassa edes on kyse?
Skedulointia tehdään hyvin monella eri tasolla. (prosessorien käskynskedulointi, work grouppien skedulointi ytimille jne).
Tai no:
Jos tarkastellaan shader-prosessoriydinten käskyskedulointia, niin nVidialla on nykyisin käytössään matalamman tason käskykanta jossa suurempi osa käskynskeduloinnista on kääntäjän vastuulla, GCN:n ollessa melko RISC-tyyppinen käskykannan abstraktiotason suhteen, ja prosessoreissa lienee scoreboarding-mekanismi käskyjen skedulointiin(en ole ihan varma tästä scoreboardingista).
Tällä nVidia tosiaan hiukan säästää virtaa AMDhen nähden noissa shader-prossuissa, mutta: nVidian tarvii käyttää se virta CPUlla vain kerran ohjelman alussa kun ne shader-koodit käännetään, ei jatkuvasti.
Mutta: Shader-prosessorien käskynskeduloinnilla ei ole käytännössä MITÄÄN tekemistä CPU-puolen säikeiden/monisäikeistyksen kanssa.
nVidialla lienee käytännössä maailman paras kääntäjäporukka. Noita matalamman tason käskykantoja (exposed datapath architectures) on tutkittu parikymmentä vuotta ja ne on saatu toimimaan hyvällä suorituskyvyllä joissain melko rajoitetuissa tapauksissa, mutta ne on vaan perinteisesti oleet liian hankalia kääntäjälle, tai siis hyvän kääntäjän tekeminen exposed datapath-arkkitehtuureille on vaan ollut todella vaikeaa, ja ne myös vaativat todella hyvän kääntäjän.
nVidia tuntuu kuitenkin tällaisen kääntäjän tekemisessä onnistuneen, ja lisäksi Denver oli myös aika suuri osoitus nVidian kääntäjäporukan taidoista. Aiemmat yritykset ajaa mitään binäärikäännöksellä VLIWillä(transmeta, uudempien itaniumien x86-tuki) kaatuivat huonoon suorituskykyyn kun kääntäjä ei ollut niin hyvä kuin mitä siltä vaadiittiin
