Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#29041
üzenetére
Nem igazán. A Volta leginkább egy technikai ugrás lesz. Sok új képességet hoz, illetve aktuálisan elérhető képességeket tesz használhatóvá, amelyeket ma szimplán nem lehet használni, mert nagyon lassúvá válik tőlük a Pascal. A Volta leginkább ezekre reagál. A Kepler-Maxwell váltás nem igazán realitás akkor, amikor technikai problémákat kell leküzdeni. Ettől függetlenül nyilván a Volta sokkal jobb lesz az új képességekben, mint egy Pascal, mert arra lesz tervezve, hogy a modern igények mellett legyen gyors. De a régi programokban nem lesz nagy előnye, mert azok nem használják az új lehetőségeket.
-
#29028
Abu85
HÁZIGAZDA
elfelejtette
#29021
Abu85
HÁZIGAZDA
válasz
elfelejtette
#29021
üzenetére
Attól függ, hogy milyen a ROP, mert ROP és ROP között is lehet nagy különbség.
Az egyébként teljesen normális, hogy a shader:blending arány növekszik. A Microsoft hozza a programozható blendinget és azt nem a ROP-okkal képzeli el egyik gyártó sem. Ergo a programozható blending mellett a ROP-ok feladatát átveszik a multiprocesszorok. Ezek az egységek ilyen környezetben csak ott lesznek a hardverben, de nem csinálnak majd semmit.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#29002
üzenetére
A terveket felesleges nézni. Nem mindegyik memóriát gyártják. Egy csomó minden változott azóta, és a gyártás is az igényekhez igazodott. Például "2 core" HBM2-t senki sem gyárt. Senki sem rendelt eddig. A jövőben persze ez változhat, mert eléggé egyszerű a dolog, elvégre csak konfiguráció kérdése, de akkor is gyártósort kell kialakítani hozzá.
-
#29001
Abu85
HÁZIGAZDA
Petykemano
#29000
Abu85
HÁZIGAZDA
válasz
Petykemano
#29000
üzenetére
A Vega 11-ből biztos lesz 4 GB-os verzió. A Vega 10-ből csak szó volt róla, de újabban sztornóról hallani. Az a gond vele, hogy úgyis ki kell fizetni a legkisebb HBM2 konfigurációt, amivel pedig 8 GB építhető. Ennek a felét letiltani pazarlás.
A következő körben egyébként az AMD 4-16 GB közötti HBC-t fog használni. Az NV a Voltához pedig 16-48 GB-nyi VRAM-ot. Nekik szinte biztos, hogy nem fog működni a PC-s host CPU-kra a GPMP-jük (IBM Power9-re igen), így jóval több memóriára van szükségük.
-
Abu85
HÁZIGAZDA
Eléggé transzparensek ezek a GPMP fícsőrök a fejlesztők nézőpontjából. Nem igazán lehet ezt rendesen vagy rendetlenül beépíteni. Sokszor direkten támogatni sem kell, csak működni úgy fog out of box. Persze a host CPU-nak x86/AMD64-nek kell lennie a Vega esetében. A Voltánál pedig Power9-nek.
-
Abu85
HÁZIGAZDA
válasz
Kolbi_30
#28960
üzenetére
A nem reprezentatív statisztika is statisztika. Csak tudni kell hol kezelni. A következő napokban tele lesz majd azzal a média, hogy az AMD egy negyedév alatt 10,4%-nyit hozott részesedésben az Intelen, mert a PassMark kiadta a saját statisztikáját, ami kvázi hasonló a Steam statisztikájához. De ugyanúgy ez sem reprezentatív. Viszont nyilván statisztika. Amíg leírják, hogy miképp kalkulálják, addig értékelhető az adat, csak nem biztos, hogy lényeges.
-
Abu85
HÁZIGAZDA
Nem a Xeon Phiből van a profit.
Persze előfordul, hogy pár termék nem lesz sikeres, de azért a Xeon Phi annyiban speciális, hogy már az alapprojekt kezdetén megmondták a tervezésben résztvevő mérnökök, hogy ez nem jó irány. Azóta ki lettek rúgva, de a projekt továbbment, és úgy néz ki, hogy igazuk volt a lapátra tett embereknek. A legtöbb cég lelövi a projektet, ha már maguk a tervezők mondják azt, hogy rossz a koncepció. Az Intel ehelyett inkább életképes projekteket és csapatokat kapcsolt le a spórolásban. Persze ez nagyrészt Krzanich hibája, amikor ez vissza fog ütni, akkor ő fog felelni érte. Nagy esélyt adok egyébként arra, hogy egy évtizeden belül Dr. Venkata Renduchintala lesz az Intel CEO-ja. Ő sokat tesz most azért, hogy a Krzanich által kirúgott mérnököket visszahozza a céghez, de a munkájának a gyümölcse leghamarabb 2021-ben fog beérni. -
#28934
Abu85
HÁZIGAZDA
Petykemano
#28930
Abu85
HÁZIGAZDA
válasz
Petykemano
#28930
üzenetére
A Xeon Phi annyira mindegy. Azért vágták felére az árát, mert alig viszik. Valszeg egy generációt él még meg, aztán jön az Intel is egy SIMT-re tervezett hardverrel. A SIMD megközelítés ilyen szinten nem működik. Még ha elméletben jó is, akkor sem érdekli a piacot.
Az Intel döntéseit egyébként ne logika szerint nézd. Náluk az a legfőbb logika, hogy ha valami jobban fáj a konkurensnek, mint nekik, akkor azt az opciót választják. Nem számít, hogy ők is vesztenek rajta, csak az a lényeg, hogy nagyobbat bukik a nem kívánt konkurencia. És ezt a modellt még úgy is csinálják, hogy jogilag teljesen támadható a versenyellenességük. Majd tíz év múlva kapnak érte egy büntit, amit kifizetnek.
-
#28926
Abu85
HÁZIGAZDA
Petykemano
#28925
Abu85
HÁZIGAZDA
válasz
Petykemano
#28925
üzenetére
Szerződés kérdése. Nyilván ki lehet kötni, hogy mit kap és mire használhatja. Inkább az Intel régimódi felfogása a probléma. Ők ma is úgy gondolkodnak, hogy többet ér a pénznél, ha az egyik konkurensüket valahol hátrányba tudják hozni.
-
#28924
Abu85
HÁZIGAZDA
Petykemano
#28922
Abu85
HÁZIGAZDA
válasz
Petykemano
#28922
üzenetére
Power9-cel biztosan. Nem csak működne, hanem működik.
-
#28916
Abu85
HÁZIGAZDA
Petykemano
#28915
Abu85
HÁZIGAZDA
válasz
Petykemano
#28915
üzenetére
Mert úgy működik, hogy a host processzor laptáblájához fér direkten hozzá. Tehát a GPU-ba épített ATS egységeknek kezelniük kell a host processzor memóriamodelljét, hogy a laptáblákat egyáltalán elérhessék. Ehhez pedig szükség van az adott ISA licencére, hiszen a memóriamodell az ISA része.
-
#28914
Abu85
HÁZIGAZDA
Petykemano
#28885
Abu85
HÁZIGAZDA
válasz
Petykemano
#28885
üzenetére
Abban téved, hogy ez nem az igazi Volta lesz. Ez az igazi, persze más dizájnnal, mint a compute verzió, de ez már ilyen szétszedett stratégia volt a Pascal esetében is. Az meg nem az NV-n múlik, hogy a Voltát Voltává tevő fícsőröket nem lehet bekapcsolni. Az Intel azonnal betámadná a hardvert az x86 licenc megsértésére hivatkozva. Nem véletlenül mondta ki a cég, hogy az emulációt nem tekintik jogilag járhatónak. Ez üzenet volt a cégeknek, hogy mindenki be lesz támadva, aki valahogy x86-ot akar. Innentől kezdve a Volta fő újítását nagyon kockázatos bekapcsolni.
-
Abu85
HÁZIGAZDA
Megközelítőleg sem. A szálak mögötti fizikai erőforrás mindig lényegesen kedvezőbb eredményt ad. Az ilyen SMT-szerű megoldások akkor jönnek jól, ha az egyik szál valamire vár, és akkor át lehet válltanai a másik szálra, de ez nem duplázza meg a magok számát. Többek között az ilyen megoldásokat az új konzoloknál ezért hanyagolják. Többet ér a több, de kisebb mag, mint a kevesebb, de nagyobb SMT-s opció.
-
Abu85
HÁZIGAZDA
válasz
#00137984
#28874
üzenetére
A konzolok a köztes generáció alapján teljesen más irányba mennek, mint a PC. Az Xbox One X esetében a Microsoft az extra processzormagok helyett, inkább fixfunkciós blokkokat épített a sűrűn használt feladatokra. Tehát amíg mondjuk a PC-nél sok mag kell a rajzolási parancsok feldolgozásához és beírásához, addig egy Xbox One X-en ez mindegy, nem a procimagokat terheli vele, hanem egy erre kialakított célhardvert. Ez nem csak gyorsabb megoldás, hanem még leveszi a terhet a procimagokról is. Az a helyzet állt elő most, hogy a draw call kezelés szempontjából messze az Xbox One X a legerősebb gép azzal, hogy az MS erre célhardvert épített. Egyébként azt nem tartom kizártnak, hogy a jövőben a PC is erre megy, és akkor a procik képesek lesznek gyorsítani a rajzolási parancsok feldolgozását és beírását, de ehhez kell a megegyezés a gyártók között, és nyilván egy API is, ami ezt kezelni tudja.
-
Abu85
HÁZIGAZDA
Mert még nem próbáltál modern nyolcmagost. Az erős multis terhelésben a négynél több magnak már nagyon sima előnye van. Ezt a tesztek sosem tudják megmutatni, mert senki sem mér multis terhelést. A gyártók viszont igen, és nem véletlen, hogy hozzák le megfizethető szintre legalább a hat magot. Már érezhető a különbség a négy maghoz képest.
Azt nehéz megmondani, hogy ez merre megy tovább. Annyi biztos csak, hogy a DX12 és a Vulkan a több mag-kisebb órajel kombónak fog kedvezni. Valószínűleg a 6-8 magon megint parkolunk egy darabig, viszont ez a parkolás más lesz, mint régen, mert az explicit API-k akkor is skálázódni fognak, tehát aki 10-12-1x magot vásárol kap némi előnyt, annak ellenére, hogy mondjuk 6-8 mag már simán elég lesz egy programnak. -
Abu85
HÁZIGAZDA
A Titan Xp egy úgynevezett prosumer kategóriás termék. Az a Frontier ellenfele, ami szintén a prosumer kategóriába készült. Ezek ilyen félprofi megoldások. Ugyanúgy a Frontiert is meg lehet venni játékra, augusztusban kap hozzá drivert, de legalább annyira nem érdemes, mint a Titan Xp-t, mert sokkal olcsóbban alig más teljesítményű, csak gaming modellt lehet kapni.
-
Abu85
HÁZIGAZDA
válasz
Raggie
#28829
üzenetére
Az Intelen múlik, meg később az AMD-n is, mert kell az AMD64 is, de utóbbi cég odaadja, ha az x86 megvan. Az AMD oldalán a licenceknek csak ára van. Lehet, hogy drága lesz, de ha kifizeti az NV, akkor viheti. Az Intel a probléma, mert nekik még sok pénz mellett sem éri meg az x86-ot osztogatni, pláne nem az NV-nek. De gondolom ezt majd meg fogja vizsgálni az FTC, mert az Intel már befenyítette levélben a cégeket, hogy aki emulálni mer, annak nekimegy. Ebből előbb-utóbb egy általános versenyhatósági vizsgálat lesz.
A hiányát amúgy túl lehet élni, csak az ideálisnál sokkal több memóriát kell pakolni a VGA-kra. Ha nem lesz megegyezés a Voltára, akkor 16-24 GB-os csúcsmodelleket is láthatunk majd, az optimális 8-12 GB helyett.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#28827
üzenetére
Semmi probléma nincs a többiekkel. A Volta is hoz egy rakás packing és cross-line fejlesztést. Ez lesz a következő körben a fontos irány, hogy a shaderek igenis fussanak olyan precizitással, ami sebességben és minőségben kedvező, elvégre ilyenkor kétszer is gyorsabban számolhat ugyanaz a hardver, illetve az LDS bandwith legyen tehermentesítve, mert aránylag sok limit keletkezik itt. Az nem véletlen, hogy a Vega és a Volta is ezekre optimalizál. A többi képesség pedig extra. A Volta esetében ugyanúgy megvan a HBCC alternatívája, csak az NV még nem tudott megegyezni az Intellel az x86 licencről, így egyelőre kénytelenek ezt hanyagolni, különben az Intel felnyomja őket a versenyhatóságoknál. Persze folyamatosan tárgyalhatnak, mert kell nekik is ez a fícsőr, nem akarnak 48-64 GB-nyi memóriát pakolni a next-next-gen hardverekre , aminek a 60-70%-a úgysem lesz használva csak fogyasztani fog.
-
#28826
Abu85
HÁZIGAZDA
Petykemano
#28821
Abu85
HÁZIGAZDA
válasz
Petykemano
#28821
üzenetére
Az MS-t kiemelve, még megjegyeznék annyit, hogy pont az a baj, hogy az MS ezért nem csókol kezet senkinek. Őket ez a két probléma nem érdekli. Amiatt nem, hogy az Xbox az nem PC, tehát egy program teljesen közvetlenül tudja kezelni a memóriáját, és a mono hozzáférési mód lehetővé teszi az egyedi futószalagok kreálását is. A Microsoft tehát ezeket a problémákat pusztán szoftveres szinten abszolút kezelni tudja, innentől kezdve pedig ezek PC-t érintő gondok, majd két-három év múlva kitalálnak rá valamit, ha nagyon veri már az ipar az asztalt. De addig minek ugye. Nem olyan nagy PC-barát az MS, ahogy azt manapság mutatja. Kifelé imádják, de valójában csak az számít, hogy a PC-t és az Xboxot a shader nyelv szempontjából egy szintre helyezzék, hogy ne kelljen a két platformhoz külön kódokat írni. A többi problémát lényegtelennek tekintik, amíg azok csak a PC-t érintik.
-
Abu85
HÁZIGAZDA
A másik nagy probléma a komplex geometria. Itt nem a minél kisebb háromszögekről van szó, hanem arról, hogy a látótér geometriája egyre jobb, és egyre több az átfedés is. Egy rakás háromszög nem fog látszódni a végső képen, de át fog jutni még a raszterizáláson is, ami az erőforrások nagymértékű pazarlása. Erre jó ideje felfigyeltek, de csak hat éve kutatják komolyabban azt, hogy a geometria komplexitásának növelése aránytalanul nagy mértékben növeli a végeredmény tekintetében nem fontos számítások elvégzését. Tehát minél több háromszög van a jelenetben, annál rosszabb a hatásfok. A problémát azonban az okozza, hogy a mai culling megoldásokat nem ezekre a terhelésekre tervezték, így új konstrukciókat kell bevetni. A Vega 10 lesz az első hardver, amely meg tudja majd mondani még az első shader lépcsőn, hogy egy olyan háromszög, amely minden culling szitán átment, végül látszódni fog-e vagy sem, és erre anélkül képes, hogy azt a háromszöget átküldené a raszterizálón. Ez ugye a primitive shader fő előnye, amiért beépítették.
-
#28823
Abu85
HÁZIGAZDA
Petykemano
#28821
Abu85
HÁZIGAZDA
válasz
Petykemano
#28821
üzenetére
Ezek a problémák már léteznek. A legsúlyosabb, hogy ma egy játék a VRAM kapacitásának jó ha a 30-40%-át tölti fel hasznos adattal. A többi szemét. Orbitálisan nagy problémáról van szó, mert emiatt nem lehet szállítani a legjobb elkészült tartalommal egy játékot PC-re. A legtöbb PC-s játék valójában nem 4K-s. Akkor lenne az, ha a textúrák felbontása is illeszkedni a függőleges pixelek számához, de nem illeszkedik. Kisebb szokott lenni, mert ezzel a kisebb felbontással is problémás beleférni a 8 GB-nyi VRAM-ba. De nem azért, mert ez kevés, hanem mert ebből 2-3 GB a valóban hasznosítható tárterület. A Vega 10 az első hardver, ami ezt a problémát megoldja és szállíthatóvá teszi a valóban 4K-hoz igazított tartalmat. Egy 4K-ra tervezett hardvernél az nagyon komoly előny, hiszen hiába 4K-s a felbontásod, ha a textúrák egyszerűen túl picik, hogy jól illeszkedjenek 2160 függőleges pixelhez.
-
#28820
Abu85
HÁZIGAZDA
->Raizen<-
#28819
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#28819
üzenetére
Minek? Egy hónapig csak Pro driver lesz hozzá. A normál, játékokhoz való driver augusztus elején jön.
A legtöbb bejelentésre a SIGGRAPH-ig van az NDA. Tesztelni amúgy lehet.(#28818) rupsz: RX-ből nem lesz előrendelés. Az csak a Frontierre vonatkozik.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#28815
üzenetére
Arra gondoltam, amit írt a teljesítményről. Legalább négy kiemelendő képessége van a Vega 10-nek. Ezek egyébként a HBCC, a primitive shader, az SDWA/packing (AoS és SoA), illetve a cross-lane/DPP fejlesztések. Természetesen vannak már eredmények, és ezeket látva mondhatja az MSI rep. azt, hogy a teljesítményből ítélve a fogyasztás teljesen ok. Ez azonban nem általánosítható. A Vega 10 az elkövetkező időszak problémáinak megoldására készült, míg a korábbi hardverek az elmúlt időszak problémáit oldották meg. Természetes, hogy egy ilyen hardver a közeljövő limitjeit előtérbe helyező szimulációkon széttép/szétgyaláz mindent, mivel a korábbi hardvereket megközelítőleg sem tervezték olyan terhelésre, amit ez az új dizájn elvisel. De például a Volta is hoz packinget, kb. hasonló cross-lane képességeket, és akár még a HBCC alternatívája is jöhet, ha az Intel ad az NV-nek x86 licencet.
-
#28814
Abu85
HÁZIGAZDA
Malibutomi
#28812
Abu85
HÁZIGAZDA
válasz
Malibutomi
#28812
üzenetére
Igazából inkább meg se szólalt volna, mert a meglepiket nem kotyoghatja el, így viszont egy mondatban foglalja össze azt, amiről szerintem hat oldalban is kevés lenne írni.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#28806
üzenetére
Mindkettő ugyanaz, csak az air verzióban 300 a BIOS Max TDP-je, míg a vizesben 375 watt. A gyakorlati fogyasztásuk között egyébként alig van különbség, szóval mindegy, hogy melyiket veszed. A vizes tuningra jobb. De még jobb lesz az RX Vega tuningra, mert az más NYÁK-ot kap. A Frontier NYÁK-ja a WX és az Instinct modellekkel egyezik meg.
-
#28623
Abu85
HÁZIGAZDA
huskydog17
#28620
Abu85
HÁZIGAZDA
válasz
huskydog17
#28620
üzenetére
NVIDIA 16xAF - AMD 16xAF
A teljesítmény preset azért nincs alapértelmezettre rakva, mert lehet, hogy segít a shimmeringen és a más problémás jelenségeken, de a fenti kép mutatja, hogy mit csinál a textúrákkal 16xAF esetén. Ezért használja az AMD a normál presetet alapértelmezetten, aztán ha nem jó, akkor állítsd át.
A helyzet az, hogy valahol mindenképpen kompromisszum lesz. Vagy a textúrák élessége nem lesz megfelelő, vagy a shimmering és a dithering pattern. Az NV szerint fontosabb az utóbbi kettő, így a textúrák élessége beáldozható, míg az AMD szerint az élesség a fontosabb, mert például a dithering patternre ma már van más orvosság, például beépítve a Dirt 4-be is advanced belnding beállítás alatt. Viszont megértik, hogy valakinek fontos a problémás jelenségekre való reakció, így erre is adnak egy beállítást a driverben.Azt mindenki döntse el maga, hogy kinek van igaza, de ez nem fekete-fehér dolog, ahogy azt sokan hiszik.
-
#28619
Abu85
HÁZIGAZDA
huskydog17
#28618
Abu85
HÁZIGAZDA
válasz
huskydog17
#28618
üzenetére
Az súlyos, hogy egy fejlesztő ne ismerje a dithering pattern eljárás mellékhatását. Szóval a helyzet az, hogy ez nem hiba, nem lehet javítani, maximum segíteni rajta, de ez akkor is egy jelenség. Ha nem tetszik ez az eredmény, akkor be van építve a játékban egy alternatív megoldás, ami a dithering pattern helyett OIT-t használ. Ez advanced blending néven fut.
Esetleg használd a Radeon driveren belül a mintázatszűrésnél a teljesítmény opciót, ami ennek a jelenségnek (és a shimmeringnek) a minimalizálására van kialakítva. Az NV-n azért ilyen alapból, mert az alapértelmezett mintavételi szűrésük olyasmi, amilyen az AMD-nél a teljesítmény opció. Az AMD még kínál két extra beállítást más szűrési minőséggel. Ezek élesebb textúrákat eredményeznek, de ennek a mellékhatása, hogy egyre inkább előhozzák shimmering jelenséget és esetleg a dithering pattern eljárást jobban láthatóvá teszik.
Az advanced blending egyébként már elég jó ezeken az újabb GPU-kon, szóval érdemes eleve az OIT-t használni a dithering pattern helyett, és akkor utóbbi hiányában maga a jelenség sem jöhet elő.A jelenség egyébként számos játékban előfordul, amelyik dithering patternre építkezik az átlátszóság kezelése szempontjából. Például ilyen a Witcher 3, vagy a Two Worlds 2, de biztos van több is, csak ezekkel játszottam az utóbbi időben és ezek jutottak az eszembe. Mindegyiknél a "teljesítmény" mintázatszűrést használtam.
-
Abu85
HÁZIGAZDA
Még annyi, hogy olvass nyugodtan utána a dithering patternek. Ez nem hardver vagy driveres dolog, hanem egy rendkívül egyszerű megoldás a transparency/alpha problémára. Az alkalmazásának oka az adott játék leképezője, amely esetlegesen csak egy felületi adatot képes tárolni pixelenként, holott normális átlátszósághoz több kellene. Az EGO ilyen motor. Van benne egy rendkívül egyszerű megoldás az átlátszóságra, ami a dithering pattern alkalmazása, és van az advanced blending opció, ami egy rendkívül bonyolult megoldás, de ez már OIT, tehát nem dithering patteres, így ezt a jelenséget megszünteti, viszont ezt külön kell bekapcsolni a grafikai menüben.
-
#28599
Abu85
HÁZIGAZDA
huskydog17
#28598
Abu85
HÁZIGAZDA
válasz
huskydog17
#28598
üzenetére
De megvan ugyanez a jelenség minden hardveren, csak az NV-nél a driver alapból olyan mintázatszűrést használ, ami elmossa a textúrákat. Olyan mintázatszűrést, amilyen a Radeon Software alapértelmezettje nem tudsz beállítani, mert a WHQL képminőségtesztjéhez igazított szűrési profilt már nem tartalmaz a GeForce driver. Régen tartalmazott, csak a Microsoft ma már nem minősíti a meghajtókat a képminőség alapján, ezért kivették. Az AMD-nél azonban még mindig a Microsoft ajánlásai az alapértelmezettek, és a felhasználó számára a többi profik opcionális. Ha olyan szűrést szeretnél, amilyen az NV-é, akkor kapcsold át a mintázatszűrési profilt a "teljesítmény" opcióra. Műhelytitok, hogy a "magas" opció az Intel szűrési minőségéhez van igazítva.
-
#28597
Abu85
HÁZIGAZDA
huskydog17
#28596
Abu85
HÁZIGAZDA
válasz
huskydog17
#28596
üzenetére
Az nem hiba, hanem a dithering jelenség. Az MSAA segít rajta, de nem tünteti el, esetleg a driverben a mintázatszűrés minőségét kell a normálról vagy a magasról a teljesítmény opcióra rakni, mert az van a dithering minimalizálására kalibrálva. Viszont ilyen formán a textúrák lesznek egy picit mosottabbak. Szóval ez egy vagy-vagy dolog. Az AMD azt csinálja, hogy a user eldöntheti, hogy milyen legyen a mintázatszűrés. Per game alapon érdemes beállítani, mert az egyik játéknak az egyik, míg a másiknak a másik a jó.
Ami egyébként eltünteti a ditheringet az az advanced blending bekapcsolása a játékon belül. Ez egy jóval fejlettebb OIT megoldás. -
#28530
Abu85
HÁZIGAZDA
huskydog17
#28527
Abu85
HÁZIGAZDA
válasz
huskydog17
#28527
üzenetére
Nothing to see here. Nem az OpenGL számít, hanem ahogy használják. Valójában az OpenGL az nem egy, hanem több API, mert nem fogalmaz egyértelműen a szabvány, így az implementációk némileg eltérnek. Amiért az AMD így viselkedik az abból ered, hogy az ilyen free projekteket az NV nem igazán támogatja. Elhajtanak a picsába, mert nem tudnak pénzt lehúzni rólad. Emiatt amikor az optimalizálásra kerül a sor vannak az Intel és az AMD-nek az OpenGL-re vonatkozó ajánlásai azok, amiket lehet követni, mert az NV dokumentációi nem érhetők el publikusan. Na most ha az Intel és az AMD leírásai alapján írják a modifikációt, akkor annak ilyen hatása van az NV OpenGL implementációjára. Tisztán látszik, hogy a skálázódás NV-n nem működik jól. Miért is működne, amikor egy ingyenes modifikáció fejlesztője nem tud hozzáférni az NVIDIA dokumentációihoz, tehát senki sem mondja meg neki, hogy mi a jó a GeForce-nak és az NV OpenGL driverének.
-
Abu85
HÁZIGAZDA
Az a baj, hogy az ilyen kisebb dropok elég sok dologtól lehetnek. Főleg egy olyan API-t használó programban, ahol valós idejű a shader újrafordítás és az allokációk törlése komoly többletterheléssel jár. A hardvernek vagy éppen a drivernek ebbe sok beleszólása nincs. Ha kell az újrafordítás vagy a törlés, akkor jön a drop. Ezért (is) jöttek az explicit API-k.
-
Abu85
HÁZIGAZDA
válasz
nubreed
#28394
üzenetére
Mert ezeket beépíteni elég drága mulatság, kell hozzá pénz, ember és idő. Mellesleg egy ideje az AMD-ben driverében sincsenek benne részletesen beállítható formában, csak ilyen egyszerűsített szinten, de hamarosan visszakerülnek. Már látni, hogy az elkövetkező körben milyen újítások jönnek a meghajtóba és az egyik a kivett szolgáltatások visszaállítása.
-
Abu85
HÁZIGAZDA
válasz
#00137984
#28387
üzenetére
Működik az OpenCL, csak az OpenCL valójában nem igazán egy API, hanem több. A gyártói implementációk annyira eltérnek, hogy az egyes implementációkra tervezett programok nem kompatibilisek a másik implementációval. Alapvetően két opció van OpenCL program szállítására. Az egyik a programot binárisként szállítani, de ilyenkor az új hardverekkel ez a bináris nem lesz kompatibilis. A másik lehetőség a kernelt OpenCL C forrásként szállítani, de akkor meg ott a driver OpenCL fordítója, ami egy csomó galibát okozhat. A harmadik a nyerő verzió vagyis a SPIR-V, de ehhez OpenCL 2.1 kell minimum, amit viszont se az AMD, se az NV nem akar igazán támogatni. A SPIR 1.2 is jó, de azt meg csak az AMD támogatja.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#28385
üzenetére
Pont erről beszélek. Amikor ki tudja az NV gyúrni az OpenCL fordítót egy alkalmazásra, hogy az alkalmazás kódjai jók legyenek, esetleg azokat le is cserélik, akkor jól működik a hardver a bányászás alatt. Mert ez a benchmark sem csinál mást. De amint egy valós alkalmazással találkozik a driver rögtön elhasal a fordítás, és rossz hatékonyságú kódot kap a hardver, amivel persze, hogy nem tud gyors lenni. A probléma emiatt az OpenCL fordító. Kevés erőforrást ölnek bele, míg az AMD-nek erre jóval több erőforrása van. De ha az NV-nek nem kellene egy rakás más problémával küzdenie, mint például a két szabványos explicit API, akkor simán be tudna tolni annyi humánerőforrást az OpenCL-be, amennyit az AMD tud.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#28382
üzenetére
[link] - Láthatod, hogy nincs baj a számítási teljesítménnyel. Az a gond, hogy az AMD-nek az OpenCL fordítója nagyon jól viselkedik általánosan, míg az NV OpenCL fordítója furán dolgozik. Lásd a mi tesztünket, amiben egy benchmark van, tehát arra rá van optimalizálva a driver, de amint egy valós bányászatra való szoftvert kap, rögtön nem ilyen előnyös a sebessége. Egyszerűen a nem profilozott alkalmazásokban nagyon rossz hatékonyságú kódot fordít az NV OpenCL fordítója.
Ezen lehet javítani, ugyanakkor az NV-nek a legkisebb gondja is nagyobb annál, minthogy az OpenCL fordítót rendbe tegyék. Egy rakás olyan munkájuk van a D3D12/Vulkan ICD-nél, és az alatta futó platformabsztrakciós rétegnél, amivel az AMD már egy éve kész van. Tehát az OpenCL fordítót jelen formában le se szarják. Rossz a sebessége, na és? Téged zavar? -
#28381
Abu85
HÁZIGAZDA
ZsiványEgyes
#28380
Abu85
HÁZIGAZDA
válasz
ZsiványEgyes
#28380
üzenetére
Az optional az AMD-nél a WHQL nélküli meghajtót jelenti, míg a hotfix a hotfixet.
Nem az a baj, hogy azonnal reagálnak. Ez így normális. Az a gond, hogy ezeknek nem kellene előfordulnia, mert minden ilyen gubanc csak abból adódik, hogy egymással nem tesztelt komponenseket csomagolnak össze. Nem véletlenül voltak anno az ellen, hogy az AMD havi Catalyst meghajtós stratégiáját alkalmazzák. Most viszont ehhez hasonló modellel dolgoznak és így a kiadott meghajtó egyes részei teszt nélküliek. Konkrétan a user lesz az első, aki teszteli a működést, és ez nem célszerű. Ez a gond csak. De ha nektek így jó...
Egyébként még az AMD (illetve az NV régi) stratégiájával is lehet hiba a meghajtóban. Ez előfordulhat, viszont nem a user az első tesztelő, hanem átmegy a csomag egy belső teszten is előtte. -
#28379
Abu85
HÁZIGAZDA
ZsiványEgyes
#28377
Abu85
HÁZIGAZDA
válasz
ZsiványEgyes
#28377
üzenetére
Nem lényegtelen, mert az AMD-nek is létezik HotFix jelölése. Csak nincs rá szükség, amióta gördülékenyen megy az egész fejlesztés. A Hotfix akkor kell, ha a WHQL-es vagy nem WHQL-es meghajtóban van valami kritikusnak minősített hiba, amire azonnal kell a javítás és nem lehet megvárni vele a később érkező csomagot. Az sem véletlen, hogy mindig ugyanazzal a fejlesztési stratégiával van sok hotfix, lásd havi szintű WHQL Catalyst, vagy szimplán sok WHQL egymás után. Mindig ugyanaz a probléma, összeillesztenek egymással egyáltalán nem tesztelt komponenseket, amelyek olyan hibákat hoznak elő, amiket a komponens különálló tesztelése nem mutatott ki. A következmény egy gyors hotfix, ha lesz olyan mázli, hogy a meghajtót nem kell visszavonni.
-
Abu85
HÁZIGAZDA
válasz
nubreed
#28368
üzenetére
Többféle elnevezés van az AMD-nél. A WHQL egyértelműen a Microsoft általi aláírás. Az Optional az AMD által aláírt tesztelt meghajtó. A HotFix egy aláírt meghajtó egy kritikus hibájára egy gyorsjavítás. A béta pedig az AMD által aláírt, de nem tesztelt meghajtó.
Az NV-nél is ugyanezt jelentik a jelzések, csak náluk nincs optional, mert három branch-csel mindig tudnak WHQL-re küldeni drivert. Az AMD egy branch-et tart fent, így erre ők nem képesek, cserébe viszont nagyon ritka a Hotfix vagy a visszavont driver.
-
#28371
Abu85
HÁZIGAZDA
Petykemano
#28363
Abu85
HÁZIGAZDA
válasz
Petykemano
#28363
üzenetére
0day driver sokféleképpen jöhet.
(#28364) VTom: Megvan a logikája. A havi catalystes időkben az AMD azzal marketingelt, hogy évi 12 WHQL-jük van. Az NV-nek erre mindig az volt a válasza, hogy ahhoz, hogy ezt elérjék több csapatot kell tartaniuk, ami több branch-et eredményez, és ha kiadnak egy WHQL-t, akkor nagy az esélye, hogy egy hét múlva hotfixet kell csinálni hozzá, mert olyan csomagokat raknak össze, amelyeket a kiadás pillanatában nem is teszteltek egymással.
Az a kérdés csak, hogy megéri-e, hogy csupán a WHQL-ért egymással nem tesztelt komponenseket csomagoljanak össze, majd ha hiba van, akkor gyors hotfix, esetleg vissza kell vonni a drivert. VAGY! inkább legyen csak egy branch teljes teszteléssel, de akkor nincs sűrűn WHQL.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#28359
üzenetére
Nem hiszem. Ők is érzik, hogy sok a hotfix. Elemi érdeke a felhasználóknak, hogy erről beszéljenek, mert annál hamarabb vált vissza az NV arra a fejlesztési stratégiára, ami összevonja a fejlesztőcsapatokat és nem lesz több branch a drivernél, ami a hotfixeket szükségessé teszi.
Persze ha jó úgy, hogy a WHQL-ek érkezése után a hotfixre várással viccelődik a hírhez tartozó topik, akkor dobjátok a köveket, ne kíméljetek. 
(#28360) Raggie: Dehogy is. Ugyanannyira jó az NV-nél is a hardver. A bányászat nem bonyolult számítás. Egyszerűen csak sokkal jobb az AMD-nek az OpenCL fordítója. Ennyi a titok. Az NV-nek millió egy fontosabb problémája van az OpenCL fordítónál.
(#28361) Pepeeeee: Majd kiderül.
-
#28358
Abu85
HÁZIGAZDA
->Raizen<-
#28356
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#28356
üzenetére
A driverek terén speciális a helyzet, mert az elmúlt két évben alaposan megváltozott az AMD és az NV driverfejlesztési stratégiája. Az AMD teljesen beállt az egycsapatos modellre, míg az NV fokozatosan egyre több csapatra bontotta a fejlesztőrészleget. Gyakorlatilag az van, hogy az NV azzal a stratégiával dolgozik, amit az AMD alkalmazott a havi Catalyst esetében, míg az AMD azzal, amit az NV alkalmazott még abban az időben, amikor havi szinten jöttek a Catalyst meghajtók. Tehát az, hogy ma az AMD driverek kódminősége számít a követendő példának nagyban köszönhető annak is, hogy az NV driverek kódminősége sokat romlott.
Vicces adalék ehhez, hogy számos NV-s programozó ment az AMD-hez, de közben AMD-s is ment át az NV-hez. Persze ennek a kódminőséghez kevés köze van. Ott inkább a fejlesztési stratégia a döntő. Csak vicces. -
Abu85
HÁZIGAZDA
válasz
TTomax
#28353
üzenetére
Ez tévedés. A bányászatra a Radeon nem a hardver miatt jó, hanem a driver miatt. Az NV is ugyanilyen jó lenne,vagy akár jobb is, ha az OpenCL fordítójuk legalább olyan hatékony lenne, mint az AMD-é.
A deep learning igazából nem nehéz. Az egész 95%-ban mátrixszorzás abban pedig minden GPU jó, főleg a maiak. Tehát egy hardver hatékonysága csak attól függ, hogy tud-e alacsony precizitás mellett is natívan számolni, semmi más nem lényeges. Ha ezen akarnak még javítani, akkor be lehet vetni speciális ALU-kat, amelyek FMA mellett tudnak FMAC-t, és ha még jobb kell, akkor logikai szinten két dimenzióba kell tömbösíteni a feldolgozókat. Utóbbi egyébként biztos nem lesz a Vegában, szóval ebből a szempontból a Volta jobb lesz.
-
Abu85
HÁZIGAZDA
válasz
velizare
#28301
üzenetére
Nem az lesz, mivel akkor eleve 60-61 lenne a határ és a minimum is emelkedett volna. Inkább a CryEngine 4, aminél már van sokkal jobb V-ös verzió is. A 4-est azért nem használják sokat, mert ennek a fejlesztése a pénzszűkés időszakokban volt, és sok hardverre nem is igazán optimalizálták rá. A legnagyobb megrendelő itt az AMD volt a Ruby demóval, és ennek a kiszolgálása volt a cég. Tehát inkább érdemes az V-ös verzióra ugrani, mert az egy sokkal jobb CryEngine változat, sokkal jobban skálázódik.
-
Abu85
HÁZIGAZDA
válasz
atok666
#28285
üzenetére
Mert úgy fogod fel az egészet, hogy a grafika sosem fog fejlődni az aktuális szintről. Most már maradunk itt, és nem lesznek többen a jelenetben, nem lesz a látótávolság nagyobb, nem lesz több shadow casting fényforrás, nem lesznek részletesebbek a modellek, stb. De ez téves álláspont. Amint eldobják a motorok a legacy API-kat és azokat a leképezőket, amelyeket igazából a legacy API-k kényszerítenek ki, egy elég nagy ugrásnak lehetünk majd szemtanúi. Ez már nincs messze, hiszen láttunk már next-gen leképezőt lásd object space rendering. De vannak még fejlesztések, például a Frostbite-hoz készülő tiled light tree renderer. Ezek egészen komoly előrelépést kínálnak a mostani tipikus mozaikos vagy jobb esetben klaszteres leképezőkhöz képest. Az egyetlen hátrányuk, hogy kétpofára zabálják a rajzolási parancsot. De ez sem a konzolokon, se a PC-n nem gond, amióta az explicit API létezik. Szóval végre lépkedhetünk tovább. Vannak még egyébként érdekes kutatások, mint például a LABS (az Eidos Montreal R&D részlege) deferred+ koncepciója, tehát nehéz lenne egy domináns irányt kijelölni, de az látszik, hogy az aktuálisan tipikus leképezőkről lépünk tovább.
-
Abu85
HÁZIGAZDA
válasz
atok666
#28281
üzenetére
Játékok alatt nem, mert azok messze nem csak rajzolási parancsból állnak, és itt csak a parancs beírása van mérve, miközben azért van más munka is bőven. Viszont a 3DMark API Overhead tesztjében érezhető az ebből eredő gyakorlati gyorsulás. Az direkt erre a problémára lett kialakítva, és mivel nem játék, így olyan mértékű rajzolást is beledobtak, amivel egy mai játék még nem dolgozik. De ez egyébként valós szám, bár az igaz, hogy inkább egy megközelítőleges átlag, mivel nem minden rajzolási parancs egyforma.
A PC-ről most elmondható, hogy túl van a fejlesztési szakaszon. Tehát a megkezdett munkát az év végére befejezik, és igazából szinte minden le lesz másolva a konzolokról. Ez persze nem jelenti azt, hogy nem marad probléma, de azokat már úgy kell megoldani, hogy a konzolos megoldásokat nem lehet áthozni, mert azok nem használnak akkor, ha sok konfigurációval lehet számolni. De ha valami áthozható volt PC-re az aktuális hardverekre, és a konfiguráció sokszínűsége sem akadály, azt lényegében áthoztuk. Ezzel a résszel kész, illetve az év végére kész lesz az ipar/Microsoft. Nem sokkal később a Khronos is. Sok szempontból most sínen van a PC.
-
Abu85
HÁZIGAZDA
válasz
#20844032
#28275
üzenetére
A konzolok addig voltak behozhatatlan előnyben, amíg nem voltak itt az explicit API-k. Amióta ezek itt vannak, egy rajzolási parancs beírása a parancspufferbe egymilliószor gyorsabb lett, tehát az az előny, amit a konzolnak biztosítottak az alacsonyabb szintű hozzáférések tulajdonképpen elszállt. De amikor bejelentették a konzolokat, akkor senki sem beszélt explicit API-król. Legkorábban az AMD hozta fel a témát a konzolok megjelenésének évében, de csak ősszel, vagyis jóval a bemutatók után. Akkor már lehetett sejteni, hogy jó lesz ez, mert a PC-s gyártók is látják a problémát és nagyon sürgősen dolgoznak ellene. A többi probléma kezelhető, mert alapvetően csak programozástechnikai. Jobban programozható a konzol? Igen, de mindegy, mert shader modell 6.0-t bármikor kaphat a PC, ahogy a Creators Update-ben már van is egy publikusan tesztelhető implementáció rá. Ezt véglegesítik és a PC ezt a hátrányát is behozza, és onnantól PC-specifikus shaderek sem kellenek a játékokba, vagyis már úgy jöhet a port, hogy a konzolhoz írt, alapvetően optimalizált shadert másolják PC-re. Ergo átjön az optimalizálás is. A shader modell 6.1 is jön igen hamar és az lehetővé teszi azoknak az eljárásoknak a portolását, amit például az Ubi használ a PS4 és X1 játékaihoz (HRAA).
A WDDM 2.x képességei sincsenek túl messze a konzoloktól, tehát ezekhez is hozzá lehet nyúlni, ha az adott port igényelné. Nem egy az egyben ugyanaz a rendszer, de nem megoldhatatlan az egyes technikák portolása. Persze Windows 10 kell hozzá minimum, de működni fog.
-
Abu85
HÁZIGAZDA
Nem kizárólag azért kapott, de a Softbank számára igen kellemetlen a Qualcomm-NXP felvásárlás. Elég csak arra gondolni, hogy milyen jónak tűnt az okostelefonok piaca. Az NV hozta a tök versenyképes Tegrákat, és mindenki vette a Qualcommot. Hasonlóan az Intel ölte a milliárdokat ebbe a piacra, aztán az új CEO mondta, hogy elég és lelőtt minden projektet. Szóval a tervek tök jók, csak egy olyan piacról van szó, amit magasan az NXP ural, és őket most akarja felvásárolni a Qualcomm, amely cégnek alapvető stratégiája az értékesítési csatornák kézben tartása és így a veszélyes konkurensek kiűzése vagy kivéreztetése. Tehát ha a Softbank szeretné, hogy ezen a piacon verseny legyen, ami elemi érdeke, hiszen többen fognak licencelni tőle, akkor muszáj beszállnia tőkével, mert a Qualcomm-NXP felvásárlással olyan óriás születik, ami ellen az NV (vagy az Intel) egymaga nehezen fog megküzdeni. Még az Intel igen, és emiatt nem is érdekesek, de az NV-t ugyanúgy ki akarják majd szorítani.
Értsd ezt úgy, hogy mindent tudni fog a Qualcomm-NXP páros, amit az NV (vagy az Intel), tehát miért is akarnák az NXP-vel való viszonyt megtörni a partnerek? Ugyanaz áll elő, mint a Tegránál. Jó-jó, de tudja a Qualcomm is, miért is kellene Tegrát venni. Ellenben nyilván, ha van kellő akarat és kellő tőke, akkor mindenki legyőzhető. A Softbank sem a Qualcomm-NXP párosnak, mint partnerüknek akar rosszat, csak magának akar jót. Most invesztálnak ide azért, hogy a jövőben a verseny megmaradjon, és ezt a beinvesztált pénzt 10-20 éves távon simán vissza visszakapják a licencekből. Ez most a logikus lépés. -
Abu85
HÁZIGAZDA
válasz
#20844032
#28265
üzenetére
Azóta a PC kapott már három explicit API-t is, ebből kettő szabványos, szóval legnagyobb problémákat leküzdöttük. Persze van még lemaradás, de ezekre is jön megoldás idén. A Microsoft már publikus szinten teszteli a Creators frissítésben, ősszel be is vetik.
Szerintem a Scorpio célhardvereit is szabványosítani lehet majd. Nincs igazából akadálya. Valószínűleg ez most egy aktív téma lehet, hiszen már dolgozniuk kell a következő DirectX verzión.
-
#28264
Abu85
HÁZIGAZDA
->Raizen<-
#28263
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#28263
üzenetére
A program szempontjából a szál és a mag között nincs különbség. Gyakorlatilag a szál a lényeg az alkalmazásnak. De azt figyelembe kell venni, hogy miképpen működik a program. Ha a játékokra gondolsz, akkor a legtöbb új motor simán job rendszerű lesz, tehát a terheléstől függ, hogy valós erőforrásban kér legalább nyolc szálat, vagy jó lesz esetleg a kevesebb valós erőforrás is a szálak mögött. 6 valós maggal egyébként simán el lehet majd lenni, de azt nem tudom, hogy például a kávétó belemegy-e a Z170-es lapokba. Elvileg nincs akadálya, de a gyártók számára inkább az a jó, ha a 200-as sorozat a minimum igény, és ezt mérlegelnie kell az Intelnek is, amikor az alaplapok eladása esik.
-
#28262
Abu85
HÁZIGAZDA
->Raizen<-
#28256
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#28256
üzenetére
Egészen messzire lehet skálázni a játékot főleg az Xbox Scorpio miatt. Ott ugye konkrétan célhardver felel a rajzolási parancsokért, tehát olyan erő lesz benne, amivel nagyon sok maggal lehet csak tartani a lépést, mert PC-ben ilyen célhardver nincs és valószínűleg nem is lesz egy darabig. Szóval a PC szintjén az lesz a legfőbb procizabáló, hogy marha sok lesz a rajzolási parancs, mert az API már nem jelent korlátot, és igazából a Scorpio sem. A látótávolság pedig széles skálán állítható. Egyébként nem hiszem, hogy a 18 mag kelleni fog. A következő körben leginkább 6-8 mag lesz az igény. A 12 mag valószínűleg kihasználható lesz, de hogy nem lesz megkövetelve az biztos.
(#28261) Petykemano: Ez erősen feladatfüggő. Aszinkron compute-tal is jó lehet a GPU offload akár dedikált GPU-ra is.
Az AMD ROCm implementációja Windows 10-re a következő update után jön, kb. az év végén. Más HSA implementációt nem csinál PC-re. A WDDM 2.x lesz az elterjedt megoldás.
Egyhamar biztos nem. IGP mellé a négy mag ideális, de hat maggal jön a Coffee Lake. -
Abu85
HÁZIGAZDA
válasz
Erdei88
#28254
üzenetére
Most akkor sem járna jól a cserével. Eleve még DDR3-on van. Tehát azt is váltani kell. Anyagilag elég sokba kerülne és túl nagy hasznát ma még nem érezné.
(#28236) Crytek: A fizika nem skálázható. Azt mindenképpen a legkisebb lehetséges konfigurációra kell tervezni.
(#28240) darkhorse: Ezek egy részét nem tudod igazán skálázni. Tehát itt a minimum konfigoknak kell elérni a négymagos szintet. Jelenleg az AI esetében sokkal több kutatás zajlik a GPU-s útkeresés szintjén.
Azt is számításba kell venni, hogy a konzolokra nagyon sok tartalom készül, és ott a CPU-k eléggé hurkák. Igaz, hogy sok az optimalizálási lehetőség, de ezekkel együtt is maximum egy négymagos Haswell szintjét tudják elérni, de tényleg agyonoptimalizálva. Tehát a legtöbb esetben a fő kutatási terület a GPU offload lesz. -
Abu85
HÁZIGAZDA
válasz
Crytek
#28231
üzenetére
Itt igazából az lesz az érdekes, amikor megjönnek tényleg a szörnyprocik. 12-16-18 maggal. Az Intel már most erősen azon van, hogy a fejlesztők nyomják ki a látótávolságot az egekig, és építsenek olyan hangmotort a rendszerbe, amivel a négymagosok nem bírnak el. Ezzel tudják terelni a játékosokat minimum 6 magra. Ez lesz a választóvonal majd. És gond sem lehet vele. Elvégre akinek négymagosa van, majd leveszi a látótávolságot és a reverbek hosszát minimumra. A játékélményt így is megkapja, csak nem úgy, akinek több magja van négynél.
-
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Ez a szerver oldali igény. Ez nyilván fontos nekik, mert ott az I/O szörnyeteg EPYC, abba bevágnak hat MI25-öt és kapsz egy gépi tanulásra igen erős konfigurációt eléggé olcsón.
A másik része ennek a piacnak az autókba szerelt hardver, amiben az AMD semmilyen formában nem utazik. Ide az Intel és az NVIDIA is pályázik, de itt az NXP messze a legnagyobb szereplő, és most akarja megvenni őket a Qualcomm, ami elég nagy baj a piacra nézve, mert akkora előnyük lesz mindenkivel szemben, hogy már most kiveri a víz a Softbankot. Ezért próbálja tőkésíteni a partnereit, mert nem akarják, hogy ez a jónak kinéző piac csak a Qualcomm+NXP-ről szóljon. Elvégre az nekik hátrány, hogy ha egy cég viszi a terület nagy részét és nem 4-5 cég versenyez.
-
Abu85
HÁZIGAZDA
válasz
rumkola
#28168
üzenetére
Jó rég volt. A Radeon Software óta a default flip queue size az AMD-nél 1. De a CS: GO esetében érdemesebb a Chillt használni. Az egy speciális modul, ami lényegében 0-ra veszi ezt az értéket, és e mellé még scene pacinget is kínál. Így érhető el PC-n a legkisebb késleltetés. Az elterjedt eSport címekre van Chill támogatás, mert ott még a driverek normál működését is problémásnak érzik a profi játékosok.
Aki nem Radeont használ, mehet HiAlgo Chillre. Ez ugyanazt csinálja GPU-tól függetlenül, bár sajnos eléggé instabil, mert a fejlesztők azóta nem frissítik, amióta beolvadtak az AMD-be. -
Abu85
HÁZIGAZDA
válasz
atok666
#28148
üzenetére
Persze. Ők is figyelik, hogy mi lesz a Qualcomm-NXP felvásárlásból. Alapvetően ezen a piacon messze az NXP a legnagyobb kiszolgáló. Ha a Qualcomm felvásárolja őket, akkor marha nehéz helyzetbe kerül mindenki, mert egyrészt a Qualcommnak marha jó technológiái vannak, és majdnem 40 milliárd dollárért még a piaci részesedést, illetve a kiépített értékesítési csatornákat is felvásárolják.
Egyelőre ugye azt vizsgálják a hatóságok, hogy jogilag aggályos-e a felvásárlás, tehát engedélyt még nem mindenki adott rá. Gondolom a háttérben a konkurensek fúrják is az üzletet, hiszen azzal senki se járna jól, ha a Qualcomm-NXP üzlet létrejönne. -
Abu85
HÁZIGAZDA
válasz
#35434496
#28144
üzenetére
Mert az AMD-t az önvezető autók piaca nem érdekli. Ők sokkal inkább a hagyományos piacok szerint tervezik a hardvereiket. Gaming, professzionális, stb. A Vega 10 sincs kitömve a grafika szempontból értelmetlen egységekkel, szemben a GV100-zal.
A Softbank számára az önvezető autók piaca az egyik kulcstényező. Lásd azt, hogy az új ARM magok merre fejlődnek. A japánok a jövőben az így kialakuló új piacok miatt komoly bevásárlásokat csinálnak. Kezdték ezt az ARM-mal.
A Softbank számára egyébként a Qualcomm és az NXP egyesülése a probléma. Olyan gigacég jön létre, hogy mindenkit kivágnak erről az önvezető autós területről, és bár sok technológiát licencel tőlük ez a két fél, illetve ha sikerül a felvásárlás, akkor hamarosan egy, de a Softbank rengeteg saját fejlesztést szeretne a piacnak kínálni, tehát számukra igen kellemetlen, hogy a sokszereplősnek kinéző automotive piacon a Qualcomm és az NXP összeáll, és csak idő kérdése, amíg beállítanak egy bedönthetetlen monopóliumot. Aztán itt sem az Intelnek, se az NV-nek, se senki másnak nem lesz esélye nagyobb megrendelésekhez jutni. -
Abu85
HÁZIGAZDA
válasz
Laja333
#28115
üzenetére
De fekszik neki, csak az AMD-re több Xbox One-ra írt kódot is áthoztak, amit lehet futtatni az AGS 4.0-val, míg az NV-n ezek nem futnak, így a hagyományos PC-s kódokkal dolgozik. Ez bizonyos területeken nagy különbséget eredményezhet.
A fejlesztő mindkét cégre optimalizál, csak a különálló kódok teljesítménye eltérő, és az NV szimplán lassabb kódokat tud futtatni. -
Abu85
HÁZIGAZDA
Ez egyáltalán nem ilyen egyszerű. Nyilvánvaló, hogy az a legjobb a késleltetés szempontjából, ha a flip queue méret minél kisebb. De maga a működés függ attól, hogy a meghajtót mire optimalizálják. Az AMD azért használ alapértelmezetten 1-es méretet a legacy API-knál, mert a Radeon Software első verziója óta át van alakítva a rendszer, hogy ezzel a flip queue mérettel működjön a legjobban. - [link]
Az NV esetében hiába veszed le 1-re, akkor is úgy vannak konfigurálva a legacy API-khoz a profilok, hogy a 3-as mérettel adja a legjobb eredményt a driver. Késleltetésben az 1-es biztos jobb lesz itt is, de "simasághoz" már a 3-as kell. Az AMD-nél a legjobb késleltetéshez és a "simasághoz" is jó az 1-es.Az explicit API-k alatt ezt a beállítást már a program kontrollálja. A legtöbb cím alapértelmezetten 1-es értéket használ, de van pár cím, ahol a felhasználó ezt módosíthatja. A legtöbb esetben az optimális méret architektúrafüggő is. Az NV azért nem lép egyesre, mert nagyon hosszú az architektúrájuk futószalagja, így nekik kell a nagyobb flip queue méret, hogy a feldolgozóik kihasználásán javítsanak. Az AMD-nek a GCN óta erre nincs igazán szüksége, ezért váltottak 1-es méretre a legacy API-knál már alapértelmezett szinten is.
A driverben ezt a beállítást nem feltétlenül ajánlott átállítani. Az AMD fel sem kínálja ennek a lehetőségét, bár amióta default 1-es a beállítás azóta ez mindegy.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#28053
üzenetére
A flip-queue beállítástól függ. Az AMD drivere régóta 1-re van optimalizálva, ergo alacsony késleltetésre, míg az NV-é 3-ra. Ugyanakkor ennél a játéknál a user határozhatja meg a flip-queue méretet. Ha a default három marad, akkor az NV sebessége tartja magát. Három alatt kicsit leesik, mert nincs az alacsony késleltetési határokhoz jól hozzáigazítva a meghajtó. Az AMD az 1-re korlátozástól nem esik el.
-
Abu85
HÁZIGAZDA
válasz
imi123
#28022
üzenetére
Megkapják ugyanazt a figyelmet, csak PC-n nincs ugyanolyan hozzáférési lehetőség a hardverhez, mint PS4-en vagy Xbox One-on. És ez teljesen független attól, hogy ki milyen utat jár, egyszerűen egy programnak nincs lehetősége PC-n közvetlen kontrollt szerezni a memória felett. Az operációs rendszer nem engedi meg. Nem is lenne értelme, mert nem fix hardverről van szó.
-
Abu85
HÁZIGAZDA
Nem szólhat bele. De a shaderek például továbbra is cserélhetők, illetve az allokáció meghatározása részben a meghajtón múlik.
Sebességet lehet, hibákat javítani nem igazán. De a sebesség szempontjából is jóval kevesebbet lehet javítani, ahhoz képest, mint amikor meg volt kernel driver.Leírtam a linkelt cikkben, hogy mi lesz.
Nyilván nem tudnak már normálisan optimalizálni. Se az NV, se az AMD. Van valamekkora driveres kontroll, de messze nem akkora, amekkora még akkor volt, amikor volt kernel driver. Ennek a gyakorlati hatása lényegében az, hogy a DX12-ben az AMD hardverek eléggé jobbak minimum fps-ben, mert az NV-nek már nincs hatalma a programfuttatást befolyásolni, és a hardverükhöz optimalizálni egy konzolos portot. Ezen úgy tudnak mostantól segíteni, hogy a fejlesztőknek biztosítják a tudást, hogy jobb legyen a programkód.
-
Abu85
HÁZIGAZDA
válasz
#69452517
#27942
üzenetére
A LiquidSky a Vegáig igen sok hardverrel ment. Főleg GRID K1 és K2, de volt benne sokféle Radeon Sky modell. Lényegében 10-15 féle különböző megoldás. A Vega arra kell, hogy a bétateszt végén már az összes eddigi VGA helyén Vega 10 fusson, mert ez a VGA lehetővé teszi, hogy egy GPU ne csak egy klienst szolgáljon ki, hanem akár hatot, tehát az egy szerverre levetített kiszolgálókapacitás akár hatszoros is lehet. Nyilván nem mindegy, hogy egy szerver fenntartási költségét hány ember fizeti. Ha csak annyi, amennyi GPU van benne, akkor ez a szolgáltatás veszteséges lesz. A Vega 10 nyereségessé tudja tenni, az aktuális árakkal is.
-
#27794
Abu85
HÁZIGAZDA
Malibutomi
#27751
Abu85
HÁZIGAZDA
válasz
Malibutomi
#27751
üzenetére
Ez tisztán programhiba. Méghozzá mintavételi. Túl kevés lehetett a tesztelési idő, hogy kiadás előtt észrevegyék és javítsák.
(#27779) huskydog17: CryEngine-nel ez tipikus. Azért licencelik annyira kevesen ezt a motort, mert nem volt pénz a next-gen konzolokra való optimalizálásra. Tulajdonképpen a legmagasabb szintű hozzáférési módokon fut. Ennél mindkét konzolban van olyan futtatási módra lehetőség, ami tíz cikluson belül be tud írni egy rajzolási parancsot a parancspufferbe, de a PC-hez igazított, magas szintű hozzáférési módok erre csak 3-4 millió ciklus alatt képesek.
A saját motor esetében ezekkel azért nem lehet találkozni, mert ott annyi pénz megy bele a fejlesztésébe, hogy nem éri meg a legmagasabb hozzáférési szintet választani. -
Abu85
HÁZIGAZDA
Ezek béták: Rust, Serious Sam Fusion 2017, The Talos Principle
A többi már végleges.
Mit jelent az, hogy nem átdolgozás? Mindegyik átdolgozás, hiszen az explicit API-hoz új motorstruktúra kell. Ezek az API-k nem kompatibilisek a régi struktúrákkal.
A patch ma szerves része a fejlesztésnek. Ennek az oka, hogy ma netje mindenkinek van, tehát nem kell a program megjelenését csúsztatni fél évet, hanem utólag kiadható egy frissítés.
Sok média be sem számolt róla. De az extra fogalma az, hogy valamit kínál valaki, amit nem muszáj elfogadnod. Ez a parancsikon ilyen volt. Legközelebb majd nem kapnak a felhasználók lehetőséget, hogy soron kívül kulcsot szerezzenek egy zárt bétatesztre. Nem erőszak ez, az AMD-nek is sokkal egyszerűbb úgy az élete, hogy nem kell kulcsokat félrerakatnia a Bethesdánál.
(#27699) Milka 78: Teljesen érthető. Eleve egy rakás paraméter van, ami ismeretlen. Nyilván a szivárgás is addig hasznos, amíg van adat, de sok infó még nincs.
-
Abu85
HÁZIGAZDA
Valamilyen explicit API-t használó, önállóan, valamilyen PC-re elérhető OS-en futtatható játékok listája:
Battlefield 1
Battlefield 4
Battlefield: Hardline
Dragon Age: Inquisition
Plants vs. Zombies: Garden Warfare
Sid Meier’s Civilization: Beyond Earth
Sid Meier’s Civilization VI
Sniper Elite 3
Sniper Elite 4
Thief
Ashes of the Singularity
Ashes of the Singularity: Escalation
Caffeine
Rise of the Tomb Raider
Gears of War: Ultimate Edition
Gears of War 4
Tom Clancy's The Division
Hitman
Quantum Break
Total War: Warhammer
Deus Ex: Mankind Divided
The Turing Test
Forza Motorsport 6: Apex
Halo 5: Forge
Forza Horizon 3
Halo Wars 2
Heroes & Generals
Dota 2
Rust
Doom
Mad Max
Serious Sam Fusion 2017
The Talos Principle(#27701) Egon: Leírtam, hogy mi volt, hogy erről mit gondolsz az olyan mindegy. Mint említettem a félreértések elkerülése miatt már nem közöljük az árakat, mert különböző NDA-k kötik a kezünket, ami egy csomó dolgot megszab, nem csak a cikk megjelenésének idejét. Utánakérdeztem, és kaptak egy hivatalos választ, ennek a válasznak megfelelően jártam el, mert kötött az NDA. Nyilván opció az NDA-t nem aláírni, csak akkor senki sem küld ebbe a kis országba hardvert időre.
Az, hogy te mit ítélsz el olyan mindegy. Egy extrát kaptál, amit lehetőséged volt egy másodperc alatt eltávolítani az asztalról.
Nem tudni egy meg nem jelent hardvernek a fogyasztását. Egyedül a memóriasáv-szélesség volt elérhető adat, ezáltal csak erre vonatkozóan lehetett összehasonlítást végezni. Ez az előzetesek hátránya, hogy nem minden specifikáció férhető hozzá. Természetesen lehetne más összehasonlítást is tenni, de azokhoz adatok kellenének.
A többi már személyeskedés, ami nem vezet semmire, de természetesen továbbra is várom a többi panaszt, amire reagálhatok. Peace.
-
Abu85
HÁZIGAZDA
Se szapulás, se szarozás nem volt. Burkolás meg pláne nem.
Én nem írtam le, hogy kapásból rossz. Épp ellenkezőleg. Azt írtam, hogy arra a piacra, amire jön így is jó. Vagy már ez is baj?.
Szerintem vagy szövegértési nehézségek áldozatai vagyunk, vagy nem ugyanazokat a híreket olvassuk. -
Abu85
HÁZIGAZDA
Mivel csak azt adta meg az NVIDIA. Akkoriban kérdeztem is őket, hogy a gyártóknál olcsóbb-e és azt írták vissza, hogy a gyártók majd külön jelentik be az árat, így hivatalosan a korábban küldött adatok helytállók. Az árakkal mindig baj van a megjelenés előtt, mert a gyártók elvárják, hogy azt írjuk be a hírbe, amit küldött a kapcsolattartó képviselet a mailben. Nem írhatok mást. Ezért sem szoktam manapság az árat közölni az táblázatos összefoglaló cikkben, mert csak azt írhatnám, amit küldtek, de ha az nem jó, akkor felhatalmazásuk nélkül nem javíthatom ki. Emiatt jobb a fórumban megbeszélni az árakat, mert ott a hozzászólók keze nincs megkötve, nem beszélve az árak látszanak a webáruházakból.
Egy parancsikont rakott ki a driver, ami egy beajánló weboldalon keresztül lehetővé tette, hogy az így kitöltött regisztrációval sorban állás nélkül kapjon a felhasználó Quake Champions bétakulcsot. Ez alapvetően egy extra, mert nem kötelező belerakni, másrészt az egész egy parancsikon volt, így akinek nem kellett le is törölhette, elvégre semmi mást nem telepített. De később megírtuk, hogy ki is vették, és elmagyaráztuk, hogy miért. [link]
Gondolom a GT 1030-ra gondolsz, mert nem derült ki egyértelműen. [link] - az a nem győztem kihangsúlyozni egy mondatból áll, amiben megemlítettem ezt. De ha úgy gondolod, hogy nem igaz, akkor vádolj meg azzal, hogy egy 48 GB/s-os sávszélességű VGA gyorsabb lesz egy 112 GB/s-osnál.
Várom a többit, mert az általánosítás helyett ezeket lehet tisztázni. Lásd a fentiek.
-
-
#27677
Abu85
HÁZIGAZDA
->Raizen<-
#27672
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#27672
üzenetére
Nem. A textúrák kezelése sosem lesz hardverfüggő. A Vega csak annyit hoz be, hogy nem a szoftver fogja vezérelni a streaminget, hanem maga a hardver. Így VGA számára emészthető formátumba kódolt, rendszermemóriába helyezett textúrákat nem egy szoftver rakosgatja majd a VRAM-ba, hanem a hardver. Amiatt nem kell egy rakás problémán átmennie a hardvernek, amikor az allokációkat kezeli.
Végeredményben ez annyit tesz, hogy hardveres menedzsmenttel a hardvernek nem kell a szoftverben lévő hibák miatt bűnhődnie. Maga a hardveres menedzsment hatékonysága simán hozható a mai megoldásokkal is, ha a fejlesztők hajlandók lennének minden egyes GPU-ra külön binárist fordítani. Konzolon simán elvannak 5 GB memóriával emiatt a lehetőség miatt. De PC-n nincs teljesen közvetlen hozzáférhetőség a memóriához se a CPU, se a GPU oldaláról. Ezért kell PC-n ugyanazt a problémát máshogy kezelni.
-
#27670
Abu85
HÁZIGAZDA
Petykemano
#27668
Abu85
HÁZIGAZDA
válasz
Petykemano
#27668
üzenetére
Nagyon leegyszerűsítve a működését. A 0% az, amit az AMD úgy állít be, hogy ne fogyasszon túl sokat, de a feszültség is finoman ugráljon, hogy az órajel is csak picikét változzon. Ha lefelé viszed, akkor egyre agresszívebben fog a feszültség ugrani, és ez nagyobb órajelre vonatkozó váltásokat is eredményezhet. Ha feljebb viszed, akkor még finomabban ugrál a feszültség, és ez akár teljesen meg is szüntetheti az órajelre vonatkozó váltásokat, kvázi állandósul a PowerTune órajel.
Persze a nagyon gyári tuningos kártyák esetében picit másképp működik, mert ott a gyártók is nagyon kitolják az alaplimitet. Tehát ott már a 0% is szinte olyan, hogy tartja az órajelet, de ott is lehet menni mínuszba. -
#27667
Abu85
HÁZIGAZDA
Petykemano
#27663
Abu85
HÁZIGAZDA
válasz
Petykemano
#27663
üzenetére
Értem már, hogy miről beszélsz. Félreértettelek. Na de erre is van megoldás, ráadásul gyári. A PowerTune skálázható a felhasználó által. -50/+50 százalékos beállítás van az Overdrive menüben. Az AMD által megszabott 0% egy általuk ideálisnak tartott középút, amivel nem kötelező egyetérteni. Ha szerinted nem elég agresszív, akkor -50%-ig bármit beállíthatsz. Ha szerinted túl agresszív, akkor +50%-ig is elmehetsz. Ezt te döntheted el. Lehet, hogy nem tudsz még róla. Ezt az AMD azért adja a felhasználóknak, mert számos igény van a hatékonyságra vonatkozóan, és nem igazán lehet mindenkinek kedvezően dönteni, ezért inkább adnak egy széles skálát, amivel a felhasználó olyanra állítja a rendszer működését, amilyenre akarja. Az AMD default beállítása nem több egy színtiszta ajánlásnál, és a limit változtatása nem tuning, hanem gyárilag garantált beállítás.
-
#27620
Abu85
HÁZIGAZDA
Petykemano
#27619
Abu85
HÁZIGAZDA
válasz
Petykemano
#27619
üzenetére
A technológiát simán beváltják csíkokra. Nem véletlenül terjedt el a Redditen az AMD FineWine dolog, hogy úgy öregszik, mint egy jó bor. De a dollárhoz más kell.
-
#27618
Abu85
HÁZIGAZDA
Petykemano
#27616
Abu85
HÁZIGAZDA
válasz
Petykemano
#27616
üzenetére
Az túl bonyolult, olyan sosem lesz. Mérnöki szemmel természetesen cél, hogy az elméletet súrolja a gyakorlat, de a komplex megoldásokra nehéz válaszolni hatékonyan. A fő cél, hogy maximalizálva legyen a gyakorlatban kihozható hatékonyság (tehát nem csak az első pár percben, nem csak a lapkák egy részére nagy varianciával, hanem úgy általánosan), nem pedig az, hogy elérjük az elméleti maximumot. Az AVFS-sel egyre közelebb lehet ehhez kerülni, de minél közelebb vagyunk, a maradék tempó annál költségesebben szedhető ki. Olyan az, mint az F1-ben. X autó az élmenőhöz képest van 4 másodpercre. 3 másodpercet könnyű találni, de a maradék 1 másodpercet már rohadt nehéz.
-
#27617
Abu85
HÁZIGAZDA
Petykemano
#27614
Abu85
HÁZIGAZDA
válasz
Petykemano
#27614
üzenetére
1.) Nem az AMD és az NV megoldását hasonlítom össze, hanem az AVFS-t és a DVFS-t. Itt tényszerű előnye van az AVFS-nek.
2.) Mert az AMD hardvere fel van készítve olyan dolgokra, amihez az NV hardvere még csak hozzá sem tud szagolni, és mondjuk az a buszrendszer, ami szükséges az egyes shader modell 6.0-s függvényekhez igen sokat szokott fogyasztani. Viszont a konzolba kérték a megrendelők a tudást, mert az emuláció túl lassú lenne. Az AMD is tudna egyébként csinálni ultramobil specifikációknak megfelelő hardvert, és akkor most emulációt építenének a shader modell 6.0-ra, nem lenne az, hogy bizonyos függvényekre külön utasítást tudnak rendelni. Ez olyan dolog, mint a procinál az Atom és a Core mag különbsége. Ha több Atomot raksz egy lapkára mint Core magot, akkor az összesítésben gyorsabb lesz és kevesebbet fog fogyasztani. Viszont számos dologban nem lesz olyan jó, mint a kevés magos Core. Pró-kontra elv.
3.) Az AMD megoldása is tud frekvenciát növelni és turbózni. A kettő között az a különbség, hogy az NV-nél a turbó máshogy valósul meg, és ezért eléggé lassú a reakcióidő, amíg azt beállítja. Ezt a rendszer binneli, tehát vannak előre konfigurált lépcsők az alapórajel fölött, amelyekre ugrándozik. Az AMD fordítva csinálja, mert például a mostani AVFS implementáció 1-100 MHz között bármekkorát tud ugrani, tehát nincs lépcsőzés, illetve 2 mikromásodpercenként szabad a váltás. Emiatt a működés miatt az AMD hardverén a turbó nem csak egy extra hatás, hanem egy állandó hatás. Tehát amikor az NV-nek a base órajelre már visszaállt a teljesítménye, az AMD megoldása még lehet, hogy a PowerTune maximumon tud maradni. Itt számít a hőtűrés is, mert például a GeForce a programindítástól számítva 5 percig tudja tartani a maximális teljesítményét. Utána valamennyit vissza fog lassulni (alkalmazástól/hardvertől függően 2-8% lehet), mert eléri a BIOS-ban konfigurált kritikus hőmérsékleti paramétert, ami a visszalassulási küszöb. A PowerTune esetében is volt ilyen tényező, amitől a lapkák a futtatási időben nagyjából 6-7 perc után elkezdet lassulni (ez is programfüggő volt, illetve hardverfüggő is, de általánosságban a mértéke 1-5% körüli). A mostani AVFS-sel viszont ez a tényező a PowerTune esetében már nem létezik. Stabilan tudja tartani az órajeleket a rendszer, nem csak az első nagyjából 10 percben. Ezért alkalmaz az AMD másfajta turbó jelölést, szó szerint a PowerTune órajelet. -
#27615
Abu85
HÁZIGAZDA
Petykemano
#27610
Abu85
HÁZIGAZDA
válasz
Petykemano
#27610
üzenetére
A user azért tudja alulfeszelni, mert xyz programra lehet, hogy jó lesz, de w-re már nem. A gyártónak viszont xyzw programokra is stabil állapot kell.
Minden rendszerben lehet találni egy rakás wattot is, ha csak pár program futtatására alulfeszeljük. Ez okozza a dolog nehézségét. Az AVFS csak abban segít, hogy a DVFS-nél alacsonyabb feszültséget és magasabb órajelet tud beállítani. De még így is messze lehet az elmélettől, viszont nem annyira, mint a DVFS. Emiatt pici a teljesítményvarianciája is. Ami mondjuk a DVFS megoldásokra nem jellemző, azoknál viszonylag nagy a variancia. Gondold el ezt úgy, hogy van két tök ugyanolyan RX 480-ad, és előfordulhat, hogy az egyik 3%-kal gyorsabb a másiknál. Ugyanez igaz a GTX 1060-ra is, ha két ugyanolyan VGA-d van, de itt már a különbség elérheti a 7%-ot is.
-
#27609
Abu85
HÁZIGAZDA
Petykemano
#27590
Abu85
HÁZIGAZDA
válasz
Petykemano
#27590
üzenetére
Éppen ilyet kapsz.
De az AVFS számol a gyártási varianciával. A DVFS nem tud ezzel mit kezdeni. Ez az oka annak, hogy a Radeonok teljesítményvarianciája 3% alatti a Polaris óta. Például egy Pascal esetében ez a szám 6-7% is lehet. Bár ebben szerepet játszik a binelés.
-
#27589
Abu85
HÁZIGAZDA
Petykemano
#27587
Abu85
HÁZIGAZDA
válasz
Petykemano
#27587
üzenetére
Használjál. Azért van ott funkció. De gyárilag csak 100%-osan stabil beállításokat fogsz kapni.
Nem szükséges a táblázatot módosítani. Egyik célpiac sem sivatag, hogy 50°C lesz a hőmérsékletkülönbség 24 órán belül. Ha instabilitást érzékel az órajelet viszi vissza. Az bőven elég a stabilitás megőrzéséhez.
A táblázat alapvetően egy működési módot ír le a hardvernek. Ettől az órajelet és a feszültséget is tudja változtatni, mindig annyira, amennyi stabilan hozható. A DVFS is kvázi ugyanez, csak ott a működési paraméterezés Európában is Indiára szabott, tehát nem tud beállítani olyan magas órajeleket és olyan alacsony feszültségeket, amilyeneket ugyanaz a lapka AVFS-sel tudna.
-
#27585
Abu85
HÁZIGAZDA
Petykemano
#27583
Abu85
HÁZIGAZDA
válasz
Petykemano
#27583
üzenetére
Mert a felhasználó a tuningolást a játékokban teszteli. De a VGA esetében nem csak olyan körülményben kell stabilnak lenni, amely a beépített részegységek zömét azonos időben nem is használja. Az xyz játékokban stabil nem jelenti azt, hogy egy w programban is az lesz. És ez egy fontos tényező az órajel beállításánál.
Nyilván, hogy ha saját magad tuningolsz, akkor te megteheted, hogy egy programra ráoptimalizálod az órajeleket. Mert úgy gondolod, hogy úgy stabil, de bőven lehet, sőt igen valószínű, hogy a világban van még egy olyan program, amellyel a tuningod már nem stabil. Ez saját órajelállításnál a te hibád, de ha az AMD csinálná, akkor az bizony gyártói hiba lenne, amiért leszednék a cég fejét.
-
Abu85
HÁZIGAZDA
válasz
schawo
#27578
üzenetére
Ilyen a Polaris és ilyen lesz a Vega is. PID szabályozó, fuzzy vezérlővel, és táblázatos rásegítéssel, meghajtó oldali opcionális profilkonfigurálással. A táblázatra igazából azért van szükség, mert gyorsabb előre kiszámolt paramétereket kiolvasni és beállítani, mint real-time számolni, majd mire beállítanád a lehetőség a magasabb órajelre megszűnik. Mikromásodpercen belüli órajelváltás lehetőségével a reakcióidő kritikus.
-
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.
-
#27575
Abu85
HÁZIGAZDA
Petykemano
#27560
Abu85
HÁZIGAZDA
válasz
Petykemano
#27560
üzenetére
Egyáltalán nincsenek túlfeszelve a kártyák. Csak nem értik a felhasználók, hogy a földön uralkodó hőmérséklet és páratartalom nem egységes. Egy kiadott terméknek nem csak mediterrán éghajlatban kell működnie, hanem trópusi és szubtrópusi környezetben is. Az AVFS pedig arra szolgál, hogy a működési órajel ne 800-900 MHz legyen, hanem 1200-1300 MHz.
-
Abu85
HÁZIGAZDA
Mikroakadások elsődlegesen az API-tól és az alkalmazástól vannak, nem pedig a drivertől. Ha erre akarsz utalni, akkor jelen pillanatban az a helyzet, hogy az AMD driverei jelentik most a csúcsot. Most az ő fejlesztési konstrukciójuk a legjobb, és emiatt jó szinten tudják tartani a kódminőséget, nem jön gyorsan különböző kritikus hibákra hotfix, stb.
Mi az a BS? Black Screen vagy Blue Screen? Csak azért érdemes ezt értelmezni, mert ha bármilyen hiba van a gépben, akár VGA, akármi, akár szoftver, akkor mindenképpen fekete vagy kék képernyőt kapsz.
A pumpa és a hűtő igazából nem tipikusan olyan hiba, ami az AMD tervezéséből fakad, de nyilván ezek tényleges problémák, ki kell értékelni őket.
A 4 GB HBM memóriával tudtommal nem volt semmilyen stabilitási probléma, vagy bármi bug.
(#27458) Egon: Éppenséggel annyira nincs nagy különbség, hogy AMD vagy Intel proci mellé raksz AMD vagy NV VGA-t.
[link] - Itt meg lett nézve. A GTX 1060 és az RX 480 nagyon hasonlóan teljesít Intel és AMD CPU-val is. Egyedül a Rocket League esetében van az, hogy AMD CPU mellett lényegesen jobban fut Radeonon, de a Rocket League-ről köztudott, hogy egy AMD-re írt játék, az RX 480 is tartja a lépést a sokkal drágább GTX 1080-nal benne (99th percentile mérésben még jobb is az RX 480, nem is kevéssel). Valószínűleg vannak a programban különböző optimalizálási problémák, amelyek az NV driverét rosszul érintik, és emiatt általánosan esik a kártyáik elméleti teljesítménye, AMD CPU-val jobban. A fejlesztők pedig szarnak rá, nem éri meg nekik javítani.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Persze ha jó úgy, hogy a WHQL-ek érkezése után a hotfixre várással viccelődik a hírhez tartozó topik, akkor dobjátok a köveket, ne kíméljetek. 
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- VR topik
- Geri Bátyó: Agglegénykonyha különkiadás 2 – Kajás poénok
- Mesterséges intelligencia topik
- Kertészet, mezőgazdaság topik
- Fejhallgató erősítő és DAC topik
- gban: Ingyen kellene, de tegnapra
- Revolut
- Pedzegeti az új Xbox irányát a Microsoft
- Autós kamerák
- Doky586: SecureBoot kulcsok frissítése (2026 nyara)
- További aktív témák...
- Apple iPhone 13 / 128GB / Kártyafüggetlen / Akku:87%
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max/
- Dell UltraSharp 24 USB-C Hub Monitor - U2422HE - 27% ÁFÁs
- HIBÁTLAN iPhone 13 Pro Max 256GB Sierra Blue-1 ÉV GARANCIA - Kártyafüggetlen, MS4224
- iPhone X 64GB 100% (3 hónap Garancia) - AKCIÓ
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest