Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
syberia
#36159
üzenetére
Nem. Alig kimutatható eladásért felel az RTX sorozat. A teljes termékskála 1%-át sem éri el. Ilyen kis volumenű termékek nem befolyásolják ennyire a tőzsdét. Sokkal inkább a bányászláz vége az, amiért megy lefele a részvényár. De ez nem valószínű, hogy tartós tényező lesz.
-
Abu85
HÁZIGAZDA
A fejlesztési költséget nem igazán szorította le egyik cég sem. A változás ahhoz kell, hogy a pénzt hasznosan költsd el. Nem mindegy, hogy funkciókba rakod, vagy az évek óta felpumpált kód megfelelő fejlesztésébe és tesztelésébe.
Kb. én is így voltam a driverekkel régen. Viszont a Chill annyira bejön, hogy már nem tudok nélküle élni. Nagyon sokat javít a késleltetésen, a fogyasztás csökkenése pedig csak extra. Én amúgy bízom abban, hogy a Microsoft ezt szabványosítja. Meg lehetne oldani. De valószínű, hogy egy nagyobb váltásnál az NV és az Intel is lemásolja, mert túl komoly előnyt jelent a fogyasztásra nézve.
(#36095) Zsébernardo: Szerintem messze az volt a legrosszabb. Ezt a vonalat nem véletlenül hagyták. A Radeon Software végre egy értékes fejlesztési irány, ami az Adrenalin verzióban eléggé odarakta. Az Omegához képest ez ég és föld.
-
Abu85
HÁZIGAZDA
válasz
#00137984
#36092
üzenetére
Szerintem az Omega az egy mélypont volt. Ott dönthették el, hogy ez nem mehet tovább, mert rengeteg volt a panasz, és nagy volt az elégedetlenség. Amióta Radeon Software-re váltottak azóta ugrott meg az elégedettség, ami mára stabilat 4,5/5 fölött van. Ez különösen igaz szerintem az Adrenalin sorozatra. Az egy egészen más szint.
Minden beállítást átmentettek a Settings vezérlőpultba, ami ott volt a Catalystben.
-
Abu85
HÁZIGAZDA
Nem mellékesek. Minél kevesebb pénzből biztosítja a meghajtó alapfunkcióit egy gyártó, annál több pénzt tud elkölteni ilyen-olyan fejlesztésekre.
Vulkan API-ra nincs RGP-hez hasonló, kihasználtságlimitet is mutató profilozója az NV-nek. Ha lenne, akkor nem váltották volna le a Unity és az UE4 fejlesztésének gépparkját Radeonra. Viszont mivel az NV egy hasonlót még be sem jelentett, máig sem, így nem volt sok választásuk. Az API-ra fejleszteni kell, tehát szerezni kellett olyan hardvereket, amin ezt meg lehet tenni. Nyilván a konzolos workflow eléggé időgyilkos, még ha ideig-óráig meg is éri. Egyébként az NSightba bele lehetne rakni, mert DX12-re például van, de Vulkan API-ra nincs. Valószínűleg nincs elég erőforrás erre, mert a hasznosságát nem lehet vitatni.
A Chill bármin segíteni tud. Az internetkávézók legnagyobb problémája az, hogy a gépeket működés közben hagyják ott az emberek. Ha fél óra múlva állították le, akkor addig csak úgy működött a rendszer és ugyanazt a képet kiszámolta mindig másodpercenként akár 140-150-szer. Emiatt van a Chillben input szerinti számítás. Vagyis, ha nincs input, akkor másodpercenként csak 30-szor is elég ha számol, hiszen ugyanaz lesz a kép mindig. Ezzel az átlagos fogyasztást igen durván csökkenti, szimplán hardver erre nem képest. Itt láthatod, hogy mekkora különbség van aközött, hogy ha áll a gép és úgy számol, illetve ha áll és aktív a Chill. [link] - ez az internetkávézóknak spórolást jelent.
-
Abu85
HÁZIGAZDA
Ők a driverben és az eszközökben látták lemaradást. Ezért kezdtek bele a Radeon Software-be és a GPUOpen kezdeményezésbe.
Egészen egyszerű dolgok történtek anno pár éve. A Catalyst vonalból kivették a pénzt. Teljesen átcsoportosították a rendszert, mert maga a Catalyst egy dinoszaurusz volt, és önmagában a legacy kódok fenntartása rengeteg pénzt elvitt. Ezt konkrétan elmondták nekem régebben. Figyelembe kell venni, hogy bár a kódbázis megtartása logikus döntés lehet, de bizonyos esetekben nagyon drága is. Emiatt úgy döntöttek, hogy dobják a Catalystet. Helyére jött egy jóval alacsonyabb költségből fejleszthető szoftver, aminek a karbantartására már nem kell annyi ember. A másik tényező pár éve az volt, hogy amikor az explicit API-t behozták, akkor úgy építették fel a drivert már a Mantle-re is, hogy két részre vágták. Lett egy hardverhez közeli, illetve API-hoz közeli része, és az előbbi implementáció megmaradt a DX12/Vulkan API-ra is, míg a kliensoldali kódot gyorsan át lehet írni. Ezen is rengeteg pénzt spórolnak, miközben nagyon gyors az összes explicit API-hoz az implementáció. És ezek nagyon kritikus döntések voltak, mert be is lehetett volna vele fürödni, viszont azzal, hogy a költségeket és az erőforrásigényt ezeknél a részeknél levágták, felszabadult egy rakás humán- és anyagi erőforrás extrákat csinálni, plusz még megvették a HiAlgót. Tehát effektíve az történt, hogy a Catalyst érához képest nem költenek igazán többen a driverre, mégis fejlesztettek pár olyan, általánosan működő szolgáltatást, amelyhez hasonlót más nem kínál, pl.: Radeon Chill, Radeon Overlay vagy AMD Link. Hasonlót egyébként pusztán elviekben tudna más is, de ez nem egy eldöntendő kérdés, mert ehhez elő kell teremteni a szükséges erőforrást, mind humán, mind anyagi szinten. Ha még ma is dinoszaurusz lenne a driver, akkor egyszerűen ezek a szolgáltatások csak elégetnék a pénzt. Olyan szinten megbonyolítanák a fejlesztést, hogy anyagilag nem éri meg beleinvesztálni az erőforrást. Amíg az Intel és az NV nem nyom egy resetet, addig például egy Chillhez, illetve egy bonyolult Overlayhez hasonló megoldás kigazdálkodhatatlan. És ez volt a legfőbb tényező, amiért az AMD megvált a Catalyst nevű dinoszaurusztól, ami nagy, agyontuningolt, éppen működő kódbázissá vált az évek során, ami lehet, hogy tette a dolgát, de ehhez olyan mennyiségű pénzt kellett elégetni, hogy az egész kontraproduktívvá vált. Az Intel és az NV még ragaszkodik a saját megoldásához, bár az NV ugye bevezetett egy külön programot a GeForce Exprience-szel, hogy nem az elavult kódbázisba építsék be az újdonságokat. Ez amolyan "nem is harapok a saját kezembe, de nem is nyalogatom meg" elvű döntés. Ugyanakkor a jövőben az Intel és az NV is váltásra lesz kényszerítve, mert egyre nagyobb gond nekik, hogy az AMD hozza be a faszántos funkciókat (nyilván tudják, hogy idén is lesz frissítés, ami megint hoz valami nagy újítást), amelyek nem is jelentenek nekik jelentős nagy terhet, viszont ezt nem tudják követni az elavult kódokra épülő csomagjaikkal. Ez volt az egyik tényező, amiben az AMD a gondot látta, és mára teljesen újjáépítették a meghajtót.
A másik tényező az volt, hogy hogyan kerüljenek be a fejlesztők gépeibe. Na ez egy nehezebb ügy volt, de itt alapvetően kihasználták azt, hogy az általánosan licencelhető motorok Vulkan API-ra váltanak. Ez egyrészt jó, de vannak olyan tényezők, amelyek nehézséget jelentenek. Például az, hogy a Vulkan API-hoz nem igazán van jól működő általános profilozó. Olyan semmiképpen, amely meg is mutatja a wave-ekre vonatkozó kihasználtságlimiteket. Ez baj, mert enélkül nem lehet a mai SIMT architektúrákra optimalizálni. És persze a konzolról át tudod valamennyire emelni a kódokat, de egyrészt mi van akkor, ha egy játéknak nincs konzolportja, másrészt azért nem egy ideális workflow egy PC-s játékot a konzolra lefordítani, az alapján optimalizálni, majd visszaportolni PC-re. Itt történt a másik váltás az elmúlt években, hogy a profilozók helyzete nagyon ramaty PC-n. Az AMD azt csinálta, hogy beleintegrált egy explicit API-hoz való profilozót a driverbe. Ilyet korábban senki sem csinált, viszont így egy külön csapat csak azon dolgozik, hogy amit az adott driver tud, ahhoz már legyen egy működő profilozó is azonnal. Egyszerűen csak aktiválni kell a devmódot, és ennyi. Ez az a pont, amiért a Unity és az UE4 fejlesztését átvitték Radeonra, mert így gyakorlatilag nincs szükséged a konzolokra ahhoz, hogy PC-re optimalizálj. És ez azért nagyon fontos, mert a Vulkan már elérhető egy jó ideje, de még ma is kizárólag az AMD kínál olyan profilozót, amivel tudsz kihasználtságlimitet elemezni. Ha GeForce vagy Intel GPU-t használsz, akkor ehhez a munkához szükség van egy X1-re vagy egy PS4-re.
Szóval alapvetően az AMD ebben a két dologban látta a problémát. A driver természetesen a saját portájuk volt, nyilván nem egy iparági gondról beszélünk, de persze számít, hogy a legacy kódok miatt mennyi pénzt égetsz el, amit el lehetne költeni hasznosan is. Viszont a profilozók helyzete egészen elhanyagolt, és ez már iparági léptékű jelenség.Volt egy harmadik tényező is, ami a kínai piac, kifejezetten az internetkávézók nézőpontjából, mert ott aztán van kereslet. Talán kevesen tudják, de a HiAlgót csak emiatt vették meg. A Chill kellett hozzá, hogy levigyék a fogyasztást igen alacsony szintre, miközben még javítják is a input lagot, illetve a látott élményen nem rontanak észrevehetően, ami a kínai internetkávézók kritikus szempont. Az persze más kérdés, hogy ha már kész volt a rendszer, akkor belerakták a normál driverbe is, de az üzleti döntés nem ez volt mögötte. Csak a végfelhasználói piacnak nem érte volna meg lefejleszteni. Nemrég ugye direkt erre jött hardver, csak az internetkávézóknak, és elég nagy az érdeklődés is, mert 100 gépnél már jócskán le tud faragni a villanyszámlából ez a funkció.
-
Abu85
HÁZIGAZDA
válasz
lezso6
#36004
üzenetére
Ha az ütemezést leszámítjuk, akkor kb. igen.
A skalárfeldolgozó igazából implementációs szabadságot biztosít leginkább. A jelenlegi API-kban az AMD azért érzi jól magát, mert benne van ez az egység a hardverbe, így nem kényszerülnek arra, hogy állandóan módosítsanak az implementációkon. Egyszerűen minden programozási eljárás alatt működik a hardver.
Hát, az igazából nem nagy különbség, hogy most vektormotort használ a hardver, vagy különálló streaming ALU-kat. A működési elv így is lényegében ugyanúgy SIMT.
(#36013) t72killer: Nagyon pici az az esély. Ha kiadás előtt nem léptek 4.20-as verzióra, akkor annak valami olyan akadálya van, ami túl drágává teszi a motor frissítését. Sok függ attól, hogy mennyire nyúltak bele.
-
Abu85
HÁZIGAZDA
válasz
t72killer
#35997
üzenetére
Ez azért van, mert az egyik legrégebbi UE4 verzió volt az alap, tehát alapvetően a technika alatta majdnem fél évtizedes. Ha mondjuk frissítenének 4.20-as verzióra, akkor sokkal jobban nézhetne ki, de nem tudom, hogy mennyi minden nem kompatibilis a játékukban az új UE4-gyel.
Ezeket érdemes figyelembe venni, mert az UE4 jelenthet igen régi kódbázist, vagy nagyon modernt is, utóbbi sokkal gyorsabb és sokkal jobban is néz ki. -
Abu85
HÁZIGAZDA
válasz
lezso6
#35970
üzenetére
Ez azért nem olyan pontos. Az ütemezés valójában egyik architektúrában sem 100%-ban hardveres, valamekkora mértékben van befolyása a drivernek is rá. A különbség annyi, hogy az NV a Keplerben sok dolgot átrakott szoftverbe, amit lassan visszaépítenek hardverbe. De ettől nem lesz teljesen hardveres.
Az LDS/L1 esetében is vannak elég nagy különbségek. A nyers számok önmagukban nem jelentenek sokat, mert a gyorsítótár elérése lehet lassú vagy gyors is. Emellett azért a Turing és a GCN manuális interpolációt használ, ami szintén az LDS-be lesz mentve, illetve a GCN-nél is csak a Vega, ami képes is használni a 64 kB-ot, míg a többinél ez 32 kB-ra volt statikusan korlátozva. Emellett itt még bejön a prefetch, mert az sem mindegy, hogy van-e előbetöltés, vagy nincs.
-
#35963
Abu85
HÁZIGAZDA
Petykemano
#35960
Abu85
HÁZIGAZDA
válasz
Petykemano
#35960
üzenetére
Rajanak ehhez semmi köze, ő nem igazán a grafikai divíziót vezeti az Intelnél, hanem a peremhálózati rendszerek menedzsere, amellett persze, hogy az alelnöke a "Core and Visual Computing" csoportnak, illetve a vezető mérnök.
Akik mennek (Darren McPhee, Tungler Antal, stb.), Chris Hook után mennek. Gondolom az AMD sem nagyon akarta marasztalni a "Mr. Poor Volta" teamet.Raja Gregory Stonert vitte magával, ő felelt az AMD-nél a ROCm-ért. Eközben viszont probléma volt, hogy le se szarta a SYCL-t, és emiatt az AMD több embere elment más céghez, hogy foglalkozhasson a SYCL-lel. Valószínűleg emiatt őt se nagyon marasztalta a cég, hiszen nem túl célravezető stratégia csak csőlátásban a ROCm-öt tolni.
Hardveres és driveres arcok maradtak az AMD-nél, őket nehéz robbantani onnan.
-
#35680
Abu85
HÁZIGAZDA
huskydog17
#35679
Abu85
HÁZIGAZDA
válasz
huskydog17
#35679
üzenetére
CPU. A VGA-teszt párhuzamosan ment. Ott 1080p, 1440p és 4K lesz. Viszont a CPU-tesztben látottak miatt átváltottunk Ryzen 7 2700X-re. Meg eleve gyorsabb a nyolcmagos Haswellünkhöz képest, és jövőre csak procicserével megoldható a 16 mag, tehát sok szólt a váltás mellett.
Úgy jön ide, hogy nem csak az RTX 20 jelent meg, hanem ugye jöttek CPU-k is. Az most más kérdés, hogy szívás, hogy mindet ideöntötték a gyártók gyakorlatilag ugyanakkor, de ez van.
Az a baj, hogy a mi játékainkkal abszolút nem látszik Full HD-ben a CPU-limit. Egyszerűen annyira máshogy skálázódnak a játékaink motorjai, hogy az lenne, ami a korábbi tesztekben, felsorakoznak a procik egymás alá. Persze választhatnánk nem túl jól skálázódó játékokat, ahogy a CB, de most 6-8 magos procikról van szó, pont a skálázódás a lényeg.
Ha kiadom a sajtótermék nevét, akkor tudod a személyt. De amúgy ezek közül egyik sem.
Voltak nagyobb különbségek is. Nem szimpla felsorakozás.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35673
üzenetére
De azt azért tudod, hogy alig tesztelünk DX11-es játékkal? Ez a múlt, mi pedig sosem kergettük a múltat. Írtam, hogy DX11-ben ez a probléma nem létezik, csak DX12 és Vulkan API-val jön elő. Itt is úgy néz ki, hogy azokban a motorokban, ahol nem épít a program root/layout leírókra. Legalábbis ezeket szűrjük le abból, amilyen eredményeket mi mértünk, illetve kaptunk ellenőrzésképpen.
Eleve nem tudjuk, hogy mi a probléma. Elképzelhető, hogy függ a Windows 10 októberi frissítéstől, vagy a 2080 Ti hozza elő, mert Pascallal nem tudta még megnézni senki. Mi sem. Csak annyit látunk, hogy az Intel processzorok 2080 Ti-vel, HD felbontásban, főleg Hyper-Threadinggel nem működnek jól. Ellenben a Ryzen kifogástalan. Nem tudjuk miért, de a Hyper-Threadinges dolgot RTX 20-ra más is jelezte. Persze talán nem volt szerencsés alig működő driverrel rendelkező GPU-val mérni, de a mérések előtt honnan tudhattuk volna, hogy valami gubanc lesz?
(#35674) huskydog17: Írsz nekik és kész. Mondtam. Nem zavar, ha válaszolnak, de én nem rakom ki a magánlevelezéseket. Nem érdekel, hogy nem tetszik, én sem örülnék, ha egy másik média munkatársa kiadná, hogy írt xy ügyben nekem, és beszélgettünk. Ez ránk tartozik, de ha mással beszél az ügyben, az szabad.
Senki sem mondta, hogy Full HD alá fog menni a játékos, de múltkor arra panaszkodtak az olvasók, hogy miért tesztelünk magas felbontáson procitesztet, ugyanis itt nincs köztük különbség. Most visszatértünk a régi modellhez, hogy akkor hozzuk ki a különbséget. De ha ez sem jó, akkor most már döntsétek el, hogy mi legyen.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Kérdés mit értesz engine limit alatt. Pár százalékot arra fognék, de nem 40%-ot. Vagy az Intelre külön be van írva, hogy alacsonyabban legyen az engine limit?
-
Abu85
HÁZIGAZDA
válasz
NewHope88
#35665
üzenetére
Az a baj, hogy sehol sem tesztelnek Full HD alatt. Ahogy mész a GPU-limites beállítás felé, annál kisebb a probléma hatása. Emellett nagyon fura, hogy nem minden játékban jelentkezik. Ahogy eddig kivettük leginkább azok a motorok érzékenyek rá, amelyek az explicit API-nál nem építenek a root/layout leírókra. Az is tök fura, hogy DX11-ben semmi jele a problémának. A RotTR pedig egy elszigetelt eset, ez a játék ugye kapott egy Ryzen patch-et, és az abba épített optimalizálásokat nem portolták vissza Intelre. Nyilván gyorsabb kódból gyorsabb egy proci, tiszta sor.
-
#35664
Abu85
HÁZIGAZDA
huskydog17
#35662
Abu85
HÁZIGAZDA
válasz
huskydog17
#35662
üzenetére
Magánlevelezésekre vagy kíváncsi. Kérdezzél rá egyenként a tesztelőknél. Olvasod a tesztjeiket. Ha ők elárulják neked, akkor nekem oké.
Egyrészt mi 1366x768-ban teszteltünk és 2080 Ti-vel. És még a Ryzen 5 2600 is nagy falat volt az i7-8700K-nak. Persze addig, amíg le nem tiltottuk a HTT-t. Utána rendbe is jött. De majd elolvasod a tesztben.
-
#35660
Abu85
HÁZIGAZDA
huskydog17
#35659
Abu85
HÁZIGAZDA
válasz
huskydog17
#35659
üzenetére
A játékosok közül nem sok embert érint. Ahogy mész a GPU-limites beállítás felé megszűnik a gond. Nekünk ez a CPU-tesztnél ütött nagyon szemet, mert ott HD-hez közeli volt a felbontás, és az CPU-limites beállítás több játékban is. Azt sem tartjuk alapvetően kizártnak, hogy az egészhez köze van az októberi Windows 10 frissítésnek.
Várd meg a CPU-tesztünket, ott ki lesz elemezve. A VGA-tesztet a biztonság kedvéért átraktuk Ryzenre, nem akarjuk, hogy emiatt az esetleges hátrány halvány esélye is felmerüljön a GeForce-okon. Lövésünk sincs, hogy miért viselkedik néha furán Intel procin a driver, így inkább nem kockáztatunk.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35647
üzenetére
A világ nem fekete-fehér, még akkor sem, ha ezt egyeseknek nehéz elképzelni. Attól, hogy valaki nem felkészült, még nem szükségszerűen hülye. Joker csak azt publikálta, amit mért. Az, hogy nem gyanakodott valami gondra a háttérben, és nem ellenőrizte az eredményeit, maximum jóhiszeműségre, illetve általános tapasztalatlanságra vall, de ettől nem lesz kötelezően hülye vagy troll. Szerintem eleve betegesen szélsőséges világlátás kell ahhoz, hogy ezt mondjuk valakire, aki csak videókat tölt fel a Youtube csatornájára.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35645
üzenetére
Pont a bla-bla-bla a lényeg.
Akivel kapcsolatban vagyok és kapott RTX 20-at. Egyszerűen nem tartottuk túl normálisnak, hogy a Hyper-Threading bizonyos játékokban, bizonyos beállításokkal, bizonyos magszám mellett és bizony órajelszinten csökkenti a teljesítményt. Emiatt ahol tudtam utánakérdeztem, hogy találkoztak-e ilyen furcsasággal. Minő véletlen találkoztak, de nem tudták hova rakni. Mi se, de legalább nem vagyunk egyedül. Arra próbálok rávilágítani, hogy a Joker Production is ebbe eshetett bele. Emiatt nem feltétlenül kell rögtön letrollozni egy embert, aki amúgy valószínűleg sokat tesz abba, hogy YouTube videókat készítsen a hardverek teljesítményéről, ugyanis lehet, hogy nem az ő hibája az, hogy az RTX 2070 nála nem teljesített. Vagy egy másikat, mert teljesítménycsökkenésről számol be a 399-ről 415-os driversorozatra váltva.
Mint írtam, ha nálunk problémamentes lenne a 416.33, vagy nem kaptam volna visszajelzéseket furcsaságokról, akkor azt mondanám, hogy az ő hibájuk, de így azért sanszos, hogy a driverrel nem stimmel valami. Hogy mi azt nem tudom, de van pár konfiguráció és szituáció, ahol nem azt hozza, amit kellene. Ezek a legrosszabb bugok, mert túl specifikusak ahhoz, hogy a kiadást megelőző teszten elkaphatók legyenek. Idővel persze úgyis kiszűrik, aztán lehet újratesztelni mindent.
-
Abu85
HÁZIGAZDA
válasz
NewHope88
#35642
üzenetére
Úgy egyszerű, hogy kapnak is hardvert, nem kell utánarohanni. Az a régió, ahova Magyarország tartozik nem célpiac. Ezt korábban kifejtettem már. Ilyenkor meg kell várni, hogy az NVIDIA partnerei hozzanak motyót.
(#35643) Raymond: Ja, csak éppen gyenge 4,7 GHz-re tuningolva, amire írtam, hogy nem mindegy a probléma szempontjából.
A helyzet az, hogy senki sem lóg ki a sorból. Másokkal is beszéltem erről, és hasonló furcsaságokról számoltak be. A különbség az, hogy a komolyabb médiáknak van lehetősége 5 GHz közelébe lőni a hatmagos prociját, vagy berakni egy nyolcmagos Intelt, esetleg váltani Ryzenre, míg valakinek van egy szem i7-7700K-ja, és abból él. Mit csináljon? Akassza fel magát? A bizniszt attól még pörgetnie kell, hogy a driver furán viselkedik.
Nem is tudom mi köze van hozzá... A 415-os sorozat tempóvisszaesését mutatja a videó egy Hyper-Threadinges procival egy 399-es driverhez képest. Nálunk furán viselkedik Hyper-Threadinggel a 416.33. Fura eredmények jönnek ki a Joker Productionnak egy Hyper-Threadinges procival. A saját eredményeinket látva, más médiát felkeresve hasonlók adatokat kaptunk. Áhhh... biztos csak véletlen, illetve "közismert trollok".
Amúgy félreértés ne essék valóban nem azt hozza Jokernek a 2070, amit kellene, de abban kételkednék, hogy ez 100%-ban az ő hibája. Ha nálunk nem lennének fura jelenségek a 416.33-mal, akkor elhinném, hogy troll, de most inkább azt hiszem, hogy van egy picike bugocska a driverben.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35639
üzenetére
Alapvetően nincs baj vele, csak vannak olyan fura szituációk, amikor egyszerűen lassít a Hyper-Threading. Nem minden játékban, nem minden beállításon, de valami gondja van. És ez látványosan kiütközik, ha a procinak nincs legalább nyolc magja, aktív a Hyper-Threading, nincs nagyon meghúzva, illetve Full HD vagy ez alatti a felbontás, de sajnos a gond WQHD-ben is mérhető. Fingunk nincs mi okozza, de a lassulás a Hyper-Threading kikapcsolásával megszűnik, vagy akkor, ha nyolcmagos az Intel proci, illetve hat maggal legalább 4 GHz fölé van húzva alapból. Biztos valami szoftveres probléma, mert túl specifikusan lép fel ahhoz, hogy a hardver okozza.
Azt se tudjuk, hogy szimplán az Intel proci mennyit árt. Az biztos, hogy Ryzennel mérhetően jobban érzi magát a 416.33. Lehet, hogy csak picit, de a 2080 Ti VGA-val a Ryzen egyeduralkodó lett a CPU-s game tesztekben, holott nem ez volt korábban a kialakult kép. Valami nem tiszta még a 2000-es GeForce-ok és a 415-ös driversorozatnál. Mondjuk mindegy, most ebből kell élni, de azért a VGA-tesztet átraktuk Ryzenre, hogy ott menjenek az új GeForce-ok, ahol jobban érzik magukat.
Ilyen szempontból viszont aki mondjuk nem tudja a 7700K-t lecserélni a teszthez, talán a Joker Production, akkor sajnos beleütközhet a problémába. Tehát nem 100%-ban az ő hibája ez. Sajnos új a hardver, új a meghajtó, lehetnek benne fura bugok. Egy-két hónap múlva jó lesz. Szóval nem tegyünk úgy, hogy először látunk helyenként nehezen értelmezhető teljesítményt az új VGA-któl. Az a ritka, ha minden rögtön flottul megy.
Az sem feltétlenül lehet vétetlen, hogy a Youtube-on megjelentek a videók, amelyek a 415-ös driversorozat lassulását mutatják. Például ez: [link] - hatalmas meglepetésre Hyper-Threadinges a procija.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35635
üzenetére
Vagy csak az a problémája, ami nekünk a 415-ös driversorozattól. Bizonyos játékokban, bizonyos beállításokkal az aktív Hyper-Threading 6 maggal vagy alatta, normál órajelen lassít. Full HD alatt látványosan megmutatkozik a probléma, Hyper-Threading off és rögtön jön a tempó a 2080 Ti-nek. A VGA tesztgépnél húztunk is Ryzenre, hogy alapvetően ne legyen gond, mert furcsa mód az AMD SMT-jével semmi baj nincs.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#35604
üzenetére
Ez ilyen. Hiába "turn up the light and just works" jellegű a dolog, azért a tartalom szempontjából igazodni kell hozzá, és a nem igazodsz, akkor néhol túlságosan fura jellege lesz az egésznek. Márpedig egy játék kiadás előtt pár hónappal nem fogják a újrakreálni a tartalmat, hogy egy effekthez jobb legyen. Örülnek, ha befejezik a fejlesztést időre.
(#35606) t72killer: Amiatt hibázna máshol is, de csak a Wolfi 2-re jellemző, ott is ritkán. Szerintem valami apró szoftveres gebasz lesz, csak nem tudni, hogy a driver vagy a játék.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Abból is.
Új konzolok még sokáig nem lesznek, és azokra sem úgy fognak átállni, hogy dobják a régieket. Tehát nagyjából 5 év múlva jön olyan Assassin's Creed, amiből már nem lesz PS4 és X1 port, vagyis tényleg lehet az új konzolokra tervezni.
Egyébként nem csak jövőre nem lesz új AC. Egy csomó kiegészítés lesz most legalább két évig. Ez még abból a szempontból is érdekes, hogy ilyen munkafolyamat mellett kialakítható lenne egy tényleg használható multiplayer. A játékban megvan erre a lehetőség, csak a sok rész tervezése mellett rendkívül kevés erőforrást kapott mindig is. -
#35373
Abu85
HÁZIGAZDA
huskydog17
#35372
Abu85
HÁZIGAZDA
válasz
huskydog17
#35372
üzenetére
Mert a primitive shaderre kérdeztek rá, amire azt válaszolta Corpus, hogy mostanában jönnek majd a játékok.
Az Assassin's Creed azért van képben, mert eleve a primitive shaderre az ötletet az Assassin's Creed Unity adta. Az ugyan compute shadert használt, de a primitive shader nem sokkal másabb, mint az Ubisoft által kitalált pipeline némileg hardveres formába öntve. Emiatt alakult át az új AnvilNext, ami az Odyssey alatt dolgozik, és emiatt kér kevesebb CPU-t, mint az Origins. Viszont az átalakítást hardveresen csak akkor lehet megtámogatni, ha lesz hozzá driver. Az Ubi ezért vitte eleve az Odyssey-t az AMD-hez, mert amit a Unity-ben régen kitaláltak, azt végre át akarják ültetni compute-ról hardveres szintre. Ez az ő ötletük, nyilván roppant módon örülnek, hogy van hardver is az ötletükre, és előbb-utóbb ki akarják használni.
A másik, hogy lehet erről még nem beszéltek, de az Odyssey nem igazán egy játék. Erre az Ubisoft egy alapként tekint, és 2-3 évig is ez lesz AZ!! Assassin's Creed. Tehát nem jön új cím, hanem tartalmat kap az Odyssey, évente többet is, méghozzá igen sokáig. Ez egy újszerű modell, mert érdemes kipróbálni, hogy mi a jobb. Évi egy AC, vagy egy AC több évig, és akkor annak a fejlesztése, kb. úgy, ahogy egy MMO-nál szokás. Ezt több forrásból is hallottam már.
-
#35369
Abu85
HÁZIGAZDA
huskydog17
#35367
Abu85
HÁZIGAZDA
válasz
huskydog17
#35367
üzenetére
Nem az AMD választotta az Ubisoftot, hanem az Ubisoft az AMD-t. Az előző évben az Ubi kötött egy megállapodást, hogy mindhárom IHV-nek megadják a lehetőséget, hogy dolgozzanak egy-egy címen. Ez döntötte el, hogy kivel lépnek partneri viszonyba. Az NV dolgozott a Ghost Recon Wildlandsen, az Intel az Assassin's Creed Originsen, míg az AMD a Far Cry 5-ön. A Far Cry 5 tetszett a legjobban az Ubinak, így az AMD maradt talpon. Eredetileg is az AMD címe lett volna a Assassin's Creed Odyssey, hiszen ennél dolgoztak a primitive shaderen. Ugye Richie Corpus a TGS-en mondta, hogy a primitive shaderes játékok mostantól jönnek, erre gondolt. De ugye ez nem működik automatikusan, kell hozzá a driver, hogy ez a fejlesztés aktív lehessen.
A korábbi döntés a jövőre érkező játékokat változtatta meg. A Divisiont például elvették az NV-től, és megkapta az AMD, illetve van még egy PC-re be nem jelentett űrhajós cím, amin az Intel dolgozott volna, de végül nem ők fognak. Ennek a PC-s portja el lett tolva. -
-
Abu85
HÁZIGAZDA
válasz
Crytek
#35342
üzenetére
A CPU-val nem lesz baj. Kevesebbet kér, mint az Origins, mert teljesen átrakták a cullingot GPU-ra. Ezzel a korábbi rendszer akadásait is eltüntették, de emiatt erősebb a GPU oldali terhelés, mert DX11-ben nincs aszinkron compute, ami itt nagyon kellene, illetve még nem érkeztek meg azok a meghajtók, amelyekkel a beépített újításokat aktiválhatják. Erre még heteket kell várni. Nagy kérdés, hogy ez hogyan fog működni, mert ilyet még soha senki nem csinált.
-
#35326
Abu85
HÁZIGAZDA
zovifapp111
#35308
Abu85
HÁZIGAZDA
válasz
zovifapp111
#35308
üzenetére
Nem teljesen ugyanannyit ér a VRAM más Resource heap szinten. Itt magának a játéknak nem igazán kell 2 GB-nál több VRAM, de egy Tier_1-es beállítással sokkal jobban szemetel, mint a Tier_2-essel, emiatt GeForce-on inkább 6 GB az a limit, ami kb. kezd jó lenni, míg Radeonon 4 GB-hoz közeli, de itt annyira a határon van, hogy számít a DCC hatékonysága is. Emiatt jók 4 GB-tal a Polarisok, és kevésbé az a többi Radeon.
Jó, hát ez az első játék, amit már dizájnban is a legmagasabb Resource heap és Resource binding szintekre optimalizáltak, tehát alapvetően természetes, hogy nem hozza a megszokott sorrendet, ahol messze nem volt ennyire extrém a terhelés az API felé.
(#35306) FLATRONW: Valamennyi optimalizálási lehetőség van a driverben is, de közel sem annyi, mint régen. Az a baj, hogy nagyban meghatározza ezeket a lehetőségeket az is, hogy az alkalmazást hogyan írták meg. Mennyire követték a Microsoft ajánlásait, ami például köztudottan rossz az NV-nek (kivéve a Turingnak), és innen nagyon nehéz kiszakítani a rendszert, mert csak szívnának vele, amikor jönnek a patch-ek a játékhoz. Nem véletlen, hogy a Turingot már a Microsoft ajánlásaihoz tervezték, elvégre nem mindig van lehetőség az NV saját ajánlásaihoz írni egy játékot.
-
Abu85
HÁZIGAZDA
válasz
lezso6
#35298
üzenetére
Meg másképpen is csinálják, ahogy az AMD. De a Turing esetében már jó. Ott az AMD-hez hasonló az NV megoldása is. A Pascal és a régebbi hardverekkel van gond csak. A Turing persze abból a szempontból nem szerencsés, hogy még eléggé kezdetleges az implementáció, elvégre ehhez a hardverhez megint egy új csomagot használnak.
-
#35073
Abu85
HÁZIGAZDA
Petykemano
#35071
Abu85
HÁZIGAZDA
válasz
Petykemano
#35071
üzenetére
Igen. De mint írtam, a hardveren belül ez egy kis áramkört igényel, plusz egy extra hardverállapotot. Tranzisztor szintjén nem igazán lehet több százezernél, ami elenyésző a mai sokmilliárd tranyós lapkáknál. Ilyenkor többet jelent a tesztelhetőség, mint a tranyóval való spórolás, mert ha először van hardvered rá, akkor először tesztelheted, és elsőként is jössz rá olyan limitekre, amelyek a második generációnál számítani fognak. A DX12 és a Vulkan API-ra sem azért az írja az AMD a leghatékonyabb drivereket, mert náluk okosabbak a programozók, hanem azért, mert nekik volt egy Mantle-jük, és mindenki előtt két évig tesztelhették, hogy mi az ideális stratégia erre. Bizonyos projekteknél fontos az idő, mint tényező, amikor egy újítást teljesítményét nem olyan nehezen befolyásolható tényezők határozzák meg, mint a compute, vagy a memsávszél. Utóbbi két esetben nyilván nem sokat lehet nyerni az idővel, hiszen eleve egy olyan tényező limitál, amivel nehéz mit kezdeni az általános fejlődésen túl. Egy primitive shader olyan dolog, amit nem igazán a compute vagy a sávszél fog limitálni, hanem sokkal inkább a szoftveres háttér, illetve a hardverállapotra vonatkozó optimális paraméterezés. Itt az idő sebességet jelent.
-
Abu85
HÁZIGAZDA
válasz
imi123
#35066
üzenetére
Másképp ezt aligha lehet megoldani. Ha a Khronos és a Microsoft nem vevő erre, akkor az egyetlen opció a Mantle átírása, mert az még egy elfekvőben lévő modern grafikus API, aminek lehet módosítani a grafikus futószalagját, elvégre az AMD kezében van a specifikáció. De amúgy a Khronos és a Microsoft miért ne lenne vevő erre? Persze a szabványosítás miatt ez egy kicsit időbe kerül, hiszen nincs semmiféle szoftveres fallback, de alapvetően a Vega és a Turing adott, amint megegyeznek a specifikációban a többiek, akkor szállítható rájuk egy alternatív grafikus futószalag. Meg ugye azokra a hardverekre is, amelyek még támogatni fogják. Hardveres szinten ez nem egy nagy varázslat egyébként, csak egy extra hardverállapot az egész, illetve egy kis extra áramkör a setupban (ami rém egyszerű is), de feldolgozók gyakorlatilag ugyanazok maradnak, ahogy eddig is.
-
Abu85
HÁZIGAZDA
válasz
imi123
#35062
üzenetére
Befizetni bárki be tudja. Az API-kkal van a baj. Nem engedik meg a futószalag ilyen mértékű módosítását egy szimpla kiterjesztésen keresztül. Szóval meg kell várni amíg a Khronos és a Microsoft kihozza azokat az API-kat, amelyek ezeket az újításokat már kezelik a futószalag szintjén is. Ez valószínűleg annyira nem lehet messze, ha az AMD-nek és az NV-nek is van már rá hardvere. Az eléggé valószínűtlen, hogy a két cég egymás, és az API-kat fejlesztő konzorciumok tudta nélkül csinált tök hasonló fejlesztéseket. Sokkal inkább esélyes, hogy már régóta megy ezekről a diskurzus a háttérben, és a Vega, illetve a Turing architektúra ezek hardveres alapján elkezdte bevezetni. Az csak pech, hogy ezek olyan módosítások, amelyek az amúgy eléggé érinthetetlen grafikus futószalagot módosítják, és ezekre nem reagált még a Khronos és a Microsoft.
-
Abu85
HÁZIGAZDA
Nyersen a számok alapján több a különbség, mint amit a 7-es és a 8-as mutat a nanométer előtt. De egy teljes lapka azért nem csak ezen múlik, sőt, ma már egyre kevésbé függ ettől. Szerintem az van, hogy az AMD és az NV is a legjobb nem EUV-s node-ot keresi. A TSMC viszont nehézkessé vált, mert ott a Qualcomm, az Apple, a HiSilicon, stb. Az NV-nek ez csupa olyan cég, amely ráígérhet az ajánlataikra, még az AMD is, hiszen nekik ott a marha nagy haszonnal árulható EPYC, ami még nagy piacot is céloz. Emiatt érdeklődhetnek inkább a Samsungnál, ahol a 8 nm-es opció a legjobb nem EUV-s node, és jóval kisebb a verseny a gyártókapacitásért.
Jó, de ezt nem értetek csinálják. Amikor a döntéseket meghozzák, akkor a legfontosabb szempont a legnagyobb haszon.
Valószínű, hogy az EUV elkerülhetetlen, de jelenleg úgy értékelhetik sokan, hogy még túl rossz hatásfokkal működhetnek a gépek, aminek a költsége ugye benne lesz a waferáraban. Talán másfél év múlva jobb lesz a helyzet. Igazából az NV nem kockáztat nagyot, hiszen a Samsungnál is van 7 nm-es EUV. -
Abu85
HÁZIGAZDA
Lehet, hogy nem a TSMC lesz az NV fő partnere a jövőben. Azt pletykálják, hogy a Samsung 8 nm-es node-jára utaznak, ami a 10 nm-es half node-ja. Bár nem új generációs node, mint a 7 nm, de sokkal olcsóbb rajta gyártani. Szvsz a 7 nm-t túl drágának tarthatják, főleg EUV-vel.
Szerk.: Extra érdekesség, hogy úgy néz ki a Navi sem az EUV-s 7 nm-t használja a TSMC-nél, hanem az EUV nélkülit, amit a Vega 20.
-
Abu85
HÁZIGAZDA
válasz
imi123
#34996
üzenetére
A konzol még mindig jelentősen másképp működik, mint egy PC. Akármennyire is megold dolgokat a DX12 és a Vulkan, nagyon messze vannak attól, amire egy konzol képes a legalacsonyabb szintű hozzáféréssel. Az Explicit API tehát csak segít a régi limitek feloldásában, de nem viszi le az elérést konzolszintűre. Azt nem lehet megcsinálni fix hardver nélkül. Meg ugye az Xbox One konzolokban is vannak olyan trükkök, mint a dupla parancsmotor, ami a PC-s hardverekben nincs, illetve az Xbox One X-ben a CPU ki van egészítve olyan fixfunkciós blokkokkal, ami egyszerűen tipikus grafikai szempontból fontos munkákat gyorsít. A PC-s processzorokból ezek is hiányoznak. Lehet, hogy egyszer lehozza ide a Microsoft ezeket, de amíg konzolon csak a saját hardverednek kell megfelelni, addig PC-n egyeztetni kell az összes gyártóval egy esetleges szabványról, mert anélkül csak állna a tranzisztor ebben a hardverben.
(#34997) imi123: Nem tudni. Annyira speciális a konzol, hogy akármit választhatnak rá a cégek. Szerintem a 7 nm már nem hoz annyit, hogy ezt erőből csinálják, ahogy mondjuk PC-n, szóval úgy gondolom, hogy a next-gen már igen sok olyan módosítást vihet a hardverbe, amelyek egy-egy tipikus feladatot gyorsítanak. Már a PS4Pro és az X1X esetében is egyre kísérletezőkedvűbb volt a Sony és a Microsoft, így megpakolták őket saját IP-kkel, amik sehol sem találhatók meg. Mivel ezt az AMD különösebb gond nélkül megoldotta, így szerintem a következő konzoloknál még több saját IP-t építenek be, vagyis még inkább egyediek lesznek a dizájnok. Ezzel azért a 7 nm mellett sokat lehet nyerni, mert arányaiban a fixfunkciós blokk a leghatékonyabb. Konzolon ez nem is probléma, fix a hardver, arra szabják a játékokat.
-
Abu85
HÁZIGAZDA
válasz
imi123
#34992
üzenetére
Nem azért lett fontos a proci, hanem azért, mert egyre több az explicit API-t nem csak használó, hanem kihasználó cím. Világos volt, hogy amikor ezt bevezették, akkor az volt a cél, hogy a többmagos rendszereket elkezdjék használni. Az Intel is hozza a mainstream nyolcmagosát, tehát nem egyedi dolog az, amit az AMD csinál. A következő szint majd a 16 mag lesz. Az Intel is nyomná ezt már 2019-ben, ha meglenne hozzá a gyártástechnológiája
-
Abu85
HÁZIGAZDA
Pont az, hogy ott nem limites. Direkt megnézettem egy Threadripperrel rendelkező emberrel a Forza Horizon 4 demóját, mert furának tűnt, hogy az AMD négymagossal teszteltette. Egy 16-magos Threadripperrel már a vizes Vega 64 nyakán volt az 1080 Ti még 1080p-ben is, nem kellett hozzá 4K. Szimplán 8-magos procival az 1080 Ti inkább a Vega 56-tal van pariban. Eközben a 4K-s eredmények nem változnak az extra nyolc magtól. Ez klasszikus CPU-limit. Azt is lehet tudni, hogy miért. Az NVIDIA aktuális DX12 implementációja a Tier_3-as bekötést nem támogatja hardveresen, de megoldják egy CPU oldali implementációval. A Microsoft ezt nem tiltja, alapvetően az Intel is így csinálja, csak ők az L3 cache-t is bevetik. Haszna ennek eléggé sok van, csak több processzorerőt igényel, de az NV többször utalt már rá a konferenciákon, hogy hosszabb távon többet nyernek ezzel a megoldással, mintha a hardvereikre szabott Tier_2 szintet használnák még ma is, na meg sok lehetőség van trükközni is. És alapvetően ez logikus, elvégre iszonyatosan megfizethető kategóriába kezdenek süllyedni a hat-nyolcmagos procik, és fél év múlva 16-magost is vehetsz mainstream foglalatba. Tehát amíg mondjuk ma még egy picit probléma számukra, az már holnap nem lesz az, és eközben élvezik a legmagasabb bekötési szint előnyeit. Emellett tudják nagyon jól, hogy a média úgyis a legjobb procical fog tesztelni, ahogy itt a Ryzen 3000, rárepülnek a 12-16 magra. Ezt megtanulták a DX11-es érából, hogy hiába kezelték jobban a deferred contextet, annak igazi haszna nem volt, mert a tesztek 4-5 GHz közé tuningolt Core-okat használtak. Most ők kezelik rosszabbul az új DX API-t, de ennek sem lesz igazi hátránya, mert a média számára ugyanúgy nyitva lesznek a lehetőségek arra, hogy 12-16-magos procikat dobjanak a tesztplatformokba. Tehát effektíve teljesen jó, amit csinálnak, mert ugyanúgy nem éri őket hátrány a tesztekben, ahogy az AMD-t sem érte igazán a deferred contextes DX11-es játékokban. Persze pár oldal előveszi majd, hogy mennyivel hatékonyabb már az AMD DX12 meghajtója négymagos procival, amire az AMD is ráerősít, hiszen folyamatosan küldözgetik a review guide-ot, hogy egy 7700K mellett az 1070 Ti, az 1080 és az 1080 Ti egymás nyakán vannak a Forza Horizon 4-ben, és ezért az NV drivere a felelős, bezzeg a mi driverünk mennyire szépen skálázódik már négymagossal is, tehát már ott GPU-limit közelébe kerülnek, de kb. annyi haszna lesz ennek, amennyi az NV-nek volt a DX11-es drivereiből, amikor ugyanez csinálták. A GPU-tesztek ettől még izomprocikkal lesznek levezényelve.
(#34990) namaste: Magasabb felbontáson az 1080 Ti is kezd GPU-limitessé válni. De ugyanúgy eléri a Vega 64-et 1080p-ben is, csak egy 16-magos Threadripperre van szüksége. Tehát a hardver működik, ha alárakod a procit. Tényleg nem viccből nyomatja a saját review guide-ját az AMD 7700K-val. Ott még a Vega 56 sincs meg az 1080 Ti-nek Full HD-ben. Okkal választották ezt a processzort. Tudják nagyon jól, hogy az NVIDIA drivere eléggé másképp bánik a processzor erőforrásaival, így ha Ryzen 2700X-re mennek az a Vegákon nem dob sokat, de az 1080 Ti-nek számítana. Szenyók ám ezek a cégek. Ha rákérdezel, akkor boci szemekkel nyomják, hogy de a 7700K az egyik legjobb gamer proci a magas egyszálas teljesítménye miatt.
Jaja az, csak a Forza Horizon 4-nek pont nem ez kell, és ezt ők nagyon is tudják. -
Abu85
HÁZIGAZDA
Te mondod, hogy innentől kezdve a Turingra lehet tervezni. Én pedig azt mondom, hogy nem, mert az egy dolog, hogy a Turing mostantól kevésbé érzékeny azokra a dolgokra amelyekre a Pascal, tehát egy Microsoft ajánlásai szerint megírt alkalmazás hasonló hatékonysággal futhat NV-n, mint Intelen és AMD-n, de a Pascal ezt a hatékonyságot sosem fogja elérni a mostani implementációval, szóval kb. semmit sem fog változni az NV ajánlása. Kivéve persze, ha nagyon ki akarják végezni a Pascalt, akkor borzalmasan sokat tudnak rontani a hardveren, de erre egyrészt nincs különösebb okuk, másrészt elég sokan elfogadták, hogy az NV ajánlásai az AMD-nek és az Intelnek irrelevánsak, tehát amíg a Pascal tényező, addig miért is ne lenne érdemes ennek kedvezni, ha a többi másik architektúrának ez nem fáj?
Nagyon egyértelmű, hogy hol mutatkozik meg. Ha nem lenne gond a driverrel, akkor milyen hardvere az NV-nek kb. úgy futna, ahogy az új Tomb Raider alatt. Ehhez képest ha csak egy picit nem követed az NV ajánlásait, akkor a Strange Brigade már hatékonyságot veszít, noha itt azért van még egy Vulkan leképező, tehát annyira azért nem volt hely a specifikus optimalizálásnak, de ott van még a Forza Horizon 4, illetve nemrég a World of Warcraft DX12 módja, ahol annyira nem működik az NV drivere, hogy amíg Intelen és AMD-n a DX12 a default, addig NV-n a DX11. Egészen egyértelmű, hogy amíg az AMD és az Intel implementációja az esetek jó részében működik, addig az NV implementációja borzalmasan kényes.
Itt nem ellene történő optimalizálásról van szó. Azért a Microsoft nem véletlenül ajánlja azt, hogy a root signature-ben ne legyen buffer view. Ennek az oka, hogy az API-t úgy alakították ki, hogy ezeket a leírótáblákba helyezzék a fejlesztők. Emiatt egy csomó SRV és UAV nem is helyezhető direkten a root signature-be, hiába írja a saját ajánlásába az NVIDIA, hogy számukra kritikus, hogy itt legyenek ezek az erőforrások. Tehát amikor azt látod, hogy egy alkalmazás nem az NVIDIA, hanem a Microsoft ajánlásait követi, lásd a World of Warcraft DX12 módja, akkor az azért van, mert olyan erőforrás-formátumokat használnak, amiket az API el sem helyezni a root signature-ben. Szóval nem az NV-nek akarnak keresztbe tenni, hanem úgy írták meg a motort, hogy az nem igazán működik az NV ajánlásaival. És tudják nagyon jól, hogy ezzel az NVIDIA rengeteg sebességet veszít, de nem tudnak ellene tenni. Az NV valamiért a DX12 implementálásának ezt a módját választotta, biztos megvolt rá nekik is az okuk, de ez bizonyos felépítésű programoknál eléggé rossz hatásfokú. Ezzel hardveres szinten nem tudnak mit kezdeni, a meghajtót kellene valahogy átírni, hogy jobban igazodjon a Microsoft ajánlásaihoz. Ez igazából a Pascal gondjait is megoldaná, csak most vizsgáld ezt a problémát az NV szemével. Az AMD régóta eléggé kész és eléggé gyors DX12/Vulkan implementációt kínál. Az Intel gyakorlatilag utolérte őket a Vulkan API-ban, és most megint nekifogni átalakítani a dolgokat, hát eléggé necces. Ma már több szól ellene, mint mellette, inkább megéri egy rakás erőforrást beleölni a specifikus trükkökbe. Sokkal bonyolultabb lesz a driver, tesztelni is sokkal nehezebb lesz, de nem kell újrakezdeni.
A Forza Horizon 4 problémája eléggé egyszerűen kezelhető. Ott egyszerűen kell még processzormag. Jövőre jönnek a 16-magos mainstream Ryzenek. Szóval az alapvetően megoldja magát. De egy 16-magos Threadripperrel már nincs az a limit, ami a mainstream CPU-knál tapasztalható. Ott már gyorsabb a Vega 64-nél az 1080 Ti, igaz nem sokkal, de picit gyorsabb. Ezért tesztelt az AMD négymagos CPU-val, amikor kiküldték a review guide-ot. Tudják, hogy az NV DX12-es drivere több processzorerőt igényel, mint a saját driverük, ami ebből a szempontból eléggé hatékony. Nyilván nem hülye cég az AMD. Tudják, hogy ha Threadrippert toltak volna az NV alá, akkor jóval kisebb lett volna a Vega fölénye. Ezekre érdemes felfigyelni, mert az ördög a részletekben rejlik.
Mi is emiatt alakítjuk át a teszplatformot, hogy jövőre könnyen tudjunk 16 magra ugrani, mivel úgy tudjuk, hogy az NV-nél a DX12 és a Vulkan alatti nagyobb processzorigény tartós lesz. Nyolc maggal egy Forza Horizon 4 simán limites, de jövőre 16 maggal már jóval kellemesebb lesz. Erről egyébként nagyon sok duma van a háttérben, hogy a Ryzen "3000"-et az NV nagyon várja, mert erőből megoldja a driverük egyik gondját, tehát azzal nem kell foglalkozni. Emiatt sem éri meg most nekik újraírni, mert aránytalanul nagy befektetést igényelne, miközben fél évre vannak az új procik, amelyek a mostaninál sokkal erősebbek. -
Abu85
HÁZIGAZDA
Továbbra is fontos, hogy sok helyen az NV ajánlásai számítsanak, mert attól, hogy a Turing jobb az explicit API-kkal a Pascal még nem az, és ha az NV ezt leszarja, akkor simán bezuhanhat az 1080 Ti a Vega 56 alá. Szóval itt sok változás azért az NV ajánlásaiban nem lesz.
A driver pedig más lapra tartozik, ott az NV eléggé le van maradva az AMD-hez képest. Hiányzik az a két év, amivel az AMD hamarabb kezdte meg ezt az irányt, és ez abban nyilvánul meg, hogy DX12 alatt kevésbé optimális a CPU-magok használata. A Forza Horizon 4-ben sem azért van a Vega 64 alatt az 1080 Ti, mert ennyire képes a GPU, hanem mert ennyire képes a driver. A felbontás növelésével ez a CPU-limit egyre kevésbé lesz meghatározó, és azzal jön is fel az 1080 Ti. Ezzel nagyon nehéz mit kezdeni általánosan, csak trükköket lehet bevetni, ami segítségnek segítség, de nem általános megoldás. De persze érthető, hogy mi a helyzet. Az AMD aktuális implementációja három éves, míg az NV-é egy. És ebben az is számít, hogy az AMD nem nulláról indult, míg az NV igen, emiatt is cserélték le egy éve az eredeti implementációt. Csak az új meghajtó borzasztóan érzékeny lett bizonyos dolgokra, amit természetesen lehet javítani, de ez nem pénz kérdése, hanem időre van szükség.Én azt sem tartom lehetetlennek, hogy kidobják a fenébe a mostani meghajtót, és a Vulkánt szelik fel úgy, hogy a hardverhez közeli rétegét célozzák egy DX12-es köztes réteggel. Az Intel lassan erre tér át. Az AMD pedig azt csinálja már a kezdetek óta, hogy van egy absztrakció a hardver fölött, és afölé húznak API implementációt. A korábbi tapasztalatok alapján ez tök hülyeségnek hangzik, de explicit API-val ez működik, és nem valószínű, hogy a nyers sebesség itt a kulcs, hanem az, hogy gyakorlatilag mind a két explicit API igen nagy részben közös kódon fut, vagyis elég ezt fejleszteni, és a gyorsulás jön mindkét API-ra vonatkozóan. A beleölt humánerőforrás hatékonysága szempontjából ez azért nem mindegy.
Az Intel Vulkan meghajtója iszonyatosan jó lett, míg az NV most írja át. Már látszanak a változások a korábbi meghajtókból is, egy csomó "PerStageDescriptor" limit lett sokkal nagyobb az elmúlt időszakban. Ami egyébként eleve WTF volt, hogy miért nem ekkorák voltak a kezdetektől fogva, de legalább kapcsoltak. Például a maxPerStageDescriptorStorageBuffers a korábbi 4096 helyett 1048576. Ezt azért illet volna az elején is a hardveres maximumra állítani, mert az AMD is arra rakta. Ugye ez az AMD-nél 4294970000, míg az Intelnél 1200, de a kékeknél eléggé másképp működik a meghajtó. Az Intel hardveres maximuma 384 lenne, de ők trükköznek az IGP-vel közös lapkán lévő CPU-val.
-
Abu85
HÁZIGAZDA
válasz
hokuszpk
#34948
üzenetére
Szerintem egy túrót mérik le ennyi CPU-val. A teljesítményben közel állókat csak másolgatják.
(#34943) b. : Más is ezt méri: [link]
Direkt írtam cikket, hogy a Forza Horizon 4 nem úgy használja már a DX12-t, ahogy régen. A lightos korszakot lezárták. Most már erősebben belemennek az API képességeibe, és a fejlesztők szerint a mai meghajtóknak ez még probléma. Ezt lehet javítani, a kérdés a mikorra. Az NV valószínűleg specifikus trükköket dob majd be, mert arra nem hiszem, hogy van idejük, hogy eljussanak általános implementációval oda, ahol az AMD drivere tart. Sokkal később kezdték meg a munkát az explicit API-kkal, és időközben még volt kettőt hátra történet is, amikor átírták a kezdetni implementációt. Szóval itt rövidebb távon trükközni kell. Erre egyébként viszonylag sok lehetőség van még DX12-ben is, na persze nem annyi, mint DX11-ben, de vállalható.
Az Intel is egy kicsit le van maradva, de ők szerintem azt fogják csinálni, hogy szétválasztják az explicit API-k implementációját. A Vulkan driverük már olyan, hogy van egy hardverközeli réteg, illetve egy API alatti összekötés. Ide már be tudják fűzni a DX12-t is, és akkor a mostan implementációt el is dobhatják. De itt is kérdés a mikor. Bármennyire is logikusnak tűnik, nem túl könnyű fejlesztésekről van szó a gyakorlatot nézve.
-
#34831
Abu85
HÁZIGAZDA
huskydog17
#34830
Abu85
HÁZIGAZDA
válasz
huskydog17
#34830
üzenetére
Csak ehhez mindenképpen kellene indirect draws/dispatches, mert ennek hiánya okozza az eséseket. Ugye ezzel az alkalmazás meghatározott számú rajzolási parancsot generálhat és futtathat a processzor beavatkozása nélkül. DX12-ben erre van az ExecuteIndirect, de DX11-ben ennek nincs semmilyen szabványos megfelelője, ami a processzorra sokkal nagyobb terhet ró. Az AGS-ben és az NVAPI-ban vannak megfelelő függvények, csak azokat nem használja a játék. Beépíteni sem hiszem, hogy beépítik, mert ezt így utólag eléggé necces megcsinálni. Egy rakás gyártóspecifikus kódot igényel, amit hetekig tart kitesztelni, arról nem is beszélve, hogy nem szabványos kódokról lenne szó, és az AMD, illetve az NV implementációja a DX11 kiterjesztés tekintetében különbözik. Gondolom ezért is állnak úgy hozzá, hogy ebből inkább nem kérnek, ott a DX12 a szabványos ExecuteIndirecttel. Alternatíva lehetne a Vulkan API, annak is van megfelelő, szabványos kiterjesztése (KHR_draw_indirect_count) erre.
Az nagyon fontos, hogy bizonyos motorok azért gyorsak DX11-ben, mert eleve GPU-driven pipeline dizájnt használnak, illetve alkalmaznak indirect draws/dispatches metódusokat a gyártói kiterjesztéseken. Ezek nélkül például a Frostbite-ban vagy az AnvilNextben is kb. feleannyit tudna a DX11-es mód. A "csodákat" is főleg ezekhez teszi hozzá a meghajtó, nem igazán a szabványos kódokhoz.
-
#34828
Abu85
HÁZIGAZDA
huskydog17
#34827
Abu85
HÁZIGAZDA
válasz
huskydog17
#34827
üzenetére
Nem hiszem, hogy ezen a motoron lehet a DX11-en segíteni. Maximum pár százalékot. De a fejlesztők nem használnak gyártóspecifikus kiterjesztéseket, tehát a motor csak DX12-ben éri el az ExecuteIndirectet. DX11-ben ennek nincs szabványos megfelelője, csak az AMD és az NV függvénykönyvtárain keresztül. Ezekből viszont semmit sem használnak. Még HDR-re is a Microsoft szabványos, "belilulós" pipeline-ját működtetik. Rohadt Xbox One persze a direkt tone mappingos alternatívát kapta, hogy szakadjanak meg.
-
#34809
Abu85
HÁZIGAZDA
cskamacska
#34790
Abu85
HÁZIGAZDA
válasz
cskamacska
#34790
üzenetére
A specifikus kódok nem úgy jönnek, hogy ezeket megírják külön. Nagyrészt azt csinálják a fejlesztők, ideértve a DICE-ot, hogy a PS4Pro géphez írt PSSL shadereket fordítják át egy source-to-source fordítóval az AMD HLSL ext. specifikációjára, amiből aztán tudnak fordítani egy olyan D3BC kódot, amit az AGS szervizkönyvtár elfogad. Alapvetően ebben jelentős munka nincs, az AMD úgy írta meg az AGS-t, hogy a PSSL shaderek szintaxisához igazodjon, ami egyébként eleve nem tér el jelentősen a HLSL-tól, főleg nem az AMD specifikus HLSL ext.-től, tehát effektíve csak a függvények nevét cserélik.
A Frostbite esetében az történik, hogy a DICE leginkább a DPP és az SDWA képességekre épít a PSSL kódokban, így tudnak sebességet nyerni a PS4Pro gépen. Ezekkel gyakorlatilag gyorsabban oldanak meg bizonyos kivágásra vonatkozó feladatokat, vagy tehermentesítik a CPU-t. A PC-s környezetben ugye nem pont úgy fut a Frostbite, ahogy konzolon, mivel a szabványos API-k számos konzolon elérhető függvényt nem tesznek elérhetővé, így bizonyos GPGPU-s eljárásokat át sem lehet menteni, helyettük egy CPU-s megoldás fut PC-n. Ugyanakkor az AMD-nek ezeket átmentik, és mivel ezek a DPP-re és az SDWA-ra épülnek, így alapvetően GCN3/4/5 kell a futtatásukhoz. Ennél egy jóval rosszabb hardveres lehetőségeket rejtő kódot kapnak a GCN1/2 hardverek. Ezért van az, hogy a Frostbite új verzióiban a GCN3/4/5 dizájnok eléggé meglépnek a GCN1/2-től. Egyszerűen ugyanazt a gyártóspecifikus kódot sokkal gyorsabban tudják futtatni.
-
#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] -
Abu85
HÁZIGAZDA
válasz
rumkola
#34696
üzenetére
A DirectX Raytracing egy szabvány. Az RTX az csak a "driver" neve, de maga a kód szabványos. Az AMD nem nagyon veszekszik a stúdiókkal, hogy ne rakják be a DirectX Raytracinget (amit RTX-nek is lehet hívni), pont ellenkezőleg.
Azt egyébként hozzá kell tenni, hogy az RTX technológia jelenthet DLSS-t is. Hülyeség ide sorolni, de az NV ide sorolja. Szóval nem csak sugárkövetést rejthet.
-
Abu85
HÁZIGAZDA
válasz
snecy20
#34640
üzenetére
Sokat zabál nagyon. Laikusoknak az jöhet le, hogy ezt külön hardver számolja, de ez nem igaz. A DXR futószalagnak csak az egyes lépcsőin belül az egyes elemei gyorsíthatók. De a teljesítményt akkor is nagyban meghatározza a szimpla pontosság melletti számítási tempó, illetve a memória-sávszélesség. Az RT mag csak a gyorsítóstruktúrára, illetve a sugár-háromszög intersectionre kínál hardveres megoldást, míg a tensor a denoisingra, de ez nem a teljes számítás. A DXR shaderek a hagyományos feldolgozókon futnak.
(#34641) TTomax: A legtöbben szerintem nem mennek tovább az árnyékoknál, mert azt lehet úgy implementálni, hogy majdnem minden leképezővel megfelel. Az AO is nagyjából oké, míg az ATAA önmagában bonyolultabb, de kompatibilitási szempontból eléggé általános. A visszaverődés, ami nehezebb, nem csak a teljesítményigény miatt. Ami itt problémás lesz a legtöbbeknek, hogy előbb írniuk kell egy DX12 leképezőt is, hogy ez az egész működjön. Aztán a shadereiket le kell konvertálniuk az új specifikációhoz, hogy DXIL-ben is tudják szállítani őket. Ez a support költséget durván az egekbe küldi, ha nem vállnak meg a régi kódtól. Itt a PUBG-ra leszek kíváncsi, hogy miképpen bírják rá a kínai játékosokat a Windows 10-re váltásra, mert így is kész káosz a support, hát még ha dupla annyi kódot kell karbantartani.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#34635
üzenetére
A SIGGRAPH-on volt erről szó. Azt kell nézni, hogy maga a program mennyire tudja átlapolni az RT-t és a rasztert. Egy jól megírt DX12-es leképező nem igazán, mert az már eleve sok aszinkron compute-ot futtat. Innentől kezdve az RT egy extra számítás lesz az ezredmásodpercekben is. Na most egy 8xATAA-t a csúcs-turing 6 ms körül számol Full HD-ben, ami az egyik legkíméletesebb RT effekt. Persze lehet ezernyi dologgal játszani, például a sugarak távolságával, azok pixelenkénti számával, stb. De jelenleg annyira korlátozott a teljesítmény, hogy egy sugár/pixel a realitás, illetve nem lehet ezeket sokáig kilőni. Az árnyék a legkevésbé teljesítménygyilkos, de csak akkor, ha kicsi távolságra lövöd a sugarakat, kis térben viszont elég jól működik. Ezt egy csúcs-turing 3-4 ms között is megoldja Full HD-ben, hacsak nem trükköz valamit a program. A legnagyobb tempógyilkos a visszaverődés. Az 10 ms alatt nincs még a leggyorsabb hardverrel sem. Ez azt jelenti, hogy ha 60 fps a célod, akkor egy ilyen effektet úgy tudsz bekapcsolni, ha a játék amúgy 170 fps-sel megy nélküle. Nem véletlen, hogy a Frostbite egy SSR hibridet használ, ami nem teljesen sugárkövetés, ezzel legyűrték 7 ms alá az igényeit egy Quadro RTX 8000-en. A 2070-re nincsenek adatok, de ha a Quadro RTX 8000-n ezek vannak, akkor sok jóra nem számíthat. Kb. a shadow és az AO menni fog rajta Full HD-ben, de erősebb grafika mellett 30 fps-sel leginkább, vagy áldozol másból, hogy sugárkövetést futtass. Azt tudni kell, hogy a sugárkövetés eléggé sávszéligényes, tehát ez jobban számít itt, mint a TFLOPS-Gigarays.
-
#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.
-
#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.
-
Abu85
HÁZIGAZDA
Ezt nagyrészt a kényszer szüli.
Az Intelt a hagyományos GPU-piac annál jobban nem nagyon érdekli, ahogy most vannak. Gyakorlatilag 70%-ban uralják az egészet. Ha ennél jobban megérné, akkor már beleöltek volna egy rakás pénzt, de nem tették, mert jelentősen növekedtek volna a kiadások, miközben a részesedés arányaiban nem nőtt volna annyit, hogy ez megérje.
Ami itt tényleg számít az a szerver és a professzionális terület. Ezt nagyrészt ma még uralják a CPU-kkal, de azt már nem lehet elvitatni, hogy a GPU-k egyre több helyre törnek be, és persze ezt nem úgy kell elképzelni, hogy megjelent a GPU, és akkor mindenki azt vesz CPU helyett, hanem elkezdődik egy folyamat, aminek a vége mindenképpen az lesz, hogy a GPU nagyjából tudni fogja a CPU-vel elérhető szoftveres hátteret. Nem ma, nem holnap, leginkább csak pár év múlva, de oda fog érni. És itt kezdődik a para az Intelnek, mert eddig hiába jöttek GPU-k egy csomó szerver/professzionális területre, a szoftveres háttért tekintve a fejlesztések elsőként nagyrészt CPU-ra érkeznek meg, ehhez építhető ki rengeteg, TB-os szintű memória, tehát egy csomó olyan tényező volt és még van ma is, amiért a GPU, jó-jó sok TFLOPS, de mégsem jó máshol. Például a render egy elég nagy piac, és ott önmagában a TFLOPS eléggé számít, a GPU-k jók is itt, de mégis nagyon sok cég, köztük a legnagyobbak CPU-s renderfarmot építenek ki, mert a szoftverek ehhez fejlődnek a leggyorsabban, meg ugye a memória is TB-os magasságokig bővíthető, akár fölé is. De a fenyegetés ott van, mert a GPU-knál a Vegából van 2 TB memóriával szerelt változat, illetve a szoftveres háttér is egyre inkább tartja a lépést a CPU-s fejlesztésekkel. Tehát technikailag már nincs messze az, hogy a GPU-k igazi fenyegetéssé váljanak itt, mert ha valaki mondjuk csinál egy olyan rendszert, aminél a CPU-t és a GPU-t egy tokozásra teszi, a GPU-nak lesz egy gyors HBM-je vagy HMC-je, és a CPU-n keresztül még eléri a 2-4-8 TB-nyi rendszermemóriát is, akkor ezzel csúnyán be tudja darálni a renderfarmokat. És ez a valaki nyilván az Intel akar lenni, meg persze a többiek, de az Intel szemszögéből ők problémaforrások.
És ez a példa egy csomó dologra kiterjeszthető, mert ahol megjelentek a GPU-k, ott a szoftveres háttérnél elkezdődött valami, és a szoftverfejlesztések egyre inkább közelítik a CPU-s kódokat, tehát a GPU-k nem csak tessék-lássék, hanem egyenesen reális alternatívává válnak, és a Vega megmutatta, hogy a memóriaprobléma is kezelhető, vagyis a legnagyobbnak tartott hardveres hátrány is lekezelhető. Persze az Intel anno azon az állásponton volt, hogy jó ide a Larrabee... akarom mondani Xeon Phi, de hát egyem a szívüket, az sosem működött igazán. Szóval nagyjából ezért csinálják.A hagyományos GPU-piac annyira nem fontos, de mivel lesz hardver, vagyis úgymond a fejlesztés igazán komoly költségét a szerver- és a professzionális piac miatt úgyis be kell ölni az egészbe, így a terméket lehozni a consumer rétegnek már "csak" maximum 1-2 millió dolláros költség, ami az egészet figyelembe véve nem nagy, így innen már megéri menni a 70%-nál is nagyobb részesedésre, mert arányaiban kifizetődővé vált. Ezt tehetik pGPU-val, vagy dedikálttal is, számukra előbbi a kedvezőbb, mert ott szépen csomagban árulhatják a hardvert a CPU-val, tehát mindenkit rákényszerítenek, hogy megvegye. IGP-re sincs ugye mindenkinek szüksége, de nem tudja nem megvenni.
Nem mellesleg azért abban eléggé igazuk van, hogy értelmes gaming notebookokat csak ilyen Kaby Lake-G-hez hasonló koncepciókkal lehet csinálni, mert így igen kicsi lesz a platformdizájn, és mehet a nagyobb akkumulátor arra a helyre, amit normális esetben egy GPU foglalna el. Tehát itt is van azért alapja annak, amit csinálnak. A többi terület pedig annyira nem érdekli őket, ezek túl picit ahhoz, hogy egy Intel kaliberű cégnek fontosak legyenek, de ha ide is venni fogja a nép, hát akkor szállítják. -
#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.
-
Abu85
HÁZIGAZDA
A ray-tracinget egyáltalán nem nehéz leprogramozni. Ez az egyik vonzó tényező a sugárkövetésben. Sokkal nehezebb valamilyen raszterizációs trükköt kialakítani rá. A DXR-nél nem az a nehézség, hogy nem lehet könnyen ray-tracing effektet írni. Ilyet igazából DXR nélkül is lehet csinálni, hiszen a compute shadert ezért hozták létre. A DXR is egy specifikus kiegészítés, ami végeredményben a DirectX 12 DirectCompute felületén fut, vagyis effektíve compute shader. A probléma a Microsoft specifikációja, ugyanis a DirectX 12 a wave programozás szempontjából "mindent vagy semmit" elvet követ. Ergo nem az a DXR nehézsége, hogy írsz pár shadert rá, amit majd az API átalakít compute IR-ré és IHV-specifikus kódokká, hanem az adja a problémát, hogy ebben a módban a rendszer csak DXIL IR-t fogad el, amihez pedig az adott motorba írt összes shadert újra kell írni, ami azért egy jó 300-400 ezer sor egy modern játéknál. Ez a fő oka, amiért az AMD például egy saját megoldást csinált a Vulkan API-hoz, mert szerintük erre a fejlesztők 1%-a ha hajlandó lesz. A Radeon Rays megoldás annyiban más, hogy ott C++-ban kell programozni a sugárkövetést, és a meglévő shaderekhez nem kell hozzányúlni, az Anvil a háttérben mindent elintéz, majdnem plug&play a modell. De ugye náluk meg az a probléma, hogy az Anvil nem egy kiemelten támogatandó projekt az Intel és az NV részéről, tehát ha mondjuk igényel valami olyan AMD kiterjesztést, amit a konkurensek implementációja pont nem támogat, akkor para van és nem fut le az effekt. De leprogramozni ezt sem nehéz, sőt a DXR-rel ellentétben, át sem kell írni több százezer sornyi meglévő kódot.
A probléma sokkal inkább az, hogy bármelyiket is választja egy fejlesztő, valamilyen szempontból mindkettőnek vannak mélytorkozós részei. És akkor most kinek hiányzik a mai világban beleállni egy mélytorkozásba úgy, hogy DXR-rel kizár mindenkit, aki nem Redstone 5-ös Windows 10-et futtat, vagy Vulkan esetén potenciálisan szopat mindenkit, aki Anvilra nem optimalizál Vulkan implementációt??? -
#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. -
Abu85
HÁZIGAZDA
válasz
Dandris
#34559
üzenetére
Amíg ilyen a specifikáció, addig az AMD vidáman számolhat 4 biten. Pont ezért akarja az NV a specifikációt bővíteni, mert így nekik nem kellene az AMD hardvere után menni. De nem valószínű, hogy a Microsoft hajlandó lesz erre.
A Microsoft nem köti ki, hogy hogyan számoljon a hardver. Mint írtam a DXR a végeredményt tekinti, hogy az megfelel-e az elvárásoknak. A hardver belül akár varázsolhat is, a Microsoft egyszerűen tesz rá. Tehát az IHV döntése lesz, hogy a denoisingot hogyan implementálja a hardverben. Erre tényleg rengeteg megoldás van, és mondjuk az Intel és az AMD nem fogja ezt külön hardverrel megcsinálni, mert akkor kevesebb FP32 ALU lenne beépíthető ugyanabba a tranyóbüdzsébe. Az NV architektúrája viszont nem tudja ezt követni, tehát nekik muszáj különálló hardvereket alkalmazni az egyes speciális feladatokra. Ez az egyetlen oka, amiért sokkal merevebb DXR specifikációkat akarnak, mert nagyon gyorsan hátrányba kerülnek a mostani specifikációkkal.
De amúgy ez a DXR legkisebb problémája. Sokkal nagyobb baj, hogy csak 32 bites vertex formátumot támogat. Ez borzalmasan memóriazabáló, vagyis ha egy VGA-n nincs legalább 10+ GB memória, akár fizikailag rá építve, akár aktivált HBCC-vel, akkor annak a geometriai részlegesség látja majd kárát.
-
#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.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#34546
üzenetére
Az AFR azért nem működik, mert nem lehet optimálisan működtetni a mai modern motorokkal. Ezzel senki sem tud mit kezdeni.
Ha kifelé egy GPU-nak látszódik egy megoldás, akkor memóriakoherens interfésszel van összekötve. Arra nem kell külön támogatás, hiszen nincs két különálló memóriaterületed.
Maga az X2-es Vega létezik, csak ott van bevetve, ahol van értelme: VDI-ban. AMD Radeon Pro V340 a neve egyébként.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#34543
üzenetére
De kamu. Azért nevezték át, mert az SLI-nek és a Crossfire-nek semmi haszna a DX12/Vulkan API-k alatt. Ezek az API-k ugyanis nem támogatják a meghajtóoldali multi-GPU-s megoldásokat, így pedig a Crossfire nevet dobták, ugyanis hasztalan, ha az API oldalán vágják el a támogathatóságot. Az mGPU egy átfogó név lett, ugyanis így az AMD egy kalap alá tudja venni a régi API-kra a régi Crossfire működését, ami ugye haldoklik, emiatt sem látsz már több GPU-s rendszert egy NYÁK-on, illetve az új API-k teljesen megváltozott funkcionalitását, beleértve a WDDM 2.0-ba épített szabványos AFR-t, amit a Microsoft csinált, és nem is engedik meg a gyártóknak, hogy belepofázzanak ebbe.
-
Abu85
HÁZIGAZDA
Mert működött az NV-nek is a HDR SDK-ja. Ezért nem értem, hogy miért álltak le vele. Az tisztán látszik, hogy a Microsoft szabványos HDR-je nagyon köhög. Ezt már akkor lehetett sejteni, amikor az Xbox One konzolokba nem a saját megoldásukat, hanem az AMD Photonját tették be.
Felesleges AMD vs. NV hitvitát csinálni ebből is. Ez csak HDR. Jelen pillanatban nem sok haszna van a mai panelekkel. A tipikus ANSI kontraszt a legtöbb kijelző esetében 10 stops, de maximum 12, és ehhez igazából még nem kell HDR. Maximum az a selling point, hogy bizonyos kijelzők ki tudják rakni a direkten tone mappingolt képet, így azt láthatod, amit a fejlesztő akart. De ezt igazából el lehetne érni szabványosan is, az egész csak egy fixen specifikált szoftver a FreeSync 2 HDR mögött. Valószínű, hogy a FreeSync 2 HDR összes, ma még abszolút egyedi tulajdonsága szabvány lesz olyan 2-3 éves távlatban, akkor már felnőnek a feladathoz a kijelzők is, nem csak ANSI kontrasztban, hanem pixelszintű vezérléssel, stb. Úgy már lesz értelme magának a HDR-nek is.
-
Abu85
HÁZIGAZDA
A driver gyakorlatilag kizárható. Itt egyre inkább a szervizkönyvtárak HDR SDK-ja a kulcs. Még 2016-ban írtunk is róla, hogy első körben ez nem lesz szabványos. [link] - Az AMD-nek van a Photon SDK-ja, ami az AGS-en keresztül kezelhető, míg az NV egy házon belüli SDK-t csinált anno. Na most a probléma ott lehet, hogy a Photon SDK-t az AMD folyamatosan fejleszti, hogy megkerüljék a Windows HDR pipeline-t, míg az NV az egészet ráhagyta, és inkább a Microsoft szabványos környezetét kezdték el támogatni, így viszont a saját környezetük mögül kivették a pénzt, vagyis nem fejlődött tovább. A Windows gyári környezete viszont nem tűnik acélosnak, tehát hiba volt így dönteni, de vissza már nem lehet menni a múltba, segíteni kell a Microsoftot, hogy jó legyen a szabványos környezet is. Ebből még mindig nem lenne gond, csak az AMD berakatja a Photon SDK-t mindegyik HDR-es játékba, szóval ők addig meg tudják kerülni a Microsoft HDR-jét, amíg a redmondiak meg nem oldják a problémákat. Az NV ezt a leállított fejlesztések után nem tudja megtenni, újraindítani pedig felesleges, hamarabb megoldja a problémákat a Microsoft. Azt persze nehéz megmagyarázni, hogy a HDR SDK-jukat miért állították le, gondolom az oda szánt pénzt valahova át kellett csoportosítani.
-
#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.
-
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.
-
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.
-
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.
-
#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.
-
#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.
-
#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. -
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. -
#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. -
#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.
-
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.
-
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. -
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).
-
#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.
-
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.
(#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.
-
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. -
#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.
-
#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.
-
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.
-
#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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Úgy hívják, hogy press release. 
De hát második release, még nem várunk csodát. 
Nem mellesleg azért abban eléggé igazuk van, hogy értelmes gaming notebookokat csak ilyen Kaby Lake-G-hez hasonló koncepciókkal lehet csinálni, mert így igen kicsi lesz a platformdizájn, és mehet a nagyobb akkumulátor arra a helyre, amit normális esetben egy GPU foglalna el. Tehát itt is van azért alapja annak, amit csinálnak. A többi terület pedig annyira nem érdekli őket, ezek túl picit ahhoz, hogy egy Intel kaliberű cégnek fontosak legyenek, de ha ide is venni fogja a nép, hát akkor szállítják.
Ú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.
- MSI GTX 1070 Ti GAMING 8G stabil, működésileg megbízható állapotban eladó!
- ASUS GeForce GTX 660 DirectCU II OC 2GB GDDR5 192bit Videokártya
- Új garancias PNY OC rtx 4070 super 3 ventis OC verzio!
- SAPPHIRE NITRO+ AMD Radeon RX 7900 XT Gaming OC Vapor-X 20G - Konzolvilág garancia 2027.05.07.
- MSI GeForce GT 710 2GD3H 2GB GDDR3 64bit
- QNAP TS-870U-RP 8 lemezes Rack NAS
- Lenovo T450s notebookok - 14", i5-i7, 4-12GB RAM, eu vil.bill, számla, gar
- BESZÁMÍTÁS! ASUS B660M i5 12400F 16GB DDR4 1TB SSD RTX 3070 8GB Zalman T4 Plus Cooler Master 750W
- Új monitor állvány- elegáns megoldás a dupla A/4-es papírcsomag helyett - csak össze lett szerelve
- HATALMAS AKCIÓK! GARANCIA, SZÁMLA - Windows 10 11, Office 2016 2019 2021,2024, vírusírtók, VPN
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő