Új hozzászólás Aktív témák
-
#33899
Abu85
HÁZIGAZDA
Petykemano
#33897
Abu85
HÁZIGAZDA
válasz
Petykemano
#33897
üzenetére
A DXR esetében a Microsoft két lehetőséget kínál a működésre. Az egyik a fallback layer. Ez egy olyan univerzális réteg, amit a Microsoft ír, és minden olyan legalább shader modell 6.0-t támogató hardveren futni fog, ami nem kapott gyártói réteget. A gyártóknak azonban lehetőségük van arra, hogy írjanak maguk egy saját hardver fölötti réteget a DXR-hez, amivel nem a Microsoft univerzális rétegét fogják használni, hanem maguk határozhatják meg, hogy az egyes feladatok hogyan fussanak a hardveren. Az RTX egy ilyen réteg a Volta fölé. De nem biztos, hogy ez a réteg el lesz nevezve, gyakorlatilag ez egy driver, amit nem drivernek hívnak, de ettől még egy szimpla driver.
(#33898) TTomax: A tesszelláció tökéletes példa arra, hogy mennyire tönkretehet valamit, csak itt a tesszelláció jellegzetessége miatt nem játékról, hanem effektekről lehet szó. Viszont látható, hogy például se a Hairworks, se a God Rays effekt kód nem fejlődik az NV-nél, mert maga az alapkoncepció az indokolatlan mértékű tesszellálásra épít, és ezáltal a geometry shaderre épít, amik olyan mértékben lezabálják az effektre szánt időbüdzsét, hogy a fontosabb komponenseket, a minőséget biztosító komponenseket már nem tudják hozzáadni. És itt például a Hairworksnek alapvetően szüksége lenne valamilyen OIT megoldásra, sőt, specifikus élsimításra is, hogy a jobb ütközésdetektálásról már ne is beszéljünk, csak nincs rá több tervezett erőforrás, mert elment a hardveres kapacitás olyan dolgokra, amelyek a végső képen a végleges minőségbe alig szólnak bele, de vért izzad a vas, hogy megoldja ezeket. Ez nem lenne annyira kirívó, ha nem lenne a Hairworks mellett egy TressFX, ami például nem tesszellál, geometry shadert sem használ, és gyorsabban megcsinálja a feladatot OIT, analitikai élsimítás és ma már SDF kalkuláció mellett, mint a Hairworks ezek nélkül. És ez meghatározza egy effekt jövőjét is. Ha már az alap hibás, akkor nem fogják továbbfejleszteni, mert nem tudnak mit kezdeni az erőforrásigényével, ezért nem láttuk sosem a második generációs HairWorksöt, míg a TressFX már negyedik generációs kódnál tart.
És hasonló probléma merül fel a sugárkövetésnél is. Azt nem igazán lehet optimalizálni, túl egyszerű maga a feladat, maximum paraméterezhető, hogy pixelenként hány sugár legyen, és milyen messze legyen számolva. Hasonlóan a tesszellálásnál, meghatározhatod a formátumot és a részletességet. De ha elszámolják az egészet, akkor onnantól kezdve azon kell gondolkodni, hogy a raszterizálás szempontjából mi legyen visszavéve, vagy ha a memóriaigény jelent problémát, akkor csökkenteni kell a textúra- vagy a geometriai részlegességet, mert ugye a VGA-k esetében a memória eléggé kötött, és nem minden meghajtóban van egy csúszka, hogy oda igazítsd a visszajelzett memóriát, ahol jó a programnak.Önmagában viszont a tesszelláció nem hibás például a fentiekért. Nem az eljárással van probléma, ahogy a sugárkövetés is nagyon jó technika. A tesszelláció esetében például a fenti problémákat minden esetben az emberi hülyeség okozta. Még azt se mondom, hogy szándékos hülyeség, mert lehet, hogy fiatal volt aki a projektet vezette, látszólag jó ötletnek tűnt az egész, mára meg a tanulópénzként tekint rá (főleg úgy, hogy az NV pénzét égette el). A sugárkövetésnél is ez lesz. Lehet ezt jól használni, és lehet úgy is, hogy végeredményben úgy nézd a tükröződést, a GI-t és az AO-t, hogy szép-szép, de a játék többi része öt éves szintre lett butítva. És itt jön elő egyébként az állandó vita, ami tényleg egy aktuális vita, hogy mire érdemes ezt használni. Mert igen, a sugárkövetéssel biztosan jobb lesz mondjuk a tükröződés, de mondjuk egy trükkös SSR megoldás tízszer gyorsabban hoz egy megközelítőleg jó eredményt. És felmerül itt, hogy például a játékos a játék közben észreveszi-e, hogy éppen van egy olyan doboz a jelenetben, ami pont nincs rajta a képkockán, de pont látszódnia kellene a vizes padlón a sarkának. Az ultimate kérdés tehát az, hogy megéri-e ezért az előnyért tízszer több ALU kapacitással fizetni, és megéri-e bizonyos problémák esetén az alapvető minőséget adó raszterizálásból elvenni, ami kihatással van a teljes játék grafikájára is, sugárkövetés ide vagy oda.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
CsonkaImo
#33903
üzenetére
Lejárt a szerződés és nem hosszabbították meg. Nem volt semmi különleges, csak nem tudtak megegyezni. Úgy tudom, hogy azért a támogatásért, amit az AMD biztosított többet vártak vissza, de az EA nem akar senkitől sem többet szimpla reklámszerződésnél, mert megvan a saját erőforrásuk a technológiai háttérhez, ezért az AMD átvitte az erőforrását a Bethesdához, a CIG-hez és az Epic Gameshez.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#33931
Abu85
HÁZIGAZDA
Petykemano
#33929
Abu85
HÁZIGAZDA
válasz
Petykemano
#33929
üzenetére
Kétféle irány kezd kialakulni. Az egyik a speciális, amikor magát a gyorsítót eléggé specifikusan egy célterületre tervezik, míg a másik az általánosabb felhasználás, amikor nem csak packed dot productra van kigyúrva a hardver.
Ezt többen másképp közelítik meg. Az Intel konkrétan két hardverrel. Nervana a specializált irányra, és a DL-es Xeon Phi az általánosra. Az NV egyszerűen egy hardverbe építi mindkettőt, de úgy, hogy elszeparálják a részegységeket, míg az AMD egy hardverbe építi mindkettőt, de nem szeparálják el a feldolgozókat.
Mindkettőnek megvan a maga előnye és hátránya.
Az Intelnek az lesz a gondja, hogy két hardverre kétféle szoftverkörnyezetet nehéz lesz optimálisan fenntartani, na jó nem annyira nehéz, de minimum eléggé költséges. Viszont a CPU-szerű Xeon Phi dedukcióra nem igazán gyúrható ki, mert már maga a felépítés elvisz egy rakás tranzisztort.
Az NV-nél igazából a tranzisztorköltség a gond, mert gyakorlatilag külön feldolgozókat alkalmaznak a packed dot productra, és mellette más feldolgozók vannak a tréning szakaszra.
Az AMD-nél a Vega 20-ról tudni lehet, hogy az AMD az architektúra flexibilitására épít, és mindent egy feldolgozóból oldanak meg. Ez kicsit olyan, mint amit az Intel csinál a Xeon Phi-nél, csak az architektúra nem követel meg a működéshez bazi nagy, tranzisztorzabáló gyorsítótárakat és ezekhez tranzisztorzabáló vezérlést, vagyis az implementált tudáshoz kellő mennyiségű feldolgozó is lesz. Ennek az előnye az, hogy az elérhető linux driver doksik szerint 4/8 elemű packed dot productot simán le tudsz implementálni. Dot utasítással 8 bites adatokon 1 GHz-en simán megvan ~114 TOPS. És az órajel biztos nem 1 GHz lesz. A 8-elemű módban akár a 400 TOPS is meglehet. De ha feltételezünk 1,5 GHz-et, akkor akár a 600 TOPS is. Ennek az összevont dolognak az az előnye, hogy az összes feldolgozót használhatod packed dot productra, míg az NV s saját módszerével csak a beépített feldolgozók kis részét éri el így, az Intelnek a Xeon Phiben eléve túl kevés feldolgozója van, mert az architektúra nem skálázható ideálisan. A hátrány igazából a tréning szakaszok keletkezik, mert ott igazából ezek a specifikus előnyök nem jönnek elő, mivel legalább 16 bites FP packing kell. Ott már a kevert pontosság melletti lebegőpontos számítási teljesítmény számít.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#33957
Abu85
HÁZIGAZDA
Petykemano
#33955
Abu85
HÁZIGAZDA
válasz
Petykemano
#33955
üzenetére
Mindenhol programozni kell. A semmiből nem terem kód senkinek.
Minden számolásnál ugyanazt a matekot kell követni. ALU-k száma * órajel * utasításonkénti operációk száma. Egy nyolcelemű packed dot product például 8 MUL és 7 ADD.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#33987
Abu85
HÁZIGAZDA
Petykemano
#33980
Abu85
HÁZIGAZDA
válasz
Petykemano
#33980
üzenetére
Azért ritka manapság az előny clock-2-clock, mert ma már az órajel is egy fícsőr. Csak ahhoz ész kell, hogy ezt meg is értse a média. Szóval hiába magyarázza azt az Intel, az NV és az AMD is, hogy a magasabb órajel az nem úgy jön, hogy kisebb a csík és csak úgy megterem, hanem beletervezik magába az architektúrába.
Egy, azóta ex-Intel alkalmazott mondta nekem régebben, hogy több újságíró is a 2000-es évek szintjén ragadt, és nem tudják őket kirobbantani onnan, mert egyrészt nagy már a bizalmatlanság a gyártók felé, hogy biztos hazudnak (nyilván 20 évvel a hátuk mögött talán egy-két füllentésre való emlékezés erre ad is alapot), másrészt régen volt nagy clock-2-clock változás is, és ezt keresik újra és újra, de ma már hiába. A húsz évvel korábbi tapasztalataiknak viszont jobban hisznek, így a modern gondolkodásra képtelenek lettek, vagyis nem tudják elfogadni, hogy a legnagyobb teljesítményt ma konkrétan szoftverből nyerhetik a hardvergyártók is, de ehhez ugye kellenek a szoftverek is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#33993
Abu85
HÁZIGAZDA
Petykemano
#33991
Abu85
HÁZIGAZDA
válasz
Petykemano
#33991
üzenetére
A DCC, a DSBR, IWD, stb. ezek mind működnek. Régebben volt olyan driver, amiben ezeket letiltották és meg lehetett nézni vele és nélküle. Ma már ilyet nem csinálnak, mert ezt csak a megjelenésre tették meg. Az IWD-t ugye úgy, hogy a 17.50-es batchtől van.
A többit nem értem, a szuperskalárizét és a super-SIMD-et sem.
Sok dolgot nem is kell szoftverből alkalmazni, driveres. A fenti három mindenképpen. DCC-je nyilván van a Fiji-nek is. IWD-je nincs, de az leginkább ott számít, ahol a munkafolyamatok kiosztásáért felelős egység limitál, például Far Cry 5-nél, Deus Ex Mankind Dividednél mindenképpen, mert ott sok a geometria. A DSBR a tipikus tiled motorokban számít, mint a Frostbite, ott nagyon sokat 30% körüli bytes/frame spórolás van. Ez egyébként az iparágon belül a PowerVR spórolásához mérhető, a többi rendszer kevesebbet spórol, igaz azok nem is draw stream megoldások.
Nem is célozzák, hogy sikerüljön. Láttad, hogy senki sem növelte meg a VGA-kra vonatkozó gyártókapacitást, amikor halálra is kereshették volna magukat az elmúlt egy évben. Ezek a cégek írják a piacot és nem csak a résztvevői. Nekik már megvan komponálva a 2020 utáni időszak, amit kurvára nem külön megvásárolható kártyákkal képzelnek el. Ma már arra rendezkedik mindenki. Ha számítana egy kicsit is ez a piac, akkor most mindenki szolgálná ki a ti VGA-k iránti igényeiteket, mert látod, hogy mennyien várják az újakat. Ehhez képest csak az időt húzzák, pedig már nincs mire, a bányászat beállt a termelt VGA-k kb. 7%-ára. A többi már a játékosoknak megy.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#33992
üzenetére
A GCN1 és GCN2 nem tudott SDWA-t, DPP-t, nem volt írható a skalár gyorsítótár, illetve nem volt regiszterindexelés sem. Utóbbit emulálnia kellett a fordítónak, ami sokszor nem vezetett jó teljesítményű kódhoz, míg a GCN3-tól ez natívan megoldható.
A GCN1->2 váltás volt inkább marketing, a GCN3 az nagy ugrás volt. A GCN4 alapvetően nem volt igazi előrelépés, de a kódolási sémát lecserélték, viszont az ISA képességei nem változtak. Ezt azért nem nevezik marketingnek, mert ez alapozott meg a GCN5-nek, ami szintén egy igen nagy ugrás az ISA tekintetében, hiszen bevezeti az RPM-et, plusz memória és atomi kiegészítések.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#33995
üzenetére
Mármint melyik gyakorlatban? Ezeket az újításokat a HLSL 2017-től lehet alapvetően használni. Gyakorlati kódot max. az Xbox One látott, esetleg PC-n a Radeonok a Doomban és a Wolf 2-ben, mert ugye ott adott a SPIR-V, de az is specifikus kiterjesztésekkel. A Microsoft a shader modell 6-ba csak idén kényszeríti bele a piacot. Szóval szabványos szinten ezek igazából az idei év végétől élhetnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Direkten ők nem tudják. A gyártópartnereiktől kapott adatokra támaszkodnak. Nyilván a VGA-gyártók ezt azért elég jól fel tudják mérni, akár direkt eladásból, akár a hivatalos csatornákon kért visszajelzésekből. Ezeket kapja meg a JPR is. Nyilván az AIB nem fogja megmondani az NV-nek az AMD, és az AMD-nek az NV számait. Legalábbis hivatalosan nem, aztán fű alatt lehet, hogy megtudják.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért nem atomfizika ez. A gyártópartner felé vannak rendelések bányába való VGA-kra. Szimplán odamegy a bányászó társulat, hogy ők el szeretnének vinni egy rakás VGA-t bányászni, mittomén 1 millió euró értékben.
A disztribútorok tekintetében pedig a hivatalos csatornákat azért elég jól lehet követni. A kereskedők sokszor kérhetnek visszajelzést, hogy a kisker cuccaiból mennyi VGA-t vittek el úgy, hogy egyszerre hatot vettek mondjuk. De már a három is gyanús. Ezeket visszaadod adatként, és meg is van, hogy mennyi VGA ment a bányába. Persze van némi hibaarány, de alapvetően nem annyira sok. Ha egy VGA-t veszel, akkor nem valószínű, hogy bányász vagy.(#34003) Yutani: Most nem. Most inkább csökkenőben vannak az árak. Régen valszeg azért sokkal több volt ez. Azt hiszem a Q4-ben valami 3 millió, de ezt nem tudom pontosan. Előtte valszeg volt 5-7 is. Azért a 25% már elég ahhoz, hogy küldje felfelé az árakat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34011
Abu85
HÁZIGAZDA
Petykemano
#34009
Abu85
HÁZIGAZDA
válasz
Petykemano
#34009
üzenetére
Na most ezeket nem úgy kell mérni, erre nem véletlenül voltak olyan meghajtók az elején, amikben le voltak tiltva. A hatásukat eleve nem fps. A DSBR-t például bytes/frame-ben mérik, az IWD hatását a kontextusváltások számában, míg a DCC-t szintúgy bytes/frame-ben. Persze ehhez tudni kell, hogy miket keressen, egy szimpla tesztelő nem tudja megcsinálni. Egyrészt nincs hozzá meghajtója, illetve hiába is szerzi be a toolokat, akkor sem fugja tudni, hogy mit kell nézni.
Ők már jóval többet tudnak a Microsoft új WDDM-éről. Az erőforrásaikat inkább abba ölik, mert egy külön vásárolható kártyával szert se fogsz elérni rajta.
(#34010) Petykemano: Az AMD teljesen más. Ők már tudják használni, hiszen van hozzá egy rakás kiterjesztésük mindegyik elterjedt API-ra. A szabványos megoldás viszont más, ott már mindenki tudja majd használni, így megéri sokkal többet építeni rá, hogy több legyen az összesített sebességelőny is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34017
Abu85
HÁZIGAZDA
Petykemano
#34012
Abu85
HÁZIGAZDA
válasz
Petykemano
#34012
üzenetére
Ezek nem egyedi mérőszámok. Így lehet mérni a hatásukat, mert a grafika számítása az heterogén feladat, vagyis sok eltérő részegységgel történik az egész és/vagy eltérő hardverállapotok mellett. Tehát van egy megoldás egy bizonyos problémára, amit nem tudsz kimérni fps-en, mert az a teljes képkocka számításának időtartamát méri, miközben lehet, hogy az adott technika a képkocka időtartamának az 5%-ára reagál. Tehát azt az 5%-ot gyorsítja mondjuk 50%-kal. Viszont ha az fps-t méred, akkor rendkívül félrevezető az egész, mert beleraksz a mérésbe 95%-nyi értelmetlen időt, ami csak megakadályozza, hogy megmérd az újítás előnyeit.
Mármint mert nem méred ki. A Doomnál például ki lehetett mérni, hogy az intrinsics mit hozott. Nem az OpenGL és a Vulkan különbségét láttad a Radeonon, hanem azt, hogy a Vulkan kódhoz a PSSL-ből volt fordítva a SPIR-V, míg az OpenGL kódnál maradt a GLSL.
Ezek a mai GPU-k igazából igen extrém mértékben skálázhatók. Ezek a modern ISA-k 30000+ konkurens szálat is futtatnak. Tehát igazából csak a buszrendszertől függ, hogy hány tömböt raksz a hardverbe, valószínűleg akkor sem ütköznél skálázási gondokba, ha minden multiprocesszort külön tömbbe helyeznéd. Az más kérdés, hogy hatalmas faszság lenne, de az ISA alapvetően elbírná. Ezért sincs egy jó ideje gyökeresen új utasításarchitektúra az AMD és az NV részéről, mert hamarabb futnak bele a gyártástechnológia fizikai limitjeibe, minthogy maga az ISA skálázódása váljon korlátozóvá. Legközelebb akkor lesz itt nagy változás, amikor hozzák a dinamikus erőforrás-allokációt. Ott kényszerből bele kell nyúlni a működésbe, mert a mostani ISA-k statikus módszerre vannak szabva. Ez egyébként majd egy külön izgalmas változás lesz. Egyedül a megboldogult Larrabee volt ilyen rendszer, csak hát sajnos nem tudtuk megtapasztalni az előnyeit.
(#34013) Oliverda: Nyilván ezek a dolgok csak azokat érdekelhetik, akik értik is, hogy miről is van szó.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34034
Abu85
HÁZIGAZDA
Petykemano
#34032
Abu85
HÁZIGAZDA
válasz
Petykemano
#34032
üzenetére
Senki sem hibás itt. Pletykákat lehet írni és linkelni is. Semmi gond nincs velük, csak tudni kell kezelni őket. Még én is megírtam Tombácsi pletykáját, csak még az élesítés előtt megírta az egyik kontakt, hogy kamu, így inkább nem is jelentettem meg a hírt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#34048
üzenetére
Igazából ahhoz van köze, hogy az új konzolok is AVX-et támogatnak, és eleve egy minimum igénnyé kezd válni a négy mag, tehát az se számít, hogy sok újabb Celeron és Pentium nem támogatja. Emiatt egyszerűbb csak az AVX-re fejleszteni, mert ha már visszaportolod mondjuk SSE4.1-re, akkor azzal a tesztrészlegnek igen nagy extra munkát adsz, és minden egyes jövőbeli frissítésnél ezt az extra tesztelési munkát hordozod magaddal, ami összességében nem kevés pénz lesz ám. Emiatt ha már úgyis négy mag a minimum, akkor a stúdiók egyre inkább húznak az AVX-hez is egy vonalat, mert a kétmagos AVX-es nélküli gépek már a magszám miatt kiesnek. A régebbi, sokmagos gépek pedig túl régiek, hogy ezekkel törődjenek.
A másolásvédelem nem kifejezetten kötelezné az AVX-et, de persze ha már a motor eleve ezt igényli minimum, akkor nyilván kérhetnek olyan verziót, ami ehhez igazodik. De sose a másolásvédelem határozza meg az erre vonatkozó igényeket.
Tudom, hogy 4-6 magos AVX nélküli procival nem vígasz, de maga az AVX 7 éves, és mindkét nagy konzol támogatja, tehát alapvetően várható volt, hogy előbb-utóbb abszolút minimum igénnyé válik a PC-n belül.(#34045) Keldor papa: A Dunia limitál? Durva lenne, hiszen háromszor nagyobb terhelésre van felépítve, mint az összes korábbi motorja az Ubinak. Megközelítőleg sem jár most ott az aktuális AnvilNext vagy Snowdrop, ahol a Dunia jelenlegi verziója. Mondjuk az is igaz, hogy az AnvilNext és Snowdrop nem is alkalmaz GPGPU cullingot, míg az új Dunia igen, meg egy rakás más trükköt. Emiatt tud most részlegesebb világot megjeleníteni. Valószínűleg ezt a fejlesztést minden más motorjába beépíti majd az Ubi, csak ez azért időbe kerül.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
core i7
#34051
üzenetére
Egyszer biztos. Talán úgy 7-10 év múlva. Most az AVX-en a sor. Elég nagy a felhasználóbázis, a kétmagos penyákat már a magszám miatt sem kell számba venni, és a konzolok is támogatják. Nincs igazán sok ellenérv az AVX kapcsán. Az SSE4.1-nél pedig ellenérv lehet a tesztelési költség, amit ennek az ISA-nak a támogatása jelentene. Gondolom ez téged nem vigasztal, de végeredményben ez lassan egy gazdasági kérdéssé válik. Megéri-e az SSE4.1-et azért a maréknyi játékosért támogatni, akik amúgy megfelelnének a magszámra vonatkozó követelménynek (ami ugye manapság minimum 4), de annyira régi a procijuk, hogy az AVX-et még nem támogatja.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
core i7
#34055
üzenetére
Egyre többen. Az, hogy az Ubinak már megéri, azt jelenti, hogy más is felveti a spórolás kérdését.
(#34060) core i7: Nem igazán fogsz nagy kilövést látni az AVX minimum igénnyé emelésétől. Pici sebességet talán lehet nyerni, de eddig is támogatta nem kevés játék ezt az ISA-t, miközben megtartotta az SSE4.1-et is. És a Gulftown mondjuk nem maradt le igazán. Szóval ez csak egy ISA, nem fog az erőviszonyokon orbitális mértékben változtatni. Annyit tudok elképzelni, hogy ha ennyire minimum igény lesz, akkor az Intel a következő körben tényleg berakja minden CPU-jába.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#34177
üzenetére
De a notebookos G-Sync-ben sem. Nem azért van ez a hardver, mert annyira szükség van rá. A Pascal óta ki lehetne dobni a kukába, nincs szükség arra, hogy beszereljék, mert ami a Kepler/Maxwellből hiányzott, és szükségesség tette ezt az FPGA-t, az már ott van a Pascal GPU-kban.
Maga a VRR, gyakorlatilag az összes verziója egy faék egyszerű megoldás, ami a VBLANK-et (vertical blanking interval) manipulálja. Ez egy olyan paraméter, ami megadja, hogy mennyi idő telik el az előző képkocka utolsó és az új képkocka első pixelsorának monitorra való kirajzolása között. Minden esetben, minden implementáció ugyanazt csinálja, amíg nincs új képkocka, addig nem kezd bele új rajzolásba a kijelző. Erre van egy szoftver oldali implementáció, hogy a grafikus eszközillesztő kontrollálhassa ezt az értéket. Na most a Kepler ezt nem támogatta, ezért kellett a külső modul. A Maxwell támogatja, bár a működés nem változott, míg a Pascal esetében a HDR-es G-Sync már nem használja ezt a modult úgy, ahogy a korábbi hardverek, így itt már a feldolgozás végig a gépen belül marad (a'la Freesync, Adaptive-Sync, HDMI VRR). Ezért is tartott olyan sokáig kiadni a szoftvert rá, mert nem nagyon akart ez működni az FPGA-n, és az NV végül nem is erőltette, hanem inkább kizárta a munkából. Gyakorlatilag csak a licenc miatt veszi meg a kijelzőgyártó, mert HDR-es G-Sync esetében már nem működik, persze HDR nélkül G-Synchez még kell, de ehhez is lehetne írni egy olyan implementációt, ami inkább a GPU kijelzőmotorját használja. Hosszabb távon ez az ideális megvalósítás, mert számos előnnyel jár a monitorgyártók számára. Használható a GPU-ba épített képskálázás, egyedi OSD-t lehet alkalmazni, egyedi színfeldolgozással és egyedi bemeneti funkciókkal. Illetve az FPGA nélkül az NV is meg tudja csinálni azt, amit az AMD a FreeSync 2-vel. Szimplán kicserélhetik a Windows HDR pipeline-t, ami nem valami jó. Valószínűleg ez már megfordult a fejükben, amikor a HDR-es G-Sync alapjait letették.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#34185
üzenetére
Az is elég lenne, ha csak 200 dollár lenne a felár. De manapság a kijelzőgyártók, na meg a kereskedelmi csatornák már igencsak dobálják az 400-700-1000 dollárt pluszt is rá. Nem igazán ez a hardver szabja meg már a végtermék árát, hanem az, hogy az R&D szempontjából a G-Sync a saját hasznát termeli ki. Tehát amíg az összes többi kijelző között egységesen oszlik el az azokba ölt R&D, addig a gyártók úgy döntöttek, hogy erről a G-Sync-et leválasztják. Ez számukra egy biztonsági tényező, okulva a 3D Vision halálából.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34189
Abu85
HÁZIGAZDA
zovifapp111
#34187
Abu85
HÁZIGAZDA
válasz
zovifapp111
#34187
üzenetére
Ilyen formában biztos nem. Ez az NV-nek is egyre kevésbé éri meg. Azzal nem mennek sokra, hogy prémium fícsőrnek tartják. A HDR-es G-Sync esetében nem sok céget győztek meg. Az Acer és az ASUS, ennyi. És ez már probléma nekik, mert például a prémiumért azért egy monitorgyártó elvárná, hogy többet tudjon, mint a FreeSync 2. De ehhez képest az NV megoldásából hiányzik a direkt tone mapping, illetve a Windows bugos HDR pipeline-ját kell használni a maga lilás beütésével. Értem, hogy prémium, csak nem tudni, hogy mire? A lilás árnyalatra? A direkt tone mapping hiányában a nagyobb késleltetésre és a kötelező kijelzőoldali tone mappingra? És akkor az ASUS és az Acer rak rá majd ezer dollár prémiumot, hogy a maguk oldalán azért ne legyen nagy kockázata ennek, így gyorsan visszahozza a beleölt pénzt, amire az európai kereskedők még raknak vagy 800 eurót, mert a luxuskategóriát luxushaszonnal árulják ugye. Legalább a Windows pipeline-ját meg kellene kerülnie az NV-nek, és akkor a lila árnyalat elkerülhető lenne, csak ez annyira körülményes, mert arra kell az NVAPI-ba egy kiegészítés, ami támogatná azt, hogy a játék egy meghajtóoldali pipeline-on kiküldje a képet, és ha már ezt megteszik, akkor amúgy mehetne rögtön a direkt tone mapping megjelenítés, tehát ott lennének, ahol a FreeSync 2, és akkor már csak arról menne a vita, hogy ér-e ez ~2000 dollárt.
Az MS-től nem tudom, hogy mennyire lehet amúgy a lilás beütésre megoldást várni. Az a vicc, hogy Xbox One-on ők is az AMD pipeline-ját használják, annyira jól sikerült a sajátjuk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34198
Abu85
HÁZIGAZDA
zovifapp111
#34190
Abu85
HÁZIGAZDA
válasz
zovifapp111
#34190
üzenetére
Igazából az a legnagyobb tévedés, hogy azt hiszed olyan világ jön, ahol választhatsz. Nem sajnos. Már a processzor kiválasztása meghatározza a GPU-t. Az Intel nem azért csinál dedikált GPU-t, mert hirtelen olyan nagyon fontos lett a VGA-piac, amikor évekig csak azt mondták, hogy elhanyagolható tényező. Azért lett fontos, mert a jövőben nem tudod majd odarakni a VGA-kat a procik mellé, hanem ott lesz a GPU a procival közös tokozáson. Így pedig már be kell nevezni, mert természetesen saját GPU-t akarnak a procijaik mellé párosítani. Szóval a jövő a jelenlegi útitervekben úgy néz ki, hogy ha kiválasztottad a processzort, akkor azzal jön a GPU és a memória. Később még az adattároló is. Szépen megkapod mindet a fémkupak alatt.
Ennek a legfőbb oka, hogy a CMOS-t nincs mivel leváltani. Elmegyünk 3 nm-ig, 2023-ben itt is lesz, és alapvetően nincs tovább (a 2 nm már nagyon elenyésző előnyt ad, az 1 nm pedig gazdaságilag értéktelen alternatíva). Elméletben sem lehet lépni, hacsak addigra valami CMOS alternatíva nem jön, de nem nagyon látszik semmi, ami 6-7 éven belül bevethető lesz. Szóval el kell kezdeni 3D-ben építkezni, és olyan terülteket fejleszteni, ahol van még potenciál, például a részegységek összeköttetésében. Aztán hosszabb távon, úgy 2030 környékén talán látni lehet majd valami CMOS alternatívát, amire át lehet állni. Az más kérdés, hogy a mai legózás nem biztos, hogy azzal visszatér.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
lezso6
#34199
üzenetére
Nem valószínű, hogy moduláris lesz a Navi. Lesznek benne GMI-k, de egészen más célból, nem azért, hogy négyet egymás mellé rakjanak egy tokozáson, hanem azért, hogy a CPU-kkal párosítsák. Szóval a Navi esetében még biztos lesz több dizájn a teljesítményre. A proci esetében ez a "szuperglue" koncepció sokkal kedvezőbb, mert nem heterogén megoldásról van szó, de a GPU-knál azért nehezebb szétbontani a rendszert.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#34205
üzenetére
Ez bizony nagy kérdés. De alapvetően azt is számításba kell venni, hogy ha a legózási lehetőséget elveszted, akkor az OEM is veszít a választható opciók közül. Lesz Intel CPU Intel GPU-val és AMD CPU AMD GPU-val. Tehát ebben a jövőképben nem csak a gyártók keverésének kiesése a probléma. Aztán a Microsoftnak is komoly szerepe lesz itt, hiszen ahhoz, hogy az NV megmaradjon itt, a Win32 API-t ki kell vezetniük, és a támogatást mondjuk át kell rakni az Azure-ba, így a legacy applikációk futtathatók maradnának a felhőben. Ezzel már lényegtelen lenne a CPU ISA-ja, jöhetnek a Qualcomm is, és az NV a saját ARM-os cuccával.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34218
Abu85
HÁZIGAZDA
zovifapp111
#34217
Abu85
HÁZIGAZDA
válasz
zovifapp111
#34217
üzenetére
Mivel a 7 nm-es node gyártási költsége eleve eléggé magas, így leginkább maximum ~400 mm2 közötti GPU-kkal fogunk találkozni. Ezek kerülnek majd annyiba, amennyibe a 12-16 nm-en az ~550 mm2-esek. De persze a költségeket figyelembe véve ideálisabb a 350 mm2 körüli maximum. Ez már egy nagyobb, HEDT tokozásra ráfér.
A Kaby Lake-G jóval gyorsabb a GT 1030-nál. Még az 1050 Ti-nél is jobb. De a Fenghuang Raven gyorsabb lesz a Kaby Lake-G-nél is. Az olyan 1060 szint, és az IGP. Persze elég sokat trükközik a rendszermemóriával, onnan azért sokat nyer.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34219
Abu85
HÁZIGAZDA
huskydog17
#34216
Abu85
HÁZIGAZDA
válasz
huskydog17
#34216
üzenetére
Bele van építve az Intelnél a pGPU árába az összes licenc (engedélyezett driverfunkciók/névhasználati jogok) és a támogatás. Egyedül a tesztelést nem végzi el az AMD, azt az Intel csinálja.
Az APU-k régóta ki vannak véve a mainline driverből, és csak a WHQL részei, vagy a régebbi modellek már annak sem. Ennek az oka, hogy nagyon nagy mennyiségben kerülnek eladásra a VGA-khoz képest, ami a gyártópartnerek support költségeit extrém mértékben megdobja. Az AMD évente kiad minimum 16, de esetleg 20 meghajtót, amik minden asztali gépre települnek, és a legolcsóbb gépeknél az árba nincs betervezve az, hogy a support egy meghajtó kiadása után user errorokat teszteljen, mert a lejelentett hibák 95%-a ez, miközben a kivizsgálásuk költséges.
A fentiek miatt az AMD átállt még az előző évben arra, hogy a saját WHQL csomagjaik között a köztes meghajtók a Windows Update-en keresztül jönnek az APU-kra. Ennek az előnye, hogy nagyságrendileg csökkenti a user errorok számát, mert a Windows automatikusan megoldja, de ha nem, akkor is a Microsoft supportját ostromolja a user, és nem az OEM partnerét.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34221
Abu85
HÁZIGAZDA
zovifapp111
#34220
Abu85
HÁZIGAZDA
válasz
zovifapp111
#34220
üzenetére
Nekem csak akkor fog tetszeni, ha értelme is lesz a lapkák közelebb helyezésének. Mert azért lehet igen komoly haszna is. De ha ezt nem használjuk ki, akkor inkább vesztünk.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34224
Abu85
HÁZIGAZDA
Petykemano
#34222
Abu85
HÁZIGAZDA
válasz
Petykemano
#34222
üzenetére
Amikor a vásárlók már nem pucolják ki a raktárakat.
(#34223) Csupingo: 125 wattba simán belefér. A csúcs Kaby Lake-G is 100 watt. Ebből a proci 45. 55 watt jön a leggyorsabb ottani AMD pGPU-ból. Persze az Intel itt érdekes skálázást is alkalmaz, így a proci képes 35 wattra csökkenteni az energiaigényét és akkor 65 wattot kap a pGPU. De ez fordítva is igaz, a proci elkérhet 60 wattot is, és akkor 40 marad a pGPU-nak. Az egész alkalmazásfüggő.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34227
Abu85
HÁZIGAZDA
Petykemano
#34226
Abu85
HÁZIGAZDA
válasz
Petykemano
#34226
üzenetére
A Fenghuang a Polaris 10/20 helyére jön.
Most eléggé alábbhagyott a bányaláz. Csak az eladott kártyák tizede került oda idén.
Majd az új Threadripperre lesznek ráizgulva ősszel. Az Moneroban 80%-kal is gyorsabb, mint a Vega 10.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyszerű. A JPR-nek eléggé jól kiépített csatornái vannak, így a kereskedőláncoknál vissza tudják keresni, hogy ki vette bányára. Lényegében eléggé egyértelmű, hiszen aki mondjuk egyszerre visz 4+ kártyát az biztosan bányász. Aztán azt is le tudják követni, hogy hányan vittek 2-4 között, és csak egyet. Az előbbi potenciálisan bányász, míg az utóbbi potenciálisan nem az. Erre vannak a statisztikákban hibakorrekciós modellek, amiket bevetnek. Végül lekérdezik a gyártókat, hogy mennyi VGA-t adtak el direkten a bányászoknak. Erről egészen konkrét adatok vannak. Az így kapott eredményeket összeadják és ki is jött a kívánt szám. Le van írva a teljes jelentésükben.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34244
Abu85
HÁZIGAZDA
Petykemano
#34242
Abu85
HÁZIGAZDA
válasz
Petykemano
#34242
üzenetére
Gyártó válogatja. Elsősorban a keleti gyártók küzdenek vele, akik főleg a nyugati piacot látják el, ott még ez a probléma nem ütötte fel a fejét, mert az európai bányászfarmok továbbra is jelentős pénzt raknak VGA-ba. Ezt a Sapphire-től tudom. Az anyavállalatuk még mindig több millió eurós megrendeléseket teljesít a bányászfarmok felé. De ez is befuccsol majd záros határidőn belül, ahogy a kínai bányászat tette. Valószínűleg ezért sem érinti még ez a probléma az AMD-t. Amíg ugyanis Európában a Sapphire szolgálta ki szinte kizárólag a bányászfarmokat, addig Kínában csak a TUL adott nekik Radeont, és ők is csupán az összes bányászatra vonatkozó eladás kisebb részéért feleltek. A többi tajvani gyártó GeForce-ot kínált bányászatra, abból lett extrém túltermelés. Az AMD-t valószínűleg úgy augusztus felé kezdi majd el érinteni ez a probléma.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34246
Abu85
HÁZIGAZDA
Petykemano
#34245
Abu85
HÁZIGAZDA
válasz
Petykemano
#34245
üzenetére
Pedig ez az a két szituáció, amikor nem éri meg kiadni. Az elsőnél azért, mert jól lehet vele keresni, míg a másodiknál azért, mert nagy veszteséget okozna. A kettő közötti állapot az, amikor ideálisan működik a piac.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#59036672
#34268
üzenetére
Hát ez az. Az NV eddig is rendkívül szűkre szabta a szivárgást. A pletykaoldalak kitalációból élnek, mert amiket megírtak és rákérdeztem, azokra az volt a válasz, hogy kamu. Ezért van már az év eleje óta mindig két hónapra az új GeForce megjelenése.
Ismerek olyan embert, aki tud mindent, csak nem meri elmondani, mert ezeket az információkat harmadik fél szintjén a világon alig egy tucat ember ismeri. Pont azért, hogy ha valakitől kiszivárog, akkor csak egy tucat ember lehessen a bűnös, és ott már könnyű halászni. Az AMD-nél és az Intelnél azért szivárogtatnak sokan, mert akár több száz ember is megtudhatja az új információkat egyszerre, vagyis rendkívül csekély az esélye annak, hogy valaki lebukik a szivárogtatásért. Ezzel az új NDA-val viszont még ha meg is szerezzük az infókat, akkor sem írhatjuk meg, különben ugranak majd a tesztre küldött VGA-k. Gyakorlatilag erről szól az egész, a már ma is rendkívül kontrollált rendszerük kap még egy külső védelmet.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#59036672
#34270
üzenetére
Szerintem sok függ attól, hogy a Vega 20-at milyen selejtaránnyal gyártja majd a TSMC. Imádkozz azért, hogy relatíve sok legyen az Instinctnek nem eladható GPU.
![;]](//cdn.rios.hu/dl/s/v1.gif)
(#34271) gézu: Nekünk ugyan nem. Tomék, WCCF-ék, meg akárkiék bullshitjeit nem akarjuk megírni. Már év eleje óta két hónapra van a megjelenés. Most mi az aktuálisan várt dátum, június 30? Erről az egészről ez jut eszembe: [link] - egy ilyen vonatra csak a bulvárújságok ülnek fel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34280
Abu85
HÁZIGAZDA
cskamacska
#34279
Abu85
HÁZIGAZDA
válasz
cskamacska
#34279
üzenetére
Amire lesz driveres megoldás azok készek. Például az IWD vagy a DSBR. Bár utóbbiból négy mód van, tehát az egyes játékok működhetnek akármelyik móddal, de a default ma már a binned.
A HSA már kész. Van rá implementáció. Itt le is tölthető: [link]
OpenCL implementáció van 2.0-ra, illetve a ROCm-ben van egy speciális hibrid OpenCL. Feljebb nem tudni, hogy mi lesz, mert a Khronos most elővette azt, hogy a Vulkant és az OpenCL-t egybegyúrja. Emiatt most mindenki ezt lesi, és várnak a fejlettebb implementációkkal, így a SPIR-V miatt az eredeti SPIR újabb verzióit nem nagyon építik be.
Az OpenCL, illetve alapvetően a HSA sem pusztán a GPU-ról szól, ugyanúgy futtatja ezeket a kódokat a CPU is. A PR nyomatta a GPU-s gyorsítást, de valójában mindig arról volt szó, hogy az adott kódrész a neki megfelelő hardveren fusson. Ez nem öli meg a CPU-t, csak valami jobb a GPU-ra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Annyit hozzá lehet még tenni, hogy az Intel, AMD, NVIDIA koncepciókat dolgoz ki. A hardver itt a legkevesebb, mert az számolni mindenképpen tud. Az elérés a kulcskérdés, de nem biztos, hogy azok a koncepciók terjednek el, amiket kitalálnak. Nagyon érdekes a culling, amire mindhárman kidolgoztak bizonyos megoldásokat, hogy gyorsítsák az occlusion culling folyamatot, ami egy rakás vektormatek, szóval számításigényes. Senkié sem terjedt el. Helyette jött a GPU-driven pipeline mellett a GPGPU culling. És hiába a sok kutatása a három nagy cégnek, a vezető irányzat ez lesz, és már az API-kban is megvan minden hozzá, hogy nagyon jó teljesítményű legyen (aszinkron compute, shader intrinsics/subgroups, execute indirect/indirect draw count ... a DX12/Vulkan ugyanarra eltérő neveket használ, de ugyanazt csinálják).
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#34289
üzenetére
Sajtó válogatja. Ha valaki megírta a pletykákat, vagy oknyomozott, ahogy a HardOCP, akkor ez nekik a világvége, de ők úgy sem írják alá, tehát végül mégsem.
Akik pedig aláírják, azok innentől kezdve jobban meg lesznek fogva. Tehát még ha a HardOCP ír is valami szaftosat, akkor azt sem lehet átemelni.
Azóta kicsit többet tudni erről, mivel vannak magyarázatok az új részekhez. A lényeg annyi, hogy az NV el akarja érni, hogy az új hardverekről csak a bejelentés napján lehessen írni. Előtte se pletyka, se szivárgás, se kódnév, se semmi, se az, hogy jön, mert ezt károsnak ítélik meg. Azt tényleg sajtó válogatja, hogy oknyomozók munkájának átvétele, illetve a pletykák megírása mennyire nagy probléma. Aki például nem írt a GPP-ről, vagy a next-gen GPU pletykákról semmit, annak az új NDA nem jelent változást.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
velizare
#34291
üzenetére
A nagyobbak közül biztos nem. És ez egy probléma az NV-nek. Nem véletlenül módosítják ezt most. Évekig jó volt, aztán hirtelen szigorítanak, ráadásul olyan kiegészítésekkel, ami nem egyértelmű. Honnan tudja az újságíró, hogy mi az NV számára kedvező hír? Számukra az is rossz, ha valaki kiszivárogtatja, hogy a következő héten ilyen-olyan fasza funkciót kap az érkező driver. Hiába a pozitív hangvétel, ez simán megszegi az új NDA-t.
Beszéltem pár újságíróval, és lényegében az lesz, hogy számukra a teszthardverek kellenek, az NV hírek pedig le lesznek csavarva a hivatalos bejelentések szintjére. Túl általánosan fogalmaz az új NDA, hogy kockáztassanak a pletykákkal, szivárgásokkal, stb. Annyit még mondtak páran, hogy az biztos, hogy az oknyomozó dolgokat megírják továbbra is. A pletykákat el tudják engedni, az újságírói szemmel nézve nem jelentős tényező, de a többit nem. Nekem is hasonló a véleményem. Az nem különösebben hasznos az olvasóknak, hogy már év eleje óta két hónap múlva jön az új GeForce, de a GPP például fontos volt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34294
Abu85
HÁZIGAZDA
cskamacska
#34293
Abu85
HÁZIGAZDA
válasz
cskamacska
#34293
üzenetére
Nem tudom, hogy miért kellene rábeszélni a Vegára, ha GeForce-ot akar, de itt van pár érv, ha nagyon szeretnéd elérni nála ezt:
- ha elfogy a 8 GB VRAM, akkor a Vega esetében csak egy csuszka segítségével beállít a driverben minimum 12 GB-ot (az ő gépével maximum 16 GB-ot) ... ha WHQD-re lő, akkor ez már erősen megfontolandó, látva azt, hogy mennyit VRAM-ot zabáltak az E3-on prezentált egyes játékok
- ha HDR-t akar, akkor egyedül Radeonnal tudja megkerülni a Windows HDR pipeline-t, amivel lehetőség adódik a közvetlen tone mappingra ... ennek a hátránya, hogy játék oldali támogatás kell, de a Far Cry 5 kezeli
- ha érdekli a villanyszámla, akkor a Chillel egészen extrém szélsőségek között konfigurálható a rendszer fogyasztása, teljesítménye, és még nagyon alacsony lesz az input lag is ... [link] - itt ugyanazt csináltuk a kijelzőn, ugyanaz volt az élmény is, de a fogyasztás teljesen más szintPersze a legjobb, ha hagyod őt választani, és nem beszéled rá semmire.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34320
Abu85
HÁZIGAZDA
huskydog17
#34319
Abu85
HÁZIGAZDA
válasz
huskydog17
#34319
üzenetére
Na miért fogyna el? Mert mondjuk a Microsoft Residency Starter Library működik ugyan, de megfelelő átalakítás nélkül borzasztóan memóriapazarló? Ugyanez igaz az AMD VMA-ra. Szóval hiába vannak ezek a libek az explicit API-k memóriamenedzsmentjéhez, elsődlegesen a teljesítményt célozzák, és nem a memóriával valós spórolást. Ezért beszél már március óta a Microsoft és a Khronos képviseletében az AMD arról, hogy vigyázzanak, mert az új játékok, amiket fejlesztenek, marhára elkezdték zabálni a VRAM-ot, holott közel sem kellene annyi erőforrás neki.
Alig van HDR-t támogató játék. Ha ezer lenne, akkor nem úgy állna hozzá a Microsoft, hogy ráérnek Windows HDR pipeline problémáit javítani majd hónapok múlva is.
Próbáld ki a Chillt. Megfelezi az átlagos fogyasztást. Linkeltem is, hogy mi történik, ha ugyanazt csináljuk, és nézd nyugodtan a fogyasztásmérőt. A látott eredmény pedig ugyanaz volt, miközben a fogyasztás gyakorlatilag GTX 1060 szintre csökkent.
Nem véletlen, hogy a kínai iCafé megrendelések megnőttek a TUL felé, mert Chillel iszonyat sokat tudnak spórolni a villanyszámlán. Az viszont kétséges, hogy otthoni környezetben ez érezhető lesz-e. Nyilván egy internetkávézóban, 100-150 géppel számít, ha jobb a hatékonyság, de otthon egy géppel nem nagy kunszt. Én sem a kisebb fogyasztásért használom, hanem a scene pacing miatt.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#34327
üzenetére
Ma már ez annyira nem számít, mert a GPU-k képesek az órajelüket szabályozni, tehát ha belefutnak a beállított hőmérsékleti limitekbe, akkor egyszerűen csökkentik az órajelet, amíg jó nem lesz a helyzet. Szóval ha nem is akármilyen, de lényegében elég széles tartományt lefedő hűtővel is üzemképesek a mai VGA-k.
Az ITX-es GeForce-oknak az egyetlen baja, hogy nagyobb a meghibásodási arányuk a normál verziókhoz képest. Bizonyos modelleknél jóval. Nekünk is tönkrement a laborban egy ITX-es GeForce (egyem a szívét pont teszt közben
), pedig alig hajtottuk, aztán kiderült, hogy nem egy strapabíró szerkezetek sajnos, más is panaszkodott rájuk. Igazából, ha nagyon számít a hely, akkor persze megvehető, de inkább egy normál. Nem sok különbség van az árban, és kevesebb rájuk a garis panasz.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34355
Abu85
HÁZIGAZDA
huskydog17
#34343
Abu85
HÁZIGAZDA
válasz
huskydog17
#34343
üzenetére
[link] - olvasd el hogyan működik, és láthatod, hogy sebességmérésre nem alkalmas, mert alapvetően a bemenet határozza meg a számítás mennyiségét. Az iCafe driverben viszont alapértelmezetten aktív.
Finomhangolni bármit lehet, de scene pacing nélkül megközelítőleg sem nyersz vele annyit. Ez nem finomhangolás ugyanis, hanem egy eltérő számítási módszer.
Amikor tönkrement a mi ITX-es 1070-ünk, akkor néztük, hogy nagyon magas a hibaarány a kereskedőnél ahol vettük, és ez jellemző volt a többi ITX-es modellre is. A normál modelleknél viszont átlagos volt a panasz. Nyilván, ha ezt az elején tudjuk, akkor nem is veszünk ITX-es 1070-et, mert lett volna hely a nagyobbnak, de akkor még nem volt annyi adat róla a kereskedőnél. Beszoptuk, ez van.
Ha van hely a házban a nagynak, akkor érdemes azt venni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34361
Abu85
HÁZIGAZDA
huskydog17
#34357
Abu85
HÁZIGAZDA
válasz
huskydog17
#34357
üzenetére
Ezért mondtam, hogy olvasd el azt az oldalt, ugyanis ha elolvasod világos lesz számodra is, hogy a teljesítmény attól függ, hogy mennyire rángatod az egeret. Tényleg érdemes elolvasni, nem csak a brute force módszer létezik.
Nem vonok le következtetést, de a 19%-os meghibásodási arány szvsz sok volt (azóta 32,4% - [link] ). Mondjuk az eladási mennyiséget nem ismerjük, tehát lehet, hogy kis mennyiségben volt a magyar piac extrém peches. Mindenesetre mi inkább nem kockáztatunk újra. Szopni pedig szoptunk, mert teszt közben ment tönkre, így oda lett minden korábbi eredmény.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34376
Abu85
HÁZIGAZDA
->Raizen<-
#34374
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#34374
üzenetére
Ez DX12 alatt erősen programfüggő is. A meghajtó csak korlátozott mértékben segíthet. A drivernél elsődlegesen azért volt látható egy időben javulás az NV-nél, mert az AMD DX12 meghajtója máshogy van felépítve. Nagyon röviden arról van szó, hogy a gyártók számára szabad az implementáció kérdésében trükközni. A Microsoftot és a Khronost addig érdekli a dolog, amíg az adott implementáció átmegy a hitelesítési teszten, de arra magasról tesznek, hogy a hardverhez közel a driver mit csinál.
Az AMD megoldása egy tipikus KISS koncepció, keep it simple, stupid. Maga az explicit implementáció egy közös rétegben valósul meg, amit PAL-nak hívnak. És ez a Mantle óta létezik, azóta fejlesztik, van benne egy rakás pénz, és ami a legfontosabb, kb. 5 év tapasztalat. A Vulkan és a DX12 csak egy ICD-vel van a PAL fölé húzva. Tehát mindkét API esetében az alapréteg ugyanaz, vagyis ha ezt fejlesztik, akkor egyszerre javul a Vulkan és a DX12 meghajtó is. Ezt a rém egyszerű modellt azért alkalmazzák, mert annyira nehézkes a külön reagálni az API-kra, hogy rengeteg erőforrást vinne el a natív megközelítés, de így az erőforrásokat arra fordíthatják, hogy a PAL réteg legyen nagyon gyors.
Az NV megoldása ma már nem ilyen egyszerű. Régen ők is furcsán közelítették meg ezt, volt amikor a Vulkan API-t az OpenGL alól hívogatták, de a DX12-t is megpróbálták költséghatékonyan beintegrálni, de egyik sem sikerült. A mai meghajtóval már natív Vulkan és natív DX12 támogatás van átlapolásra vonatkozó rétegezés nélkül. Ennek az előnye, hogy tényleg specifikusan lehet az implementációval az API-kra reagálni, viszont hátránya, hogy a sok trükközés miatt egészen bonyolult a kód, és a karbantartása sokszorosan több pénzbe és humánerőforrásba kerül. Emellett ugye a mostani implementációk alig egy évesek, vagyis a tapasztalat alapján beépített teljesítmény is kevés bennük. Ezért tudtak az elmúlt évben sokszor javítani, mert akkor még csak pár hónaposak voltak az implementációk, és könnyű volt sebességet találni. Ahogy telik az idő, ez egyre nehezebb lesz, mert függetlenül attól, hogy kívülről nem látszik, azért a háttérben a kód fejlődik, és bizonyos változásokkal mikromásodperceket nyernek helyenként.
Az Intel DX12-es megoldása hasonló az NV-hez, de ők a Vulkan esetében csináltak egy érdekes dolgot. Hasonlóan rétegelték az implementációjukat az AMD-hez. Emiatt nagyon érdekes, hogy a DX12 implementációjuk nem annyira erős, de a Vulkannál a mostani kód hihetetlenül jó. Valószínű, hogy a jövőben döntenek majd arról, hogy a DX12-nál megoldják azt, hogy írnak egy kliensoldali modult a Vulkan implementációhoz használt hardverhez közeli rétege fölé. És akkor a DX12 implementációjukkal is áttérnek a KISS-re. Ezzel ugye az a baj, hogy élesben csinálják a váltást, ami egy csomó meglévő programnál hibát generálhat, de valószínűleg a hosszabb távú hatásai megérik. Látva azt, hogy mennyire jól működik a Vulkan driverükben a hardverközeli réteg, egyértelmű, hogy nem éri meg szenvedni a jelenlegi langyoska DX12 implementációjukkal.
Egyébként nem biztos, hogy az NV-nél jelenleg működne a KISS megoldás. Biztos van oka annak, amiért ők ezt kerülik, annak ellenére is, hogy az AMD-nél általánosan, míg az Intel Vulkan driverénél látványosan jól működik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nyilván NV DX12 meghajtó.
Bocsi.De reggel nem akartam annyira elkapatni a hsz-t, de van még egy rakás probléma, például a memóriatípusok szempontjából az implementáció kialakítása. Na most az egy külön marha nehéz téma. Főleg azért, mert annyira eltérnek az implementációk, hogy nehéz mindenkinek jó megoldást találni.
Nézzétek meg Vulkan alatt (DX12 is ugyanez kb.): Intel - AMD - NVIDIA
És akkor erre kell írni egy memóriamenedzsmentet a programból, ami mindhárom gyártó implementációjával jól működik. Alig lehetetlen.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
cl.aci
#34392
üzenetére
Az NV D3D12 implementációja miatt. Nem igazán szereti, ha egy D3D12 leképezőt egy adott játékba teljesen a Microsoft ajánlásai szerint írnak meg. Ez lehet hardveres vagy szoftveres probléma is, de az látszik, hogy az Intel és az AMD meghajtójának ez egyáltalán nem gond. Valószínűleg később ezt a gondot megoldják, és onnantól már az NV-re is a D3D12 lesz a default, de ezt nem olyan egyszerű ám az alkalmazás oldalán kezelni. Írtál valamit az MS ajánlásai szerint, ami speciel az NV-nek nem jó, vagyis írni kell valamit az NV ajánlásai szerint, ami egyébként most még jó is, mert az Intel és az AMD dizájnja erre sem érzékeny, tehát lehetett volna helyből sok kisebb parancslistát használni. Elég sok D3D12-es játék működik így.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#34411
üzenetére
Hivatalosan nem kapta meg sosem. Engedélyezték, de ha valami problémád van a G-Sync+GT 1030-cal, akkor mossák kezeiket. Megmutatják, hogy a specifikációban a G-Sync-re "NO" van írva.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ahhoz, hogy ez számítson FCAT-tal kell mérni. A presentek közötti mérésnél ezek a beállítások nem módosítják az fps-t.
Nem valószínű, hogy ez egy driverhiba. Az lehet a gond, hogy az NV a Microsoft HDR pipeline-ját használja, míg az AMD mindenhova berakatta a saját natív pipeline-ját. Tehát a Microsoft pipeline-jának többletterhelésétől menetsülnek, mert megkerülik az egészet. Nem véletlen, hogy a Microsoft Xboxon sem a sajátját, hanem az AMD HDR pipeline-ját használja. Lényegesen jobb, mint amik ők összehoztak. De OS frissítésekkel ez helyrehozható, vagy az NV-nek is szüksége lenne egy natív pipeline-ra, amit aztán a fejlesztők beépíthetnek. Igazából az a fő kérdés, hogy miért nem fejlesztettek ilyet alapból.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ilyenkor be kell állítani a 60 Hz-et. A tesztre vonatkozóan úgy sem számít. Persze a HDR sem, a Windows pipeline-jának annyira lilás hatása van, hogy rosszabb lesz az egész, mint az SDR.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Akik pedig aláírják, azok innentől kezdve jobban meg lesznek fogva. Tehát még ha a HardOCP ír is valami szaftosat, akkor azt sem lehet átemelni.
Ú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.
- Galax GeForce RTX kártyák jönnek a szűkösebb házakba
- Kínai, és egyéb olcsó órák topikja
- Xiaomi Mi 9 SE - csúcsimitátor
- Metal topik
- Házimozi belépő szinten
- Kerti grill és bográcsozó házilag (BBQ, tervek, ötletek, receptek)
- Energiaital topic
- Vezetékes FÜLhallgatók
- Debrecen és környéke adok-veszek-beszélgetek
- Háztartási gépek
- További aktív témák...
- Üzletből, garanciával, Macbook Air Retina 13" 2020, 8GBRAM 256GB SSD magyar bill
- Lenovo ThinkStation P330 Workstation: 3D tervezésre (CAD), videó vágásra, animációk készítésére(DCC)
- ASUS ROG STRIX RTX 3070 8GB
- Eladó ASUS ROG STRIX SCAR II GL704G kishibás gamer notebook
- ÚJ! // ÁR ALATT! // Edifier S3000 MK II // Muziker garancia
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen