Új hozzászólás Aktív témák

• #27577 Abu85 HÁZIGAZDA

  Új Válasz 2017-05-06 12:47:47 #27577

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  Oké látom ez a skálázás nagyon nem világos. Megpróbálom leírni részletesen.

  Szóval kezdjük azzal, hogy van egy termék skálázás nélkül. Ilyenkor az a helyzet, hogy a terméknek vannak megcélzott piacai, és ezeken a piacokon igen eltérő lehet a hőmérséklet és a páratartalom. Elég csak azt figyelembe venni, hogy Indiában azért vannak olyan hetek amikor 45°C van és a páratartalom is az egekbe szökik. De más egyenlítőhöz közel lévő területen is lehetnek hasonlók a körülmények. Ezzel szemben Európa mondjuk egész kellemes egy kontinensnek számít az itt uralkodó éghajlattal. Amikor tehát egy hardvert paramétereznek, akkor olyan órajelet és feszültséget kell beállítani, amivel Indiában is működni fog. Régen ez pusztán a hardvertervezés direktívái miatt nem volt probléma, mert igen kevés lépcsőre bontotta a futószalagokat egy GPU, tehát eleve alacsonyabb órajelre kényszerültek a gyártók, mint amennyit elméletben be lehetett volna állítani. Egyszerűen el kellett kerülni az órajel-csúszásokat. A pite onnan vált meleggé, amikor az órajel elkezdett felfelé kúszni. A gyártók elkezdték úgy tervezni az architektúrákat, hogy a futószalagokat több részre bontották, és ez a lépcsőzés lehetővé tette, hogy egy órajel alatt kevesebb munkát lehessen végrehajtani, tehát maga az órajelciklus is rövidebb lehetett, ami magasabb órajelet eredményezhetett. Ebből a szempontból az első igazán extrém megoldás a G80 volt, ami abból a szempontból nagyon érdekes volt, hogy nem csak többfokozatú lépcsőzést használt, hanem még a multiprocesszorokon belül is több fokozatra bontotta a feladatot. Ezért volt külön mag és külön shader órajel. Itt már volt egy alapvető skálázás a rendszerben, de turbó még nem, mert eléggé kezdetleges volt az egész. Viszont a G80 más feszültségen üzemelt például Európában és más feszültségen a trópusokon.
  Az egész futószalagokat felbontó koncepció lehetővé tette az órajellel való játékot, mert már képesek voltak a gyártók elérni azt, hogy ostromolják az adott node határait. Ez hozta el a GPU-knál a komolyabb órajel- és feszültségskálázás szükségességét. Az első igazán életképes rendszereknek a Fermi (GeForce 400) és a Terascale 2 (Radeon HD 5000) volt tekinthető. Kezdetlegesek voltak ugyan, teljesen szoftver vezérelte őket, de működtek, és esetenként belenyúltak az órajelbe és a feszültségbe. Ehhez a meghajtóba volt építve egy táblázat, ami alapján a rendszer kiértékelte, hogy kell-e az órajelet csökkenteni vagy nem. Általában nem kellett, főleg az európai éghajlattal, de a lehetőség ott volt a rendszerben. Biztos emlékeztek még a Furmarkra, ami pont a Fermi és a Terascale 2 után vált használhatatlanná a VGA-k megsütése szempontjából, mert ezekben jött először egy életképes skálázó rendszer. Főleg a Terascale 2 volt védve, mert a szoftveres vezérlés mellett a túlterhelés ellen teljesen hardveres megoldása volt, tehát ha a szoftver nem tudott reagálni a körülményekre, akkor a hardver végső pajzsként megtette.
  A DVFS valójában ezután csatlakozott be. Persze bizonyos értelemben a Fermi és a Terascale 2 lapkákat is nevezhetjük DVFS-nek, de a szó legszorosabb értelmében nem szokás, mert szoftverből volt szállítva a táblázat a működéshez, ugye ennek az volt a hátránya, hogy ha elrontottad a szoftvert meg is sültek a termékek, például a Fermi a Starcraft 2 alatt - [link].
  A következő körben már igazi DVFS megoldások jöttek. Ezeknél az volt a lényeg, hogy az egyes külső körülményekhez már a lapkába került egy táblázat, ami alapján a rendszer maga is képes volt beállítani a megfelelő feszültséget és órajelet. Ezzel bejöttek a turbók is, mert reszponzívvá vált az egész, nem kellett a meghajtó jóváhagyására várni. Az AMD a HD 6900 sorozattal tért át erre a modellre, ami az első generációs PowerTune volt. Majd ezt követte a második generációs verzió a HD 7790-nel. Az AMD ezt azért fejlesztette két lépcsőben, mert teljesen át akartak térni hardveres vezérlésre. Ezt valójában a CPU-s mérnökök know-howja alapján rakták össze, de ez lényegtelen. Az NV az első igazi DVFS-t a Keplerben hozta. Ők még félig szoftveres szinten maradtak. Úgymond az órajel vezérlése hardveressé vált, de a védelmi rendszerek még szoftveres választi igényelnek, ahogy az órajelállapotok váltása is igényli a driver engedélyét. De ezektől a különbségektől eltekintve, nagyon lecsupaszítva az a lényeg, hogy a hardvert mindig a legrosszabb körülményre kell tervezni, tehát kvázi a trópusi igénybevételre, ugyanakkor Európában másképp is működhetne. Tehát az elérhető órajel más a trópusokon és más a mediterrán területeken. A DVFS táblázata ezt a különbséget hidalja át. Ezzel az elvi maximum órajelhez relatíve közel lehetett vinni a valós órajelet. Tehát ha mondjuk az elvi maximum ~1500 MHz lenne, akkor egy DVFS-sel valóban beállítható a gyakorlatban is egy ~1200 MHz-es maximum szint a táblázatba. Ha nem lenne DVFS, akkor az órajel pedig úgy ~900 MHz lenne, ami ugye eléggé messze van az elvi maximumtól.
  Az AVFS pedig a következő lépcső ebben az órajelekért folytatott versenyben. Annyiban különbözik ez a rendszer a DVFS-től, hogy nincs egy előre beállított táblázat a lapkában, hanem az indítás során mért hőmérsékleti értékek alapján kalkulál egy saját táblázatott a chip. Ez azért jobb megoldás, mert ilyenkor a skálázást már nem egy legrosszabb körülményekre állított táblázatból valósul meg, hanem a hardver az adott körülményekhez számol egy sajátot. Ilyen formában mondjuk maradva az elvi ~1500 MHz-es maximumnál, a gyakorlatban beállítható maximum órajellel elérhető az ~1350 MHz is. Ennek az AVFS megoldásnak az a nehézsége, hogy jó táblázatott számoljon a hardver, és ez tényleg olyan nehézség, amely látszatra egyszerűnek tűnik, de a valóságban éves szintű tesztelések szükségesek, hogy egy implementációra rá lehessen mondani, hogy ez jó. Persze ismét vannak olyan GPU-s csoportok akiknek tálcán viszik a rendszert a CPU-s mérnökök, amiért az AMD RTG részlegének a dolga valljuk be baromira egyszerűvé válik. Tehát igazából az AMD és az NV megoldása között csak pár CPU-s mérnök áll, semmi más, mert amíg a CPU-s részleg nem vitt semmit a GPU-s részlegnek, addig az AMD és az NV nagyjából hasonló megoldásokat talált ki. Emiatt az NV mérnökei se dolgoznak rosszabbul, mint az AMD mérnökei, csak nekik senki sem vitt oda egy bő évtizedes know-howt a skálázási probléma kezeléséről. Emiatt lehet, hogy az NV egy másik irányt is válaszott az órajel meghatározása szempontjából, és jóval több futószalag fokozatot használnak az architektúrára. Ezzel a futószalagot több részre bontják, mint az AMD, ami magasabb órajel beállítását teszi lehetővé, de egy órajel alatt kevesebb munkát is tudnak elvégezni. A Vega esetében az AMD is növeli egyébként a futószalag fokozatok számát, hogy növelhessék az órajelet, de ezzel ugye nekik is kevesebb munka lesz elvégezhető egy órajel alatt. Az optimális futószalag fokozatok száma egyébként a GPU-knál is olyan kérdéses, mint a CPU-knál. Se a kevés nem jó, se a sok. Tipikusan van egy optimális szám, ami részben architketúrától is függ. Tehát annak kicsi a jelentősége, hogy az AMD kevesebb fokozattal dolgozik, mint az NV, mert ez egy architektúrára vonatkozó döntés is lehet.

  (#27576) s.bala31: Nem. Pont, hogy rosszabb. Például ezért nincsenek kiadva az ultragyáriagyontuningolt VGA-k az egyenlítő közelében, többek között Szingapúrban. De mondjuk Indiában is az van, hogy ezek simán nem működnek. A ~45°C-os nyári melegben le fognak fagyni, és azért pár nap van az évben, ami ilyen ezeken a területeken.

Új hozzászólás Aktív témák