Hirdetés
-
Perelnek a vallásos kripto-piramisjáték miatt
it Két kriptocéget perel New York államügyésze, mert több mint 1 milliárd dollárral károsították meg az áldozatokat.
-
SGF24 - Remekül fest a Phantom Blade Zero
gp A Summer Game Fest utolsó játéka nem más volt mint a PC-re és PS5-re készülő játék, amelyhez még mindig nem kaptunk megjelenési dátumot.
-
Computex 2024: szimpatikus Montech billentyűzetek a porondon
ph A vállalat egy olcsóbb fajta, két színben választható, vezetékmentes modellel és két érdekesen festő koncepcióval jelentkezett.
Új hozzászólás Aktív témák
-
#33788
Abu85
HÁZIGAZDA
Petykemano
#33786
Abu85
HÁZIGAZDA
válasz
Petykemano
#33786
üzenetére
GPGPU felé azért mennek most, mert az mindenkinél van. Tehát ha írnak egy GPGPU-culling megoldást, akkor az kompatibilis az összes konzoltól kezdve, az összes compute shadert támogató GPU-n át, az összes compute shadert támogató IGP-ig. Egy irtó univerzális megoldás multiplatform szinten, még akkor is, ha van nála jobb. Emellett fejleszthető is. Egyszer megírod, és a "hovatovábbal" ráérsz majd két év múlva foglalkozni. Addig optimalizálod, beépíted a subgroup/wave intrinsics függvényeket, kihelyezed asszinkron computera. És ezektől még a módszer univerzális jellege megmarad.
Ha nem egyezik meg a piac, és mindenki lezárja magát a saját linkjére, akkor eleve megszűnik a gyártók keverése. Nem is tudsz majd VGA-t venni. Megkapod a GPU-t a CPU-val közös tokozásban. Az meg tökmindegy, hogy háromféle link van. A program oldaláról ezzel nem kell különösebben foglalkozni. A leglassabb sebessége is messze több, mint amire ma képes a PCI Express, de még a készülő 5.0-t is felülmúlja, és akkor ezek is gyorsulnak a jövőben.
Oké most ez teoretikus lesz. Tehát amerre megy a Microsoft, és amilyen jól működik a texel shading, én egyáltalán nem tartom kizártnak, hogy a PCI Express és a gyártók külön linkjei jól el lesznek egymás mellett. Legalább az asztali szinten. Mobilban nem, ott túl kicsi a hely, de asztalon simán meg lehet csinálni azt, hogy veszel egy Intel vagy AMD procit, ahhoz jár ugye a GPU a tokozáson, és az már egy komplett rendszer. De teszem azt egy texel shading leképezőt használó játéknál az árnyalási fázis függetleníthető a raszterizálástól, tehát azt szépen szétszedi a program, és a fő GPU-d marad a tokozásban, míg az árnyalásra befogsz egy VGA-t a PCI Express porton, de akár befoghatsz 20-at is. Maga a texel shading marha jól skálázódik. Ugyanígy a sugárkövetés. Az is egy nagyon jól függetleníthető feladat. Nem kell azt azon a GPU-n elvégezni, ami éppen a képet rakja ki a kijelzőre, és ennek a skálázódása is igen baráti. És itt lehet igazából keverni a gyártókat is. Láthatod az AotS-t, az is támogat multi-GPU-t AMD+NV rendszeren, tehát technikailag ennek nincs akadálya. Az más kérdés, hogy üzletpolitikailag x gyártó mondhatja azt, hogy az én piacomon y gyártó nem szívesen látott szereplő. De tényleg, a szoftver oldaláról sok dolgot lehet csinálni, még akár nem is jelent ez jelentős többletmunkát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#33819
Dtomka
veterán
Petykemano
#33818
Dtomka
veterán
válasz
Petykemano
#33818
üzenetére
Az egész regényedből csak erre reagálok.
"a jót meg kell fizetni." Akkor szerinted az normális dolog, h egy ~100 000 ft os vga majdnem 2x annyiba kerül?
ASUS STRIX-GTX1060-6G-GAMING GeForce GTX 1060Szerintem meg lehúzás...
A jót meg kell fizetni...
Igen én semleges vagyok, hisz sosem volt és nem is lesz rajtam 1ik féltől sem az a bizonyos szemüveg. Azt veszem ami a legjobb ár\teljesítmény nekem.
[ Szerkesztve ]
-
#33821
Dtomka
veterán
Petykemano
#33820
Dtomka
veterán
válasz
Petykemano
#33820
üzenetére
Írtam én olyat, hogy az AMD béna? Nem azok, csak 1 másik úton indultak el és nem vált be.
Az áremelkedést a bányászláz okozta. Vagy szerinted más oka volt? Ők is éltek a lehetőséggel...jól tették. Kisebb cég, sokkal rosszabb helyzetben vannak.Az Nvidia valóban elhúzott, (Fermi után a jelenlegi sorozat előtt le a kalappal!) de erre írtam, hogy remélem az AMD összekapja magát.
-
#33879
cl.aci
aktív tag
Petykemano
#33877
cl.aci
aktív tag
válasz
Petykemano
#33877
üzenetére
Ő mindent is tud.
"bakker ez tényeg egy fadoboz, azt hittem csak viccelsz"
-
#33893
smc
addikt
Petykemano
#33892
válasz
Petykemano
#33892
üzenetére
Akkor jöhetnek a föld alatti fények.
![;]](//cdn.rios.hu/dl/s/v1.gif)
5600X 2x16GB 6800XT | i5-3570 2x4GB 1050TI | MS Surface Book | iPad Pro 12.9 | iPhone X | iMac e2008
-
#33894
Abu85
HÁZIGAZDA
Petykemano
#33892
Abu85
HÁZIGAZDA
válasz
Petykemano
#33892
üzenetére
Nem alkalmasak. Maximum denoisingra jók.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#33896
Abu85
HÁZIGAZDA
Petykemano
#33895
Abu85
HÁZIGAZDA
válasz
Petykemano
#33895
üzenetére
Nagyon szép a marketing, csak ha megnézed a DXR-t, akkor az jelenleg csak 16 és 32 bites lebegőpontos formátumot támogat. A tensor magok 8 bites fixpontos ALU-k.
Eleve az AMD mondta, hogy ők is tudnak rá drivert csinálni, GCN3-tól felfelé van is már tesztcsomag. Egyébként egy olyan dologról vitázunk, aminél a Remedy elmondta, hogy 1920x1080 pixeles felbontáson, pixelenként egy sugarat, virtuálisan maximum 4 méteres távolságig kilőve a számítások nagyjából 5 ms-ig tartanak. Na most egy sugár az nem sok, és a 4 méteres távolság sem az, tehát iszonyatosan szűk térben alkalmazható technikáról van szó, ami a 60 fps-hez mért képszámítás harmadába kerül és akkor ez csak Full HD. 4K-n ez 20 ms, ami a 30 fps-hez mért képszámítás kétharmada. És akkor még nem számoltál semmit, amit ki tudnál rakni a kijelzőre.
A packing alkalmazható a DXR-en belül, hiszen támogatott a shader modell 6.2 16 bites lebegőpontos formátuma. Persze ettől az ég óvjon minket.
Elmondom neked, hogy miért csinálják ezt a sugárkövetést a gyártók. Az AMD-nek és az NV-nek is ugyanaz a koncepció mögötte. Mindegy, hogy DXR, vagy Vulkan-féle GPUOpen, vagy egy esetleges Vulkan szabvány, a probléma az, hogy a PC-s GPU-kat a jövőben nem igazán lehet úgy skálázni, hogy ne növekedjen meg a multiprocesszor:raszter arány. Viszont ahogy távolodsz a konzolok arányától, ami amúgy 8:1 körüli, úgy lesz egyre több idle lyukad az architektúrában. Tehát tök jó, hogy megvan a GPU-ban az ALU, csak a shadereket nem olyan multiprocesszor:raszterre optimalizálták, amilyen az új, erősebb GPU-ké. Viszont a sugárkövetés egy marhára függetleníthető folyamat a raszterizációtól, vagyis meg tudod azt csinálni, hogy ezt felhasználod az idle lyukak betömésére az aszinkron compute segítségével. Ettől még mondjuk egy újabb, mondjuk 16:1-es arányú GPU nem lesz jobb grafikára, de van egy rakás szabad ALU kapacitása sugárkövetést számolni.
Nagyjából ennyi a koncepció mögötte.Egyébként ez a sugárkövetéses dolog nem rossz, csak lesznek majd olyan árnyoldalai, hogy ha nem lesz meg a teljesítmény, akkor maga a sugárkövetéses rész a programon belül túl egyszerű, hogy bármit is elvegyél belőle, emellett a 32 bites lebegőpontos formátum eléggé zabálja a memóriát is (értem a 16 bit opció, csak aki látott már ilyet, az tudja, hogy nem éppen reális), miközben van erre sokkal jobb formátum is, ami pont nem támogatott. Tehát iszonyatosan kell majd a memória, ami miatt félő, hogy kisebb textúrarészletességet szállít a fejlesztő, vagy rosszabb minőségű modelleket, mert azzal a sugárkövetés memóriaigényét is levágja. Vagyis összességében többet vesznek majd el a raszterizálás minőségéből, mint amennyit a sugárkövetés egyáltalán hozzá tud tenni az egészhez. Nézd meg a Metro Exodust sugárkövetéses trailerét.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
-
#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.
-
#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.
-
#34021
Raymond
félisten
Petykemano
#34020
Raymond
félisten
válasz
Petykemano
#34020
üzenetére
Nem, a Hot Chips-en csak a mar bemutatott es piacradobott termekekrol beszelnek es a bemutato cimeben "mainstream GPU" van ami nem a Volta.
Privat velemeny - keretik nem megkovezni...
-
#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.
-
#34117
rumkola
veterán
Petykemano
#34116
rumkola
veterán
válasz
Petykemano
#34116
üzenetére
LOOOOOL
-
#34123
s.bala31
őstag
Petykemano
#34116
s.bala31
őstag
válasz
Petykemano
#34116
üzenetére
Jelenleg NVidiám van mert amikor vettem sokkal jobb ár/teljesítmény mutatója volt mint az AMD termékeinek (most is). Nagy csalódás volt akkoriban számomra az AMD Vegája. Legközelebb is zöld oldalról fogok választani ha jobban meg fogja érni általuk gyártott gpu-val szerelt VGA-t vásárolni, függetlenül attól mit "derítenek ki" a cégről ilyen-olyan jútyúberek meg firkászok.
[ Szerkesztve ]
-
#34124
Milka 78
nagyúr
Petykemano
#34116
Milka 78
nagyúr
válasz
Petykemano
#34116
üzenetére
Jaja...német kocsit se vegyél,mert lopnak,csalnak,hazudnak.Az F1-be (és a valós életben is) a Renault és a Ferrari ipari szintű kémedéssel szerez plusz infókat,elszipkázza az értékes embereket és megkerüli a szabályokat unferr módon megkerüli, így a full PSA és Fiat konszer is kiesett.Ideje lenne már felkelni és nem idealizálni,vagy démonizálni egy céget,mert mindegyiknek van vaj a füle miatt
-
#34134
Milka 78
nagyúr
Petykemano
#34132
Milka 78
nagyúr
válasz
Petykemano
#34132
üzenetére
Te meg kimeríted azt a tábort akinek lövése sincs a világ működéséröl és érzelmi alapon választ terméket,de se baj ilyen honfitársak is kellenek
Mint mondtam vannak győztesek és vesztesek.Ez egy ilyen játék.Van aki jól játsza és bevet minden piszkos trükköt és van aki nem.Ennyi.
Ezt az Intel/gpu-t meg majd visszaolvassuk mondjuk 2-3 év múlva,csak aztán nehogy ez is olyan mester féle,nem teljesült jóslat legyen[ Szerkesztve ]
-
#34145
s.bala31
őstag
Petykemano
#34131
s.bala31
őstag
válasz
Petykemano
#34131
üzenetére
Kinek az érdekét kéne néznem amikor vásárolok magamnak egy VGA-t, az AMD-ét mert "szegényeket" megszívatták az exmérnökeik?
Ugyan már, ez szerintem nem így működik a vásárlók többségénél. Amennyiben az Intel letesz az asztalra egy ár/teljesítményben elfogadható terméket simán megveszem és az sem fog különösebben érdekelni ha csak tőlük lehet majd VGA-t venni. Mellesleg ezt úgy sem fogják engedni a hatóságok, hogy egyszereplőssé váljon a VGA piac. Én optimista vagyok -
#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.
-
#34231
Yutani
nagyúr
Petykemano
#34230
Yutani
nagyúr
válasz
Petykemano
#34230
üzenetére
Majd az ASRock csinál 6-8-10 CPU foglalatos bányászdeszkát!
#tarcsad
-
#34243
Yutani
nagyúr
Petykemano
#34242
Yutani
nagyúr
-
#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.
-
#34248
Yutani
nagyúr
Petykemano
#34247
Yutani
nagyúr
-
#34249
Kolbi_30
őstag
Petykemano
#34247
Kolbi_30
őstag
válasz
Petykemano
#34247
üzenetére
Mindjárt beugrik manbal meg a másik 😂😂 Erről is Soros tehet 😂
You want some birth control, you can smoke a cigarette.
-
#34460
imi123
őstag
Petykemano
#34459
imi123
őstag
válasz
Petykemano
#34459
üzenetére
Nem ám.Főleg újan 70-ért.
A Zotac logó az 1070-esemen most is pirosan világít.Nosztalgia.Tévedni emberi dolog, de állati kellemetlen.
-
#34473
#59036672
törölt tag
Petykemano
#34472
#59036672
törölt tag
válasz
Petykemano
#34472
üzenetére
Ez azért így nem korrekt mert ha az nv mondjuk Laborghini akkor a Régebbi (ATi) Radeonok bizony Ferrarik voltak.
Pl: az én Ati Radeon (Sapphire 5870 Toxic) kártyám akkoriban kettéhugyozta az Nvidiat. Röhögtem sokat az nv tulajokon akkoriban. Sajnos számomra még mindíg az a teljesítmény/minőség a Benchmark.
AMD lerak az asztalra egy ilyen kártyát és még aznap eladom a gtx-et.[ Szerkesztve ]
-
#34477
Abu85
HÁZIGAZDA
Petykemano
#34475
Abu85
HÁZIGAZDA
válasz
Petykemano
#34475
üzenetére
Mert nyolcmagos. A motorba építettek deferred contextet, de csak NV-n aktiválják, viszont így az NV driver máshogy viselkedik, mint az IC manuális többszálúsággal. Az AMD utóbbit használja, vagyis a magok számának növelése valós eredményhez vezet. Az Intel IGP-i is az utóbbit használják.
A következő generációs GeForce parancsmotorjából már rengeteg aktuális funkciót kivágtak, és az általános data path-ok szélesebbek, így az sem igényel majd specifikus optimalizálást a skálázódáshoz, vagyis ott is mehet majd az általános kódút.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34480
Crytek
veterán
Petykemano
#34479
Crytek
veterán
válasz
Petykemano
#34479
üzenetére
AMD meg lehozza Ryzenbe a 32 magos ripper feriket....azt lesz itt minden csak nem rip...
Next PC Upgrade: 2022
-
#34482
Erdei88
veterán
Petykemano
#34479
Erdei88
veterán
válasz
Petykemano
#34479
üzenetére
PótLake....
-
#34513
cskamacska
addikt
Petykemano
#34512
cskamacska
addikt
válasz
Petykemano
#34512
üzenetére
Az van már Vega megjelenése óta.
és ha már Vega
Miért nincs 200000 alatt egy Vega sem Árukeresőn?
Mintha már nagyobb lenne a választék, de az áraik jól láthatóan felmentek, pontosabban nem mentek le. Ződ oldalon a GTX 1070 továbbra is 140-150, 1070Ti 150-160, 1080 180 ezer forinttól, az árak nem nagyon változtak.[ Szerkesztve ]
"Para mis amigos todo, para mis enemigos la ley"
-
#34555
Abu85
HÁZIGAZDA
Petykemano
#34554
Abu85
HÁZIGAZDA
válasz
Petykemano
#34554
üzenetére
A sugárkövetés alapvetően nem egy tensorban megvalósítható dolog. Az FP32-es számítás, ráadásul a DXR aktuálisan érkező verziója 32 bites vertex formátumot támogat csak, vagyis ha nem butítasz nagyon a geometriai részletességen, akkor 10+ GB VRAM a belépő. A második DXR verzió fog több vertex formátumot támogatni, de az leghamarabb jövő tavasszal jön, de az is lehet, hogy csak egy év múlva, mert rengeteg más szempontból is változás lesz a DXR-ben, ami már eleve megtöri a kompatibilitást, tehát célszerű, akkor egyben újrakezdeni.
A fixpontos dot product a denoising szempontjából előnyös a DXR-ben, de ott is valami szabályozást akar az ipar, mert az AMD például már bejelentkezett a 4 bites megoldásával, amit a DXR specifikáció elfogad, de az NV szerint kellene egy minimum érték. Nekik ugye 8 biten kell ragadni a hardverük miatt, ami azt jelenti, hogy az AMD sokkal gyorsabb lesz a Vega 20 4 bites formátumával. A 8 bites fixpontos dot product egyébként egy reális szabvány lehetne, de mivel az AMD-nek már van 4 bitre is alkalmas hardvere, így csípőből ellenezni fogják, vagyis leginkább annak van most realitása, hogy az NV és az Intel is elkezd vadul menni a 4 bites formátumra.
Jelen pillanatban a DXR mögött rengeteg a kérdés. Már csak a hardver oldali implementáció miatt is, mert a Microsoft nem nagyon akarja szabályozni ezt, ők úgy vannak ezzel, hogy adnak egy specifikációt, aztán nézik a végeredményt. Azt nem igazán akarja a cég meghatározni, hogy a végeredmény előtt mit csinálhat a hardver. Az MS szempontjából akár varázsolhat is, ha a végeredmény megfelel a követelményeinek. Az NV azonban szabályozást akar, méghozzá úgy, hogy a Microsoft kötelezően írja elő, hogy fixpontos dot product számításokat egy külön ALU-csoport végezze. Ebbe például az AMD és az Intel helyből nem fog belemenni, mert ők például ellenzik ezt a megoldást, ugyanis ha így lenne meghatározva a specifikáció, akkor tranzisztorok milliárdjait költenék egy olyan részegységre, amely grafikai szempontból csak egy specifikus működés mellett hasznos, máskor pedig csak a helyet foglalja. Ezzel szemben az AMD és az Intel a fő ALU-kba építi bele a fixpontos dot product támogatást, vagyis ha erre nincs szükség, akkor azok a tranyómilliárdokat elfoglaló ALU-k mást számolnak. Az NV-nek érthető, hogy ez miért nem tetszik, a architektúrájuk ilyen formában hátrányba kerül, mert ha egy játék nem használ majd DXR-t, akkor semmit sem fog érni a hardverben található rakás fixpontos dot product ALU. Ráadásul a denoising esetében a Microsoft nem igazán határoz meg semmit. Emiatt az AMD lehet, hogy nem is DL TOPS-szal implementálja, hanem SAD/QSAD/MQSAD megoldással, amit visszamenőleg meg tudnak oldani az összes GCN-re.A másik probléma ebből a szempontból a Vulkan API. Amire szintén van egy nagyon érdekes sugárkövetési megoldás. És ott az a fő gond, hogy azt az AMD írja, és nem egy szabványalkotó. Ráadásul nem lehet megcsinálni driverben azt, hogy ezeket a feladatokat a hardver ne futtassa le, vagyis az NV és az Intel is kénytelen elviselni mindazt a terhet, amit az AMD saját megoldása rájuk rak. És a DXR-hez képest a Vulkan AMD-s megoldása nem az API kiegészítése, hanem egy API feletti réteg, így a meghajtó oldalán nem befolyásolható, úgy fut a program egy hardveren, ahogy az AMD akarja. A DXR ebből a szempontból sokkal általánosabb, hiszen a Microsoft lehetővé teszi a saját fallback layerét, illetve a gyártó bármikor írhat rá drivert, amiben sok dolgot befolyásolhatnak. Ilyen formában a DXR nem igazán veszélyes, mert specifikált megoldás, amit egyenrangú felekként támogathat minden IHV. A Vulkan feletti Radeon Rays sokkal veszélyesebb, mert még ha a Volta tudná is futtatni sokkal hatékonyabban, akkor sincs meg az az úgymond híd, amivel ezt meg is tudják valósítani.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Dandris
tag
válasz
Petykemano
#34568
üzenetére
Pontosan, csak meló közben nehéz így megfogalmazni. Köszönöm
Abu: Egyébként nézhetjük a prey megjelenést, amit biztosan egy amd kari megjelenéshez lett kötve ugye
-
#34570
Abu85
HÁZIGAZDA
Petykemano
#34568
Abu85
HÁZIGAZDA
válasz
Petykemano
#34568
üzenetére
Szakmai szinten kezdjük ott, hogy az NVIDIA-nak nincs ray-tracing megoldása. A DXR egy Microsoft szabvány. Semmi köze az NVIDIA-hoz. Az RTX csak egy név, ami a DXR drivert takarja, de ilyet más is írhat, akár el is nevezhetik sugárbébinek. Tehát egy olyan dolgot nem lehet szidni, ami nem is létezik.
Az AMD-nek van egyébként saját ray-tracing megoldása Vulkan API-ra. Az valóban nem szabványos, annak ellenére sem, hogy amúgy minden hardveren működni fog, hiszen a Radeon Rays library van bekötve a Vulkan API fölé. Ez sem lesz más, mint a DXR, csak nem szabványos, tehát az AMD határozza meg, hogy miképpen futhat az egyes hardvereken, nem pedig az adott hardver gyártója, ahogy a DXR esetében.A legnagyobb probléma egyébként ezekkel a ray-tracing megoldásokkal, legyen az a Microsoft szabványa, vagy az AMD Vulkan fölé húzott koncepciója, hogy iszonyatosan erőforrás-pazarlók. Ez mindkettőre igaz lesz. És persze lesz itt 1 TB/s-os közel 600 TOPS-os Vega 20, vagy már van 650 GB/s-os 120 TOPS-os Titan V, stb, ezeket sokan nem fogják tudni megvenni. Pedig ezek azok a szintek, ahol ez a sugárkövetés realitás, de még így is 30 fps-ről van szó. Emellett a DXR csak olyan programot futtat, amiben az IR DXIL-ben van szállítva, amire pedig csak a dxc fordít, méghozzá csak új specifikációjú HLSL-t. Tehát a DXR használatához nem csak ezt kell beépíteni, hanem újra kell írni közel 300 ezer sornyi meglévő kódot. Nem véletlen, hogy annyira egyikre sem ugrott rá a piac, mert a DXR-nél közel másfél éves munkával jár egy meglévő motor portolása, és eközben Windows 10 Redstone 5 lesz a minimum igény. A mostani Redstone 4-re már azt fogja mondani az alkalmazás az indításnál, hogy "baszki ez nem elég jó ide". A Vulkan API-nál az AMD-s Radeon Rays megoldásának pedig ott a baja, hogy bár technikailag gyártófüggetlen, azért a backendet biztosító Anvil erősen úgy van megírva, hogy bizonyos AMD kiterjesztéseket igényel. Tehát persze be lehet építeni, még Windows 7-ig visszamenőleg is működik, de nem garantálható 100%-ig, hogy az effekt bekapcsol az NV és az Intel Vulkan implementációján.
Szóval nagyjából itt tart a ray-tracing. A DXR-rel lezárod a játékod az év végén érkező Windows 10 frissítésre, és aki nem használ ilyet, annak nem is érdemes megvenni a programot, mert nem fog elindulni. A másikkal pedig nincs garancia a 100%-os kompatibilitásra. Ettől függetlenül a SIGGRAPH-on is volt róla szó, hogy pár fejlesztőnél befizették mindkettőt, de pénz nélkül erre nincs értelme ráugrani. Különösen az AMD speciális megoldására, mert abból sose lesz szabvány. Szerintem kb. a Bethesda lesz az egyetlen, aki használni fogja, elvégre nekik az AMD csinálja az R&D-t.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34574
Crytek
veterán
Petykemano
#34573
Crytek
veterán
válasz
Petykemano
#34573
üzenetére
De hát te nem tudtad? Az nvidiának már nincs sok hátra mert az intel kivégzi őket.... Szóval hiába vezeti a benchmarkokat lassan már a múlté lesz a cég
Next PC Upgrade: 2022
-
#34576
Abu85
HÁZIGAZDA
Petykemano
#34573
Abu85
HÁZIGAZDA
válasz
Petykemano
#34573
üzenetére
Semmit nem tudunk arról, hogy a gyártók hogyan implementálják a DXR-t. Ezt ugyanis lehet fallback layeren futtatni, illetve írni rá egy specifikus implementációt. Annyit tudunk, hogy az NV a Volta-hoz ír meghajtót, míg az AMD a GCN-hez, de itt annyi infó még van, hogy a GCN3-tól más lesz az implementáció, mint a GCN3 alatt. Minden más hardver a fallback layert használja.
A teljesítmény szempontjából két tényező van. Lesz ugye maga a számítás. Mivel a DXR is ugyanazt csinálja, mint más raytracing framework, így hasonló lesz itt a teljesítmény, mint mondjuk a Luxmarkban, persze a raszterizáció miatt itt közrejátszik majd az aszinkron compute hatékonysága, hiszen nem csak a sugárkövetést számolják az ALU-k compute shaderben, hanem más feladatot is. A másik tényező például a denoising speciális végrehajtása. Ehhez lehet használni egy rakás implementációt. A Microsoft gyári implementációja egy SAD-re épülő technika, ami a fallback layeren belül működik. Az NV valószínűleg a tensor magokat használja majd itt, míg az AMD valószínűleg a saját dedikált SAD/QSAD/MQSAD utasításait. A Vega 20-ban valószínűleg valami kevert megoldást alkalmaznak majd, hogy hozzájussanak a 4 bites feldolgozás extrém sebességéhez. Szóval ezek a tényezők összességében határozzák meg a végső sebességet.
Az AMD Vulkan-hoz írt implementációja eléggé speciális. A teljesítménynél az a probléma vele, hogy az Anvilt az AMD saját magára írja, tehát tök oké, hogy elvileg működhet gyártófüggetlenül, de annyira magára tudja szabni az egészet az AMD, hogy nem fog annyira gyártófüggetlenül működni. Értsd ezt úgy, hogy amíg a DXR esetében a gyártó önállóan dönthet úgy, hogy bizonyos dolgokat felgyorsít egy gyártói implementációval, amihez ad egy drivert ki és megy, addig a Vulkan-féle sugárkövetésnél az NV-nek és az Intelnek az AMD-t kell megkérni arra, hogy ugyan gyorsítsák már fel rajtuk a sugárkövetést.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34587
szmörlock007
aktív tag
Petykemano
#34580
szmörlock007
aktív tag
válasz
Petykemano
#34580
üzenetére
Sőt, intelnél még pénz is lesz
-
#34599
Raymond
félisten
Petykemano
#34598
Raymond
félisten
válasz
Petykemano
#34598
üzenetére
Vagy ha olyannak "uzen" akivel nem akar uzletet kotni akkor az van a homlokan hogy SEMMI CUSTOM!
Privat velemeny - keretik nem megkovezni...
-
#34618
cyberkind
félisten
Petykemano
#34617
cyberkind
félisten
válasz
Petykemano
#34617
üzenetére
Ez a grafikon tökéletesen bemutatja mi is történt az 5k széria után, én 6990-ről mentem a jóval gyengébb 580-ra, azóta eszembe se jut az Amd mint videokártya, felém mindenképp rosszul csinálnak valamit jó régóta.
Paranormal Cocktivity
-
#34621
#59036672
törölt tag
Petykemano
#34617
#59036672
törölt tag
válasz
Petykemano
#34617
üzenetére
Sapphire 5870 Toxic
-
#34624
Abu85
HÁZIGAZDA
Petykemano
#34623
Abu85
HÁZIGAZDA
válasz
Petykemano
#34623
üzenetére
Nem időben. Akkor kellett volna, amikor Justin Rattner helyére magát jelölte. Ott rombolta le az Intel következő 5-6 évét.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34630
Abu85
HÁZIGAZDA
Petykemano
#34628
Abu85
HÁZIGAZDA
válasz
Petykemano
#34628
üzenetére
Azt jelenti, hogy a 2022-ben érkező Sapphire Rapidsban sem lesz gyorsabb p2p interconnect, mint 2019-ben érkező Rome-ban. És ez Krzanich döntése volt, elvégre ő felelt ezekért a tervekért Ruttner helyén. Ez pedig alapvetően meghatározza a skálázhatóságot. Most már ezzel nincs mit tenni, nem lehet csak úgy leállítani a fejlesztéseket. A Sapphire Rapids után lesz esélyük, addig a Rome is nagy falat lesz, hát még a következő Milan.
(#34629) Locutus: A 2070 játéktól függően úgy 15-25%-kal jobb az 1080-nál (legtöbb helyen inkább 15, de ha nagyon sávszéligényes a játék, akkor többel). A 2080 kb. hasonló az 1080 Ti-hez, hol gyorsabb, hol lassabb, attól függ, hogy mennyire terheli a ROP-ot és a memóriát a játék, mert ezekből sokkal kevesebb van a 2080-ban. A 2080 Ti pedig gyorsabb az 1080 Ti-nél úgy nagyjából 10-20%-kal.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34688
lezso6
HÁZIGAZDA
Petykemano
#34687
válasz
Petykemano
#34687
üzenetére
A RPM kimaradt. Azaz a 2x FP16/INT16 és 4x INT8.
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
#34701
Abu85
HÁZIGAZDA
Petykemano
#34700
Abu85
HÁZIGAZDA
válasz
Petykemano
#34700
üzenetére
A függetlenített int32 elsődlegesen ahhoz kellett, hogy sugárkövetésben ez egy, ha nem is nagyon sűrűn, de azért picit erőteljesebben használt operáció. Így az fp32-es shading mellett párhuzamosan lefuthat. Persze csak akkor, ha van elég regiszter hozzá, mert ugye ez még mindig probléma lesz, de legalább az elvi lehetőség adott.
Az 50% az L1-ből jön, de csak akkor, ha a futtatott shader kevés warpot tud használni a Pascal multiprocesszorán. Lásd a Vega esetében az LDS pressure, amitől a Polarishoz képest a Vega CU shader teljesítménye a duplájára nőtt. Na most a Pascal->Volta/Turing váltásnál nem volt közel duplázás, de azért az összevont cache az occupancy limites szituációkban simán hoz 50%-ot, ha a meghajtó úgy van beállítva, hogy a maximális warpot direkt limitálja, hogy azzal a cache partíción keresztül csökkentse az LDS/register pressure-t. Persze a legtöbb compute shadert úgy írják, hogy ne legyen occupancy limites a Pascal/Polaris és a még korábbi generációkon sem. De azért van már olyan compute shader, ami már az. Ezekhez az új, occupancy limitre kifejezetten ügyelő Vega/Volta/Turing dizájnok az ideálisak, vagy az Intel IGP-i, azok brute force tolják. A gyakorlatban pedig ezeket azért nem látod igazán, mert rengeteg shadert futtat egy alkalmazás, tehát teszem azt a shaderek 3%-ára az új multiprocesszor hatékonyabb, de az összesített teljesítményt inkább a maradék 97% határozza meg, ahol pedig eleve nincs occupancy limit, vagy nem annyira erős, hogy amellett még ne lehessen elfedni a memória késleltetését. Persze azzal, hogy a hardverek fejlődnek, a fejlesztők egyre komplexebb shadereket írhatnak, így pedig egyre több olyan shader futhat egy játékban, ami a régi dizájnokkal occupancy limites lesz.A DLSS az olyan mint az SS, csak nem mindenhol alkalmazza a rendszer. Igazából azért hoz sebességnövekedést, mert közben mást viszont nem úgy számol, ahogy natív részlegességgel amúgy tenné. Ezért van megjelölve a DLSS külön, mert a DLSS nélküli eredmény jelöli a natív részletességet. Ha natív részletesség mellett lenne alkalmazva a DLSS, akkor az extra számítástól csökkenne a teljesítmény, de pont az a lényege, hogy ne kelljen némelyik számítást elvégezi.
Ha ugyanaz a számítás az AMD és az NV között, akkor igazából a képminőség is 99%-ban ugyanaz. Egyedül a szűrés különbsége okozhat eltérést, de ez felfogásbeli különbség, illetve ebből a szempontból az AMD-nek van egy beállítása a driverben, ami annyit tesz, hogy ha a mintázat szűrésének minőségét a user "teljesítmény"-re állítja, akkor azt a minőséget kapja, amit az NV ad default. De az AMD default minősége még mindig eléggé sokban követi a Microsoft WHQL-es, mára már nem kötelező érvényű előírásait.
A különböző eljárások pedig különböző minőséget adnak. A főbb dolgokat összehasonlítottuk régebbi cikkekben (viszont ezek jó része nem alma-alma összehasonlítás, mert eltér maga az eljárás, tehát természetes némi különbség): [link] és [link][ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34704
b.
félisten
Petykemano
#34703
válasz
Petykemano
#34703
üzenetére
Az valami garázscég?
Látod azt a vigyorgó ZÖLD fejet ?
[ Szerkesztve ]
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
#34706
b.
félisten
Petykemano
#34705
válasz
Petykemano
#34705
üzenetére
Találó
"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Nagyjából ennyi a koncepció mögötte.
Mintha már nagyobb lenne a választék, de az áraik jól láthatóan felmentek, pontosabban nem mentek le. Ződ oldalon a GTX 1070 továbbra is 140-150, 1070Ti 150-160, 1080 180 ezer forinttól, az árak nem nagyon változtak.
Ú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.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs