Új hozzászólás Aktív témák
-
-
Abu85
HÁZIGAZDA
Ami rossz az rossz, ami jó az jó. Ennyire egyszerű. Itt nincsenek oldalak.
Az, hogy a kiadó sürgeti őket már önmagában egy probléma, mert ettől a végeredmény sokszor lesz rossz. És a kiadó számára nem egy opcionálisan bekapcsolható effekt lesz a fontos, hanem a játék maga. Ehhez tényleg kellenek a konzolok, mert ott akár az is előfordulhat, hogy maga a játék van úgy felépítve, hogy az AI upscaling a leképezés fontos eleme, és akkor az nem csak úgy lesz kezelve, hogy meh... hanem rászánják az időt, hogy jó is legyen, és arra már a kiadó sem mondhatja, hogy baszki nincs több idő, adjátok ki, mert dizájnból úgy tervezték a játékot, hogy az AI upscaling nélkül nem jó a sebesség és a végeredmény. Tehát a Microsoft megoldása nem azért más, mert másképp csinálják, hanem egyrészt ott az Azure, amely összesített számítási kapacitásban mérföldekkel több, mint ami az NV-nek van, és ennek egy jó részét pusztán oda tudják adni a fejlesztőknek, hogy Xboxra jól megcsinálják. Aztán persze lehet ezt hozni PC-re, valószínűleg a Microsoftot nem fogja érdekelni, de mivel a DirectML ugyanaz lesz a következő Xboxon, mint PC-n, ezért az egész fejlesztés egy az egyben másolható.
Az NV megoldása is lehetne jó, csak láthatóan nem érdekeltek abban, hogy ebbe pénzt fektessenek, mert ha azok lennének, akkor teleszórnák a fejlesztőket szerverekkel, hogy csinálják a neuronhálót, de nem csinálják ezt. A DLSS szerintem egy nagyon gyors ötlet volt arra, hogy van egy rakás sötét szilícium a hardverben a Tensor magok által, és azokat nem tudták mire használni. Kitalálták, hogy jó lesz az AI upscalingra, meg is csinálták, mert nem nagy művészet ennek a szoftveres háttere, csak azzal nem számoltak, hogy itt a minőség kulcsa nem a hardveren műlik, ami nálad van, hanem azon, hogy mekkora erőforrást hajlandó a minőségért befektetni a játék fejlesztője. Jelen állás szerint nem sokat, mert a DLSS minősége a játékokban a ritka ronda és a - jó szándékkal - közepes szint között van. És ez ellen nem tud tenni az NVIDIA, mert nem érdekeltek abban a fejlesztők, hogy a legalább jó szinthez szükséges erőforrást belefektessék. Szóval ez alapvetően nem az NVIDIA hibája, látható, hogy a 3DMark DLSS tesztje jól működik (sőt kiválóan), csak az egy 3 perces jelenet, arra nem művészet ezt megcsinálni. Egy 10-20 órás játékra már sokkal körülményesebb. Úgy mondanám ezt, hogy a 3DMark bemutatta, hogy maga a DLSS alapvetően tudja azt, amire tervezték, csak a játékoknál fejlesztők szarnak bele, hogy ezt kihozzák, egyszerűen se erőforrásuk, se pénzük rá, hogy egy korlátozott usernél bekapcsolható fícsőrre koncentráljanak. Emiatt lesz más a konzolnál, mert ott aztán minden usernél működni fog, tehát megéri ebbe pénzt és erőforrást rakni, mert optimalizálásként lehet majd felfogni, és ha már működik, akkor mehet copy-paste PC-re is.
-
#40019
huskydog17
addikt
b.
#40014
huskydog17
addikt
Igen, gondolom azért, mert mindhárom felbontást engedi az összes RTX kártyán DLSS alatt, viszont sajnos DX12-ben grafikai hibák jelenhetnek meg, így járt a CB is, de még Gronkh is emiatt használta a DX11-et. Egyébként érdekes az is, hogy ez is egy olyan cím, ahol a DX11 leképző jobban működik, mint a DX12, egyrészt a régi API alatt nem csak gyorsabb a játék, de a grafikai hibák is eltűnnek.
AMD esetén alapértelmezetten DX11-ben indul a játék, nem véletlen, Navi alatt akár 13%-al is gyorsabban fut így.A CB esetén is a DLSS csak felerősítette a hibákat, illetve 1080p alatt erősen mosott lesz a kép, mivel a játék alapból nem túl éles képet ad (kikapcsolhatatlan élsimítás).
A játék meglehetősen lassú alapból is, ugyanis 1080p alatt az RX580 és GTX 1060 csak minimális grafikán hoz jó sebességet, de mindent elmondanak a grafikonok.
A brutális gépigényt a Hardwareluxx és PCGH tesztjei is megerősítik.
Összességében azért nem vagyok elájulva ettől, mert a játék látványa szerintem messze nem olyan, hogy ekkora gépigényt igényeljen, az meg, hogy a DX11-es leképző jobban működik, mint a DX12-es, nos láttunk már ennél sokkal jobb PC portokat is. Northlight motoron bőven van még mit reszelni.
-
Abu85
HÁZIGAZDA
Viszonyítás kérdése. Ahhoz képest jó, hogy pár játék milyen szar képet rak eléd DLSS-sel, de az elvárható minőségtől fényévekre van.
Ugyanaz a probléma mindig. A jó eredményhez jó neuronháló kell, de mivel alapvetően ez csak egy kikapcsolható fícsőr, így nincs értelme belerakni a gépidőt. És itt elcsúszik az egész, mert nem úgy tekintenek rá a fejlesztők, hogy ezzel optimalizálnak, hanem csak megvásárolja tőlük a funkció beépítését az NVIDIA, de eközben a fejlesztői oldalon kb. semmi kedvük arra, hogy ebbe erőforrást rakjanak. A pénz jól jön, aztán szarnak az egészre, miközben a probléma megoldása kellően bonyolult ahhoz, hogy ha ehhez így állnak hozzá a fejlesztők, akkor annak nagyon felemás eredményei lesznek.
Ezen az segíthetne, ha a Microsoft beállnak az egész mögé a következő generációs Xboxnál, és kb. odatolná az Azure-t a fejlesztők segge alá. Tessék ott egy rakás ingyen számítási kapacitás a felhőben, és csináljátok meg az Xboxra jóra, aztán az a neuronháló vihető PC-re is. Az NV-nél ugye a számítási kapacitás nincs ingyen, hiába a reklámszerződés a funkcióra. Ha kifogy az erre szánt büdzsé, akkor ez van, otthagyják szarul a funkciót. Szóval az iszonyatosan sokat jelentene, ha a fejlesztőknek a Microsoft adna ingyen gépidőt.
-
-
Nem tudom, nekem valahogy tiszta, hogy a szilícium chip belsejének hőmérséklete és a VGA kártya PCB-jének felületi hőmérséklete nem ugyanaz.
Mindenesetre a chip belsejében mérhető 110°C ijesztő, ebben egyetértünk, és remélhetőleg a custom 5700-akban nem tapasztalunk majd ilyet. Most, hogy már tudjuk mérni.
-
Abu85
HÁZIGAZDA
Nagyjából azt jelentené, igen. Bár itt számít az is, hogy mennyire van közel a dióda a legforróbb ponthoz. Általában nem a lapka közepére szokás rakni, hanem valamelyik shader tömbbe, méghozzá abba a tömbbe, amely közel van az egyes multimédiás blokkokhoz. De ettől persze bőven elképzelhető, hogy a lapka másik végében jóval nagyobb a hőmérséklet egy specifikus munkafolyamat miatt. A Navi 10-nél ez mindegy, ott már teljes hőtérkép van, tehát konkrétan meg tudja mondani a rendszer, hogy hol van a legforróbb pont, és az milyen hőmérsékletű.
Az órajel-szabályozáshoz nem elég, ha csinálsz egy ilyen rendszert, azt is el kell érned, hogy finom szemcsézettségű legyen a paraméterezhetőség. Ezért jött a finomszemcsés DPM mechanizmus és a hőtérképes mérés együtt. Külön-külön nem sokat érnek.
-
Abu85
HÁZIGAZDA
Minden eladott hardver úgy van beállítva, hogy bírja a terhelést. Az hogy képes-e kimérni a szilícium legforróbb pontját, vagy nem lényegében csak azt befolyásolja, hogy képes-e minden pillanatban beállítani a lehetséges legmagasabb órajelet, vagy nem. Tehát attól sincs igazából gond, ha egy hardver nem képes meghatározni a lapka legforróbb pontját, hanem esetleg 10-15°C-szal kisebb hőmérsékletet mér a diódával, mert a tesztek során be lett állítva erre a helyzetre is, és stabilan, a hardver károsodása nélkül átvészeli az egészet. Csak nem akkora órajelen fog futni, mint amekkorával futhatna, ha pontosabb lenne a mérés.
-
Raggie
őstag
Pontosan kimérte a külső felületük hőmérsékletét. De nem azt, hogy belül mennyire voltak melegek.
A VRM-nél ez jóval egyszerűbb, mert ott ha nincs rajta hűtés, akkor kvázi a chip felületét nézed ami kis kiterjedésű és konkrétan pár tized mm-el alatta melegszik.
A GPU-nál ez közel sincs így... -
Abu85
HÁZIGAZDA
A szilícium hőmérsékletét ezzel nem fogod látni.
Az órajel-szabályozás esetében tipikusan az jelenti a problémát, hogy a szilícium nem minden pontján ugyanolyan hőmérsékletű, viszonylag nagy különbség is lehet két pont között, és egy-egy ponton, akár egy másodperc alatt hevülhet vagy hűlhet ~10-15°C-t. Ezeket sehogy sem lehetett eddig mérni. Teszttapasztalatok alapján lehetett rá következtetni, de gyakorlatban mérhetetlenek voltak. A Navi 10 az első GPU, ami mérni tudja ezeket. Valószínűleg nem az utolsó GPU, mert a legnagyobb teljesítményt akkor tudod kihozni a GPU-kból, ha a beépített rendszer tényleg kiméri a legforróbb pontot.
-
Egon
nagyúr
Jaja, PoorVolta 2.0...
Úgy látszik, az AMD-nél nem csak Raja volt az, aki "rajkodik"...
Neki legalább nomen est omen, de a többieknek... ![;]](//cdn.rios.hu/dl/s/v1.gif)
Egyébként a konkurenciánál legalább van belőle hír: [link] Úgy látszik Abu kezd óvatos lenni: a beégésre alkalmas hírek inkább nem jelennek meg (elég neki ha a be nem teljesült jóslatai miatt ég... ). -
-
#39910
huskydog17
addikt
b.
#39908
huskydog17
addikt
Nagyon röviden azt történt, hogy az AMD ugye a 19.7.3-as driverben támogatta hivatalos az új Wolfi játékot, csakhogy ez a driver több problémát is hozott, mint amennyit megoldott. A PCGH és CB több összeomlást is tapasztalt kizárólag Navi VGA-k alatt. Ezt a 19.7.5-ös driver javította, csakhogy az előző kettő, amivel mindenki tesztelt sajnos instabil volt. Ezeken felül a PCGH VRAM allokációs problémákról és grafikai hibákról is beszámolt, ezek mind kizárólag a Navi VGA-knál fordultak elő.
Ez ugyan nem a két cikkben van, de a 19.7.3 továbbá a GTA V alatt is sokszor elcrashelt, ezt a 19.7.4 javította. Ezen felül a 19.7.3 megváltoztatta az idle fan tempót, ami miatt kicsit hangosabb lett az amúgy sem acélos referencia hűtő alapzaja. Erről a techpowerup számolt be.
Pug: Tök jó, csakhogy ezzel elkéstek, mert a tesztek többsége és ugye a lets play-ek már lementek az első pár napon és ha valaki olyankor ütközötött problémába (márpedig jópáran voltak), akkor ők jogosan könyvelhették el, hogy Navi nem szereti a Youngblood-ot. Az AMD ezzel elkésett, mert nem valószínű, hogy bárki újrateszteli vagy újrajátsza a játékot csak a 19.7.5 miatt, főleg úgy,hogy a 19.7.3 is már hivatalos támogatta a játékot.
-
-
Abu85
HÁZIGAZDA
A ReShade verzió megy minden DX11/OGL játékon. De amúgy nem ugyanez van a driverben, mert ez a CIS portja, a driveres pedig egy módosított CIS, ezért nem ugyanaz a neve. Az eredmény tekintetében a driveres RIS verzió két dologban különbözik a CIS-től:
- egyrészt a PAL szintjén van írva (ez a hardver fölötti legalsó réteg, vagyis szinten assembly szintű kódolásról van szó), tehát több nagyságrenddel gyorsabb, ami mondjuk az effekt jellege miatt elfogadható így is, mert maga a CIS shader 4K-ban 400 mikromásodperc alatt fut 5700XT-n, tehát a ReShade verzió kb. tudni fog 600-900 mikromásodpercet a kevésbé erős hardvereken. Ez így is 2-3 fps mínuszt jelent csak, a felbontás csökkentésével még kevesebbet.
- másrészt a RIS annyiban módosítva van a működést tekintve, hogy erősebb élesítés mellett se adjon túl sok képi hibát. Ez a CIS-ben nem létezik, mivel itt a fejlesztők eleve rászabhatják a működést az adott játékra, ami a RIS esetében ugye nem lehetséges, tehát külsőleg kényszerített eljárásnál általánosan kell jónak lenni, nem pedig specifikusan. A CIS-nél az is lehetséges, hogy csak a kép egy részére alkalmazzák, a motorba történű direkt beépítésnél nagyon sok opció van.DX12/Vulkan játékokra az AMD megoldása kell. Itt a memória vezérlésének jellegzetessége miatt még maga a meghajtó sem tudja segítség nélkül, hogy hol vannak módosításra kijelölt pufferek. Ezt az AMD például úgy csinálja, hogy van a meghajtóba építve egy RGP rutin, ami feltérképezi a memóriát a DX12/Vulkan játékoknál. Na most ezt egy külső programmal marha nehéz megoldani, gyakorlatilag játékonkénti optimalizálás kell hozzá, és ha jön egy patch, akkor jól ki is végzi a működést, vagyis mindent lehet a nulláról kezdeni.
A ReShade egyébként nekifutott megint a DX12 támogatásának, immáron másodjára, de tényleg kellene nekik úgy 150-200 ember, hogy ezt reálisan meg lehessen oldani a meghajtón kívülről. -
#39864
huskydog17
addikt
b.
#39860
huskydog17
addikt
Persze, hogy megy, a moddolt verzió.
Itt a lényeg:
"Navi doesn't have any unique hardware for this, it can be optimized with Navi's FP16 instructions but Vega and Turing support that as well. However ReShade doesn't support FP16 so we have to use the FP32 version regardless of hardware. On my RTX2070S it takes 0.15ms to evaluate ReShade CAS at 1440p.
Like driver CAS this is sharpening-only, the upscaling variant of CAS requires integration into the game engine."
Érdemes nézni ezt a topicot.
A driveres és a Reshade RIS kizárólag sharpeninget csinál. Ahhoz, hogy skálázni lehessen vele, bele kell építeni a játék motorjába, pont úgy, mint a DLSS esetében.
-
Raymond
titán
"Csak ha a Shader cache le van véve 0.7re"
Meg mindig nem ertem ezt honnan szeded.
Azert a DLSS-el hasonlitjak ossze mert a DLSS lenyege az volt hogy kisebb felbontasban renderesz es ezt szuperintelligensAI felskalazza 4K-ra jo minosegben. Aztan latod mi lett belole.
Ez meg tobbek kozott ezt is csinalja. Ezert van ott a 2560x1440 rendereles es felskalazas/elesites 4K-ra ami aztan a DLSS kepminosegevel van osszehasonlitva. A DLSS-nek itt vege, de az elesitest nativ kepre is ra tudod rakni, ahogy a videoban is szo van rola ez akkor lehet jo ha valamilyen jatek szetmaszatolja a kepet a sok PP effektel (hello Codemasters, hello Ubi).
-
ChME
tag
Azért, mert a DLSS a végeredményt tekintve egy leskálázás + élesítés. Ahogy a videóban elhangzik, a shader scale-t úgy állították be, ami megfelel az adott játékban a DLSS által használt leskálázásnak, és erre küldték rá a RIS-t, ami így shader scale+RIS csomagban ugyanazt próbálja csinálni, mint a DLSS. És persze nyersz vele FPS-t.
A Sharpened 4k esetében nem lehet direkt DLSS összehasonlítás, mert nem tudsz (ugye?) DLSS-t futtatni úgy, hogy ne skálázza le a rendert.
-
#39809
Petykemano
veterán
b.
#39808
Petykemano
veterán
szó szerint patikamérleg.
Itt még csak talán nem is az dönthetne egy tiszta (értsd mindshare támogatás nélküli) helyzetben, hogy melyik olcsóbb vagy jobb, mert láthatólag annyival jobbak egymásnál, amennyivel drágábbak is.
de azokon a spotokon, amik olyan szép kerekek, nvidia kártya ül.BEst gpu for $400, best gpu for $500
A 450 esetleg elgondolkodtató, mert pont középen van, de aki $500-t akar költeni, a $450-hez képest pont azt érzi, hogy megéri elkölteni azt az $500-at, amit erre szánt. Aki meg $400-ban gondolkodot, pont nem fog rákölteni még $50-et.
A $380 meg még inkább ilyen. Nem $380-an gondolkodik az átlagember, hanem $400-ban. A 2060S pedig megintcsak jobb annyival, amennyivel drágább, aki $400-ban gondolkodott, nem fogja lespórolni azt a $20-t a végéről.Szerintem az AMD igazából emiat lenne kénytelen $350-re és $400-ra igazítani az árait.
IGazából aközül kell választaniuk, hogy lemondanak a debüt extramarginról - mert ugye a fanok ennyiért is megveszik, vagy pedig a debüt chartokra a fenti konnotációval kerülnek-e fel, s az első benyomást egy 2-3 hónap múlva végrehajtott árcsökkentés már kevéssé fogja befolyásolni. (Persze akkor meg megveszik, akik addig drágállották) -
#39776
Petykemano
veterán
b.
#39775
Petykemano
veterán
Szerintem az optimalizálás az alábbi nem feltétlenül egymást kizáró, de valamiféle fontossági sorrendet mindenképpen leíró lista alapján történik:
1.) Ha valaki (mármint hardvergyártó) megfizeti azt, vagy szellemi erőforrást dedikál
2.) Amelyik hardver a játék célközönségére jellemző, nagy arányban fordul elő
3.) Amelyik kényelmes, könnyű, olcsóAz AMD a 3.) érdekében tett az elmúlt években sokat: profilozó meg dokumentálás, open-source, stb. Meg most még egy lépés, hogy a hardver teljesítményét nem rontja, ha más hardverre optimalizált kódot kap.
Teljesen egyetértek, hogy ez nem fogja felborítani az eddigi optimalizálási rendet.
-
#39774
Petykemano
veterán
b.
#39770
Petykemano
veterán
Szerintem ennek örülni kell. Végre egy fícsör, ami outofthebox működik, nem attól függően lesz olyan jó az amd kártya, mint elméleti tudása szerint lennie kéne, hogy vajon hajlandó-e elbíbelődni valaki a sarokban akkor is, ha kiválóan dokumentált és rém egyszerű.
Ha ez igaz, akkor innentől nincs az, hogy Gameworks, meg turingra optimalizálták, mert bár pazarlóan, de a navi megoldja.Attól meg nem kell félni, hogy bárki elkényelmesedne és emiatt helyzetbe kerülne az AMD és kínlódna az Nvidia. Hiszen ez történt az elmúlt... 4 évben. /NEM/
-
-
Abu85
HÁZIGAZDA
Az Intelnek ez csak a papír miatt kell. Amúgy elég drága a rendszer, elég sok pénzt emésztene fel szoftveres szinten, és eközben nagyon sokat is fogyaszt. Kétszer többet, mint az új EPYC. Krzanich egy csomó fejlesztést kinyírt, ezeket nem lehet visszahozni és most fejvesztve legóznak össze mindenféle töltelékterméket, hogy legalább a versenyképesség halvány látszatát fenntartsák, de ugyanakkor ezekkel már nem akarnak foglalkozni kereskedelmi szinten, mert ott már nyűg lenne.
Csak azt vedd figyelembe, hogy 2020-ban három, azaz három eltérő szerverplatformjuk lesz, amikor a gyártók számára egy platformra is sok-sok millió dolláros tétel felkészülni. Ez a kapkodás jele, hogy számos, hirtelen elindított projekt egyszerre ér be, de ők sem tudják eldönteni, hogy melyik a jó, így kiadják mindet. -
Abu85
HÁZIGAZDA
Persze, csak nincs ugye forgalmazó.
Alapvetően a Cascade Lake-AP esetében az Intel követelményei csak arra szolgálnak, hogy a termék ne legyen vonzó egyetlen komolyabb partner számára sem. Gyakorlatilag csináltak egy processzort, amire úgy rakták össze a rendszerszintű igényeket, hogy a Dell EMC, HPE, Inspur, Lenovo, QCT, Huawei, Supermicro, ésatöbbi, semmiképpen se akarjon erre terméket piacra dobni. És ha megnézed, akkor ez bejött, mert egyik komoly szervergyártó vagy OEM nem kínál az érintett modellekre terméket. -
hokuszpk
nagyúr
"Az hogy ha AMD nem támogatja azért rossz, mert hátráltatja az elterjedését elvégre a köv gen konzolok, Nvidia és Intel is támogatni fogja, "
ha a NAVIban nem is lesz benne, de ahogy irod kovi konzolgenben lesz, azok meg jelen ismereteink szerint AMD cuccbol osszerakva varhatoak.
viszont amig nemjon az a konzolgeneracio, addig szvsz teljesen jo dontes az AMDtol, ha nem erolteti.
majd a konzolokkal megjon a kritikus tomeg is, aztan elterjed jol. -
hokuszpk
nagyúr
"Itt boltokrol volt szó amúgy, nem szerveruzemeltetokrol.."
bolt se fog 24 oras cseregarit biztositani. az 56 magos xeon nem szervercucc ?
"Nem tudom elkepzelni, hogy egy szerverekkel foglalkozó bolt/cég elhajt ha ilyen zsíros falatot tud eladni.
A garancia feltételei vetelkor kötetnek."szvsz attol fugg mekkora hasznot tud ratenni. de ha veszek egy ilyen eromuvet, akkor valoszinuleg valami olyan feladatra fogom hasznalni, ahol nemigazan toleralt a leallas, kell a 24H csere.
szoval ha hajlando 24 oras cseret vallalni, akkor ott raktaron kell lennie cseredarabnak. Ez nagyobb darabszam/forgalom eseten erheti meg a boltnak, vagy ha kb.tripla aron tudja adni. Utobbit nembiztos, hogy sokan kifizetik. -
Televan74
nagyúr
Csodálkozol rajta? Az RTX ütött a népnek,egyeseknek mindegy mennyit fizetnek egy alig használható dologért,ami majd egyszer tényleg jó is lesz, ezt nem vitatom.
Azóta is kérdés hogy lesz e RT az új Naviba. Pedig számomra nem ez fogja eldönteni hogy megveszem e a terméket. De figyeld meg a online médiumokat és a fórumozókat ha nem lesz benne,le fogják hordani a sárga földig.Számomra ami fontos az a teljesítménye és az ára. -
hokuszpk
nagyúr
-
schwartz
addikt
Most komolyan, kit erdekel egy ocska jatekban a ray tracing? Es muszaj ezt ide linkelgetni? (talalgatosba is betoltad, meg ki tudja meg hova) Bejovok ide, olvasni valami erdekeset, pl. illegalis bennfentes tozsdei ugyletek miatt szorongatjak a burdzsekis tokeit, e helyett ez a rejtresz COD. Amugy a Quake2-t mar linkelted? Ha nem, potold kerlek...
(#39697) Abu85
Na most nem fogok tudni aludni, ha nem beszelhetsz rola. -
Abu85
HÁZIGAZDA
Ettől még elnevezhetik 3080-nak, ha akarják. Mint írtam ez csak egy szám. Az NVIDIA majd beperelheti őket, ha a világon elsőként képesek lesznek egy számot levédetni.
(#39675) Televan: Na igen. Nagyjából ez a gond a számok levédésével, és ezért dobják vissza ezeket a kérelmeket.
-
Abu85
HÁZIGAZDA
Számot nem lehet levédeni. A Naviból minden le van védve, amit le lehet, de úgy nem fogadják majd el a beadott kérelmet, hogy RX 3080. A számot visszadobják. Elnevezhetik annak, de az RX részét leszámítva nem védethetik le. Az NV is hiába adta be az RTX 3080-4080-at, a számot vissza fogják dobni belőle.
Ezeket például úgy lehetne védeni, ha így írnák ki: 30∞0. Ez levédhető, de a 3080 nem. -
#39668
Carlos Padre
veterán
b.
#39643
Carlos Padre
veterán
Megvilágítom miért nem érted a cégek működését: jelenleg az aprót úgy szedik fel a földről, hogy lábbal összekotorják, majd lehajolnak érte, semmi fölösleges energia befektetés, szemük végig a nagy zsozsón, te viszont elvárnád, hogy négyütemű fekvőtámaszt bemutatva egyesével szippantsák fel az érmeket, szájjal.
A Dunakanyarban is elvannak az aranymosók, jó levegő, napfény, még talán pénzük is van belőle de egy komoly vállalkozást inkább ne akarj ráépíteni.
-
Abu85
HÁZIGAZDA
Az Intel és az AMD is keres pénzt a datacenteren, nem az a lényeg a cégeknek, hanem az, hogy mennyit kell befektetniük, hogy sokkal-sokkal több pénzt keressenek abból a zsíros piacból.
Emiatt értékes a szerver és a mobil PC-k piaca, mert vagy stabilan tartják magukat, és nem várható olyan változás a jövőben, ami nagyon más útra terelné a felhasználóbázist, sőt, még növekedés is lehetséges, főleg a szervernél.A dGPU-piacon az is egy elég nagy kérdés manapság, hogy a 7 nm-es EUV-re hogyan fognak reagálni a felhasználók, mert ott a középkategóriát simán 400-450 dollárra kell emelni, hogy egyáltalán megérje az egész. Szóval egy olyan tényező van ebben benne, amivel nagyon nehéz számolni, és lehet, hogy felhasználókat fognak veszteni, mert mondjuk xy gémer azt mondja, hogy a 300 dollár is sok volt, de a 400-450 már egyenesen rablás, de ugyanakkor az AMD és az NV se tud nagyon mit tenni, mert a teljesítmény növeléséhez új memóriatechnológiákra van szükség, amelyek a kezdetekben mindig drágák, illetve egy tape-out a 12-16 nm-es tape-out árának a hatszorosa lesz 7 nm-es EUV-n. És még a wafer is nagyon drágul. Ezek olyan kérdések, amelyek az egész piacot nagyon kiszámíthatatlanná teszik, nem lesz rossz a piac, csak a jó ég tudja megjósolni, hogy egy eddig 250 dolláros szinten vásárló PC-gamer mit fog szólni a 450 dolláros árcédulákhoz. Megvásárolja? Megy konzolra? Esetleg Stadia? Nem nagyon van még válasz, mert ugye azt is bele kell számolni, hogy a korábbinál sokkal több alternatíva is lesz.
-
Abu85
HÁZIGAZDA
Nem érted a cégek működését. A dGPU-k piaca éves szinten nagyjából 5 milliárd dollár, és ez inkább fölé van lőve a valóságnak, mert ugye az elmúlt évben azért még a bányászat éreztette a hatását. Ami viszont például az AMD-nek inkább értékes az a datacenter, ami éves szinten úgy 30 milliárd dollár, vagy a mobil, ami szintén nagyjából 30 milliárd. Most te cégvezetőként mit csinálnál? Pacsiznál az NV-vel, és mennél arra az 5 milliárdra, ami ráadásul egy szűkülő piac, vagy megcéloznád a 30+30 milliárdot, ami inkább növekvő? Na ugye. Nyilván, ha a dGPU-k piaca annyira fasza lenne, akkor az NV sem költene az önvezető autókra, a datacenterre, és a többi professzionális területre, de mivel ez a piac messze van a faszától, így ők is inkább a növekvő, 10+ milliárdos területeket üldözik.
(#39641) Petykemano: Tíz év múlva biztos.
-
Abu85
HÁZIGAZDA
Az a baj, hogy a dedikált GPU-k piaca nem kritikus fontosságú. Amikor döntéseket hoznak a cégek, például az egymással való együttműködésről, akkor azt egy olyan piacért hozzák, ami vagy rendkívül nagy, vagy rendkívül dinamikus növekedés előtt áll. Na most a dGPU-kra egyik sem igaz. Ilyen szempontból se az AMD, se az Intel nem fogja különösebben keresni az NV-vel való együttműködést itt, nem tényező, amit ezzel nyernének. Nyilván nem fogják tiltani a kombinált konfigurációkat, ha valami bug van, azt egymás felé is javítják, mert a bug az nekik is para, de kb. ennyi.
-
Abu85
HÁZIGAZDA
Az AMD-nek igazából nem annyira kritikus, hogy a GPU a Ryzen mellett Radeon legyen, ahogy az NV-nek is gyakorlatilag mindegy, hogy a GeForce Intel vagy AMD proci mellé kerül. Azért jönnek a Ryzen+GeForce notebookok, mert a gyártók nem bíznak az Intelben, hiszen hónapok óta azt hallgatják, hogy minden fasza lesz, aztán semmi sem történik. Kb. két-három negyedévig vársz, de van egy pont, amikor el kell azon gondolkodni, hogy az Intel képes-e a problémáit javítani. Bizonyos gyártók úgy döntöttek, hogy jobb biztosra menni, és Ryzent rakni a GeForce-ok mellé. Ennek semmi köze annak, hogy az AMD vagy az NV együttműködne, egyszerűen nekik tényleg mindegy.
A data center az le van játszva. Látható, hogy az új fejlesztésű HPC klasztereknél nem igazán kombinálják a gyártókat. Nem is nagyon tudják, mert itt például az NV az NVLINK-et használja, az AMD az IF-et, és az Intelnek is lesz majd egy saját zárt megoldása.
-
Abu85
HÁZIGAZDA
Amikor az NV-nek van egy játékkal gondja - volt már ilyen, lásd Tomb Raider, Doom, stb. -, akkor azt csinálják, hogy nem beszélnek róla, amíg nincs driver. Mindig így csinálták, és ha megnézed, akkor most se reagálnak a World War Z-re. Majd megteszik akkor, ha már lesz hozzá driverük.
Ennek a fejlesztésnek semmi köze az AMD-hez. Ez gyakorlatilag a shader modell 6.0 Vulkan megfelelője.
Hogy mihez mennyi idő alatt jön javítás, nagyban függ attól, hogy mi a probléma. Például egy memóriamenedzsmenten belüli allokációs problémát sokkal egyszerűbb javítani, mint egy fordítási gondot.
Amiről szó van egy új képessége a Vulkan API-nak. Lényegében lehetővé teszi, hogy az egymástól független feladatok párhuzamos futtatását egy multiprocesszoron. Korábban ezek futtatása csak egymás után volt megvalósítható, ezért vezették be ezt az új képességet, így már egymás mellett is futhatnak. Az, hogy a driver oldalán mi a gond ezzel... kb. ezernyi oka lehet. Nagyon röviden, amikor shader fordítás történik, akkor a meghajtó a hardverre vonatkozó adatok birtokábak kialakítja a megfelelő wave-eket. Lesz egy kép arról, hogy a shader mennyi regisztert (compute esetén LDS-t is) használ, és a multiprocesszor képességeit figyelembe véve lesz egy szám, amennyi wave-et a multiprocesszor tud futtatni. Itt minden harver statikus particionálást használ, vagyis betöltenek minden adatot a regiszterekbe, még akkor is, ha sose nyúlnak hozzá. Minden gyártónak van egy jól kialakított képe arról, hogy az adott hardver multiprocesszora mire képes, hol van az a minimum/maximum határ, ami már rontja cachinget, vagy nem fedhető el a memóriakésleltetés, stb. és a fordító is próbál határokon belüli kódot fordítani, amennyire ez lehetséges persze. És itt van az a pont, amikor leginkább az segít, ha kitapasztalod, hogy mi a jó hardvernek. Általában ezért van az, hogy amikor kiadnak egy új architektúrát, akkor az első driverek nem valami gyorsak, mert még nem értik annyira a hardvert, de aztán írnak jobb shader fordítókat, és egyre jobb lesz gyakorlatilag ugyanannak a shadernek a hardveren való működése. Persze csodát nem lehet tenni, de problémás helyeken +20-30% is benne lehet, átlagban pedig simán meglesz a +5%. A probléma az új subgroup/wave terminológia esetében az, hogy független feladatok párhuzamos futtatása megvalósítható, tehát a wave-ekre vonatkozóan ugyan a hardver működése nem változott, de az új funkcióval a szálak, illetve inkább lane-ek képesek adatokat megosztani egymással, ráadásul nem csak shader lépcsőn belül, hanem shader lépcsők között is. A kérdés az, hogy a lane-ek közötti adatmegosztás tekintetében mi az optimális a hardvernek, érdemes-e változtatni a tipikusan jól működő wave mennyiségekre való optimalizálást. Ezekre nehéz felkészültni tesztshaderekből.
Ami biztos, hogy nem az NV-nél dolgoznak hülyék, hanem nincs elég adat ahhoz, hogy mindig jó döntést hozzanak, mert a PC-piacon ez egy újdonság, illetve a Nintendo Switch által használt API-k sem tartalmaznak subgroup/wave terminológiát. Ergo még nem volt igazán igény egyetlen ügyfél részéről sem arra, hogy a hardver működjön ilyen körülmények között is. Ezzel szemben az AMD-nél már a Sony eleve wave terminológiát kért a PS4-hez, aztán követte őket a Microsoft is, tehát a GCN-nél már 2012-ben felmerült az igény arra, hogy a hardver így működjön. PC-n pedig ugyanezt bevetették 2016-ban a Doom Vulkan portjában, akkor még nem szabványosan, de ahhoz is kell fordító. Ergo amíg az NV-nél egyetlen ügyfél sem kért subgroup/wave terminológiára optimalizált fordítót, addig az AMD-nél ez két ügyfélnél már lassan 7-8 éve igény, a PC-s partnerstúdiók tekintetében pedig három éve. Ennyi idő alatt azért elég jól rá lehet jönni arra, hogy az adott hardver mit szeret, ha a lane-ek között adatmegosztás lehet shader lépcsőktől függetlenül. Alapvetően egy év alatt ki lehet ezt tapasztalni, csak nem elég tesztkódokat futtatni, hanem kellenek a production ready cuccok.
Ilyen különbségek azért nem történnek meg sűrűn, mert általában a piac az újdonságokra egyszerre lép rá, tehát úgymond valami nagy változás bevezetésénél egyszerre szarok a driverek, amelyek egyszerre fejlődnek majd. Manapság az eltérések azért szaporodtak meg, mert az AMD mindent évekkel hamarabb megcsinált szoftveres szinten. Az explicit API-kra vonatkozó implementációt a Mantle-lel, ebből él a Vulkan és a DX12 is. Szimplán van egy PAL rétegük, ami egységes, és fölé húznak egy API-tól függő részimplementációt. Szoftveres szinten azért marha nagy előny, hogy már a DX12 és a Vulkan bemutatására van egy működő absztrakciós réteged a hardveren, amire csak húzol egy kvázi wrappert, és már megy is az egész. Eközben az Intelnek és az NV-nek semmije nem volt a DX12 és a Vulkan API-hoz. Ők nulláról indultak, nem több év tapasztalatból, illetve több tízezer sornyi gyakorlatilag 99%-ban hasznosítható kódról. Ugyanez a shader fordítónál. Az AMD-nek rég megvan, rég működik, míg az Intelnek és az NV-nek megint a nulláról kell felépíteni.
Azt értsétek meg, hogy itt nem a hardver a rossz, vagy az API, vagy bármi az iparágon belül, hanem az a különbség csak, hogy az AMD-nek voltak olyan megrendelői, akik igényt formáltak ezekre az újításokra, már azelőtt, hogy a PC-n szabványosítva megjelentek volna, míg az Intel és az NV esetében ilyen megrendelő nem volt, így nekik értelmetlen volt korábban ebbe erőforrást rakni. Most persze raknak, már megvan az igény, csak a bevezetés szempontjából már nem azt látod, hogy mindenki nulláról indul szoftveres szinten.
A VMA-nak pedig semmi köze a fentiekhez. Az csak egy menedzsment lib. Leginkább abban van jelentősége, hogy mennyi VRAM-ot használ a program, az allokációk törlése hogyan zajlik, van-e defragmentálás, ha igen, akkor hogyan, stb. Ez minden hardvert kb. ugyanúgy értint. Az, hogy bekapcsolták valószínűleg abból adódott, hogy a saját megoldásuk túl agresszív volt, így talán a kelleténél többször törölt allokációkat, ami akadozáshoz vezethetett. Inkább választották azt, hogy legyen több VRAM-igény. Ezt leszámítva más problémát nem fog okozni egyetlen hardvernek sem. A VMA-t nagyon sokan használják a piacon belül, mert időigényes ~13-15 ezer sornyi kódot magadnak bepötyögni, és a végén kb. ugyanott leszel, ahol az AMD megoldása. Inkább érdemes ezt módosítani az igényeknek megfelelően. Valaki persze nem módosítja. Például az Ubisoft elmondta az idei GDC-n, hogy bekapcsolták az Anvil Vulkan portján, és out of box működött az egész, sose kapcsolták ki többet. A Quantic Dream PC-s portjai is ezt használják majd, az új Wolfenstein is ezt fogja használni, bár tudtommal az id software módosít rajta, mert annál a motornál vannak igen specifikus igények, amit egy általános lib azért nem fed le, vagy nem elég jól.
-
Televan74
nagyúr
Én sem vettem meg a Vega 56 -ot 200.000 Ft környékén,sőt én mindig mondtam hogy a custom modelleknek 130.000 Ft körül kellene lenni. Legelső RX580 -nak nem voltak drágák. 85.000 Ft tól indultak,csak jött a bányászszezon és a kereskedők megemelték az árakat. A új árak meg mindig igazodnak a meglévő árakhoz,ami függ a piacon levő régi termékektől és függ a konkurencia esetleges gyengélkedésétől. Én továbbra is az gondolom hogy az AMD elengedte a top kategóriát és egy megfizethető teljesítményt fog nyújtani inkább a Navi személyében, ami jó lesz a jövőben érkező konzol portokhoz(pl. Vulkan alatt).
-
Abu85
HÁZIGAZDA
De ez egy álomvilág. Oké, az NVIDIA felfogta, hogy kijött az első játék, ami subgroupot használ, és kellene hozzá a driver. Nem lesz meg holnapra, a következő hétre sem, talán még a következő hónapban is dolgozni fognak rajta. Természetesen csinálnak hozzá drivert, de van az amit akarsz, hogy holnapra legyen jó a sebesség, és van az ami a realitás, hogy talán tavasz végére jó lesz (nagyon talán).
Ilyenkor egyébként az van, hogy az NV a fölét-farkát behúzza. Lásd az első Tomb Raider, a Doom Vulkan portja, stb. A marketing ilyenkor annyi, hogy nem vesznek tudomást a jelenségről, mintha meg sem történt volna. Ez tart addig, amíg nem tudják mondani, hogy van hozzá driver, ti balfékek, milyen problémáról beszéltek?
-
Abu85
HÁZIGAZDA
De, ahogy írtam ennek a játéknak nem is igazán a Vulkan implementáció a gondja, hanem a shader fordító. Amíg azon nem változtatnak, addig nehéz sokat nyerni.
Egyébként ez egy befektetési kérdés. Rengeteg dolgot lehet még ma is javítani a meghajtókban az explicit API-knál is, csak kérdés, hogy hova rakod az erőforrásod. Például, ha úgy látod, hogy a saját fejlesztőpartnereid nem fogják használni a subgroupot, akkor ugye miért is költenél rá?
-
-
Abu85
HÁZIGAZDA
A kernel driver szűnt meg, de a user mód oldali dolgok megmaradtak, és ide tartozik a shader fordítás. PC-n a bináris képtelenség. Tegyük fel, hogy megadják rá a lehetőséget. A fejlesztők lefordítják a shadereket binárissá, majd azokat szállítják. Addig jó lesz, amíg nem jön egy új GPU-család, amitől kezdve viszont a játék nem fog elindulni. Arra megint fordítani kell binárisokat, majd a következőre ismét, és így tovább. De egy idő után a játékokat nem támogatják, tehát be fog következni egy olyan pont, amitől kezdve az adott játék nem futtatható többet PC-n, az új hardverekkel. Ezért van a shader fordító a meghajtókban, hogy a játékok tudjanak IR-t szállítani, ami akármeddig fordítható az új hardverekre. Persze ennek megvannak a maga hátrányai, például az, hogy ha sokat változik a shader modell, mint mondjuk a Vulkan esetében a subgroup terminológia, akkor oda elég sok munkát újra kell kezdeni, és egy új shader fordító kell az újabb IR-ekhez. Hasonló váltások voltak régen is, és az egyes gyártók jobban felkészültek rá, mint mások.
Nem biztos, hogy azonnal sok javulást kell várni, azért shader fordítót fejleszteni nem egyszerű. Az a baj, hogy az NV-t ahhoz a szinthez méritek, amit az AMD képvisel szoftveresen az explicit API-k szempontjából, és ez borzasztóan igazságtalan ám velük szemben, amikor az AMD-nek ebben a programozási terminológiában van már lassan két évnyi tapasztalata, míg az NV-nél kb. most látták az első production ready kódokat, amik ugye szabványosak, tehát tudnak velük mit kezdeni. Két év tapasztalati háttérrel nagyon könnyű ám jobb shader fordítót fejleszteni.
-
Abu85
HÁZIGAZDA
Ha a shader fordító nem fordít egy hardverre jó kódot, akkor minden felborul. Mindegy, hogy Turing az architektúra, a probléma már ott felütötte a fejét, hogy a driver nem tudott a hardvernek hatékony kódot adni, amit a hardver természetesen nem tud javítani. Annyit tehet, hogy lefuttatja a rossz hatékonyságú lefordított kódot. Ugye PC-n nem lehet binárist szállítani, tehát minden optimalizálást a IR szintjéig kell betervezni, alatta már minden a driverben található shader fordító feladata.
(#39508) b. : A VRAM-ra vonatkozó idény nem az API-tól függ. Alapvetően most se gond a 6 GB VRAM, amíg nem mész 4K-ra, illetve nem használod a felbontásskálázást. A 4 GB-os VGA-kkal simán elvan a játék a legjobb alatti textúrarészletességgel.
-
Abu85
HÁZIGAZDA
Ezért jobb saját memóriamenedzsmentet csinálni. Az AMD sem azt javasolja, hogy kapcsoljátok rá a VMA-t, úgy ahogy van, hanem írják át az igényekre. Ennek az oka, hogy a VMA általánosan fedi le a memóriamenedzsment problémáját, vagyis sosem lesz olyan hatékony a memória kímélése szempontjából, mintha módosítva lenne, vagy a nulláról írna valaki egy saját menedzsmentet. Az előnye annyi, hogy kapsz ~15000 sornyi kódot készen, ami azért elég nagy előny.
A WWZ esetében volt a VMA és a saját menedzsment. A sajáttal jött a játék, majd a patch-ben átkapcsolták a VMA-ra. Na most a saját kóddal hiába törekedtek arra, hogy a 6 GB-os VGA-kba férjen be a játék full részletességgel, ez a VMA-nál már nem igaz, mert a DX11-hez hasonló a memóriaigénye, szemben a korábbi, saját kóddal, ami a DX11-nél is kevesebb VRAM-ot evett. Ez van, picit jobban működik a VMA, de ez nem azt jelenti, hogy NV-n rossz, mert minden hardveren megnőtt egy picit memóriaigény. Aztán, persze később visszakapcsolhatják a saját menedzsmentet, bár kétséges, hogy ebbe akarnak-e erőforrást fektetni.(#39504) Yutani: Jelen esetben a meghajtó fordítója a legnagyobb gond. A WWZ az első játék, ami subgroupokat használ, ehhez nem jók az eddigi fordítóoptimalizálások. De egyébként nem hiszem, hogy az NV hibázott volna, egyszerűen csak másra koncentrálták az erőforrásaikat, mert az elmúlt időszakban azt tapasztalták, hogy az AMD külön kódot kapott, tehát logikusnak tűnt azt feltételezni, hogy az AMD mindenképpen ragaszkodik a saját kiterjesztéseihez. Valószínűleg ez így is van, csak a Saber nem különösebben rajonghat a pluszmunkáért, így nem akarnak két kódbázist karbantartani, hanem mindenki kap szabványos subgroup shadereket. Mivel az NV és az Intel ezekkel először találkozik, így nyilván nem olyan hatékony itt a driver, mint az AMD-nél, akik már az irányt tekintve másfél-két tucat külön kódos kalandon túl vannak.
(#39505) cain69: Az önvezetésbe sokkal több érdekes szolgáltatás belefér, mint a váltóba.
-
Abu85
HÁZIGAZDA
A VMA-t és az RSL-t nem kell támogatni. Mindkettő teljesen szabványos header az érintett API-khoz. Semmit nem kell tennie az NV-nek és az Intelnek, hogy működjön, mert az RSL és a VMA is minden szabványos, rendre DX12 és Vulkan implementációval üzemképes. Ezért használják ezeket a fejlesztők, mert sokkal könnyebb egy már megírt alapra építeni, mint nulláról írni egy csomó kódot, és szabványos rendszerekről lévén szó a piac összes implementációján működnek.
Az NV és az Intel azért nem ír ilyeneket, mert lényegében ugyanazt tudnák megírni, amit a Microsoft és az AMD. Értelmetlen ezekbe erőforrást ölni, amikor az iparágon belül már van a problémára nyílt forráskódú megoldás.(#39501) cain69: Igény nem lesz erre. Az a gond, hogy a Bosch számára nem elég jó, hogy a Mercedes igényeit kiszolgálja. Költ egy rakás pénzt egy olyan platformra, aminél a Mercedes biztos jogot akar a szoftver birtoklására, hogy azt a Bosch ne tudja eladni másnak, vagyis a Mercedes megoldása megkülönböztethető legyen. Így viszont a Bosch számára az a gond, hogy egyrészt drága egy gyártót szolgálni, másrészt nem tudják, hogy a Mercedes mikor mondja nekik, hogy oké, ezt mi is meg tudjuk csinálni házon belül. Jó volt nálatok égetni a pénzt, de inkább megtartjuk...
-
Abu85
HÁZIGAZDA
Csak a VMA az AMD megoldása a WWZ-ben. Minden más a Saber technológiája. Persze használtak ProRendert lightmap bakinghez, de itt csak arról van szó, hogy nem nagy stúdióról van szó, így egyszerűbb számukra venni négy Radeon VII-et, mint ezer CPU-t, így világos, hogy az olcsóbb megoldást választják. Ettől a végleges program sebessége nem módosul, mert a számításokat előre elvégzik, és azt a programfuttatás során már csak megjeleníteni kell.
A VMA egyébként minden Vulkan játékba be van építve, egyszerűen ehhez viszonyítanak a fejlesztők, mert egy általános megoldásról van szó, ami gyakorlatilag lefed szinte minden menedzsmenttel kapcsolatos problémát. A gond vele az, hogy általános, tehát nem feltétlenül működik annyira hatékonyan specifikus környezetben, mint amennyire hatékonyat tudna egy fejlesztő írni az adott motorba. Viszont így is hasznos, mert ha mondjuk a kiadásig nem sikerül a saját menedzsmented megírni, akkor megpróbáltad, VMA-t aktiválni, és mehet ki a játék. Jó persze van olyan opció is, amikor kiadod a saját menedzsmented, aztán egy patch-csel cseréled a VMA-ra. Attól függő döntések ezek, hogy melyik működik jobban.
A Microsoftnak is van egyébként a DX12-re egy RSL-je, aminek hasonló célja van, csak az RSL-nél tudni kell, hogy a Microsoft ezt kiindulópontnak szánja, így csak úgy natúran nem feltétlenül hatékony. Az AMD a VMA-t, elsősorban kiindulópontnak, másodsorban pedig annak szánja, hogy aki nem akar saját memóriamenedzsmentet írni, az egyszerűen betölti a headert, és bamm, működik is.
Más gyártó is csinálhat hasonlót, csak különösebb hasznát senki sem látja, mert az RSL és a VMA is open source.(#39498) cain69: Olyan nem lesz soha. Maximum a hardvert megcsinálja nekik, de a sokkal nagyobb költséget jelentő szoftveres résszel nem éri meg vesződni csak egyetlen megrendelő igényeinek való megfelelés szintjén. Egy NVIDIA számára például anyagilag csőd, ha a Tesla igényeire szabnak egy teljes platformot. Egyrészt nem tudják az NVIDIA hardvereire lezárni, másrészt csak a Teslára költenek egy rakás pénzt, amiből alig látnak majd valamit vissza. Vagy mindenki viszi ugyanazt a platformot, vagy csak a hardvert fogják gyártani, és a nagy költséget jelentő szoftvert mindenki megoldja maga. Egyik cég sem a saját pénze ellensége.
-
#39476
Petykemano
veterán
b.
#39474
Petykemano
veterán
Nem gondolnám, hogy szándékos visszafogás lenne, vagy lett volna az nvidia részéről. Inkább csak valami laza ráérősség.
A fejlesztők részéről pedig afféle "why bother?" típusú hozzáállás lehetett. Biztosan vannak előnyei annak, amit kértek (mégha igazat is kell adnom annak, hogy néha nem az a jó, amit az ember gondol, hogy szeretne)
Abu azt szokta mondogatni, hogy amiket eddig láttunk döntően DX11-hez írt motorok átiratai. Ezeket én leginkább afféle gyakorlásnak tudnám be - próbáljuk ki, hogy meg tudjuk-e oldani, miközben nem nyúlunk bele mélyen és nagyon. Nekem ebből az jön le - Abu is mindig ezt mondta -, hogy amíg az alapjaitól nem írják az új apihoz a motort, addig szinte semmilyen előny nem lesz érezhető például a CPU magokon való jobb skálázódásból.Én arra fogadnék, hogy most hogy megjött a Turing és az explicit apikhoz tartozó drivertámogatás is, most (a következő 1-2 évben) fognak majd elkezdeni érkezni azok játékok, amiknél majd azt hallhatjuk, hogy ezt vagy azt az tette lehetővé, hogy a vulkan/DX12 blablabla
Tehát a kérdésedre válaszolva: nem, szerintem még nincs itt a elégedettség ideje. -
#39473
Petykemano
veterán
b.
#39471
Petykemano
veterán
Én nem ástam bele magam, ezért csak amolyan távoli érzet alapján mondom: úgy tűnik, a nyafogás az explicit apikkal kapcsolatban addig tartott, amíg az nvidiának (hardver és/vagy driver) a DX11 (alapokra épült) játékmotorok feküdtek jobban. Most hogy a driver már jó, meg a Turing is már fekszik explicit apihoz, meg jönni fognak a nem csupán DX11 alapú motorok dX12/vulkán támogatással is rendelkező változatai, hanem a már tényleg explicit apihoz írt programok - nyafi nélkül.
De persze lehet, hogy tévedek.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Persze nyilván kimagyarázza ezt is, meg érveket vár majd... 
Annyira hozzászólnék amúgy, csak az a kibaszott NDA. Na majd később. 
Én megyek rakok egy kis AMD -s húsvéti csokitojást. Ú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.
- Frederick Forsythe: Isten ökle (nem olvasott)
- Xiaomi Redmi 13128GB Kártyafüggetlen 1Év Garanciával
- Beszámítás! Sony PlayStation 4 PRO 1TB fekete játékkonzol extra játékokkal garanciával hibátlan
- REFURBISHED és ÚJ - Lenovo ThinkPad 40AS USB-C docking station (akár 3x4K felbontás)
- ÚJ Apple Macbook Air 15,3 M4 10C CPU/10C GPU/16GB/256GB - Ezüst -(2025) - 3 év gari - MAGYAR
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest