Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Habugi
#19191
üzenetére
Nem az aszinkron compute jelenti itt az AMD-nek ezt az extrém gyorsulást, hanem ez: [link] Persze TSSAA-val az async is számít, de nem annyit, mint a gyors shaderek futtatásának lehetősége. Nem véletlenül nevezik ezeket a nem szabványos shadereket gyors kódoknak. Ennek azon egyszerű oka van, hogy sokkal gyorsabban futnak, mint a szabványos kódok.
-
#19153
Abu85
HÁZIGAZDA
Harley quinn
#19150
Abu85
HÁZIGAZDA
válasz
Harley quinn
#19150
üzenetére
Minden architektúrában van ennyi, csak a szabványok nem adnak lehetőséget a kihasználásra. Itt sem szabványos kód fut RX 480-on, hanem úgynevezett gyors kód.
-
Abu85
HÁZIGAZDA
A Doom esetében az OpenGL nem annyira limites, amennyire más játéknál. Eléggé modern kiterjesztéseket használnak mindkét gyártónál, szóval nem igazán a szabványos OpenGL lehetőségek működnek benne. Emiatt erősebb CPU mellett szinte mindig GPU-limit van. A Vulkan általánosan csupán pár százalékot jelent erős CPU-val. Gyengével persze sokat.
Ami hozza a sebességet az az aszinkron compute, de ez GCN1/GCN2/GCN3-on üzemel csak, míg GCN4-re egyelőre nincs engedélyezve, mert ez a rendszer egy másik konstrukciót kap. Emellett a nagy sebességet a GPUOpen intrinsics hozza, ennek GPU-limit mellett 10-20%-ot lehet köszönni. Az RX 480 csak ettől gyorsul annyit amennyit. -
Abu85
HÁZIGAZDA
válasz
nubreed
#18819
üzenetére
Általában ezeket a megjelenés előtt felrakják, hiszen az adott gyártó az OEM-ekre vonatkozóan már végez limitált szintű előzetes terméktámogatást a kiszállított mintákra, de az nyilván nettó hanyagság, hogy ezeket nem rejtik el a publikum elől.
(#18820) schawo: Default beállítással nem lesz teljesítményveszteség. Ugyanakkor lesz egy TDP-t csökkentő speciális beállítás is, ami egy előre konfigurált power limitet állít be, azzal pár százalék tempócsökkentés lesz. Viszont ez alapértelmezetten ki van kapcsolva.
-
Abu85
HÁZIGAZDA
Ehhez még annyit hozzáfűznék, hogy jellemzően gyakorlati a meghajtók fejlesztése, noha tény, hogy erősen elméleti alapokra van építve. A legnagyobb ismeretlen az RX 480-nál az utasítás-előbetöltés, és ennek a kiismerése hozhatja a legtöbb extrát, mert korábban minden esetben arra törekedtek a rendszerprogramozók, hogy megfelelően át legyenek lapolva a rendszerben futó szálak. Ez számos kellemetlen döntést is vont maga után minden GPU-n, de érdemes volt a kisebbik rosszt választani. Az RX 480 itt teljesen megkavarja a kártyákat, és érdemes kísérletezni azzal, hogy nem az átlapolásra, hanem az utasítás-előbetöltés épül a meghajtó optimalizálásának egy része, ugyanis lehet, hogy a többi hardver miatt csupán egy kényszerből bevezetett rutinok a GCN4-re egyáltalán nem szükségesek, így mehet az optimális konstrukcióval is a feldolgozás.
-
Abu85
HÁZIGAZDA
válasz
nubreed
#18814
üzenetére
Valószínűleg csak az RX 480-on. A többi VGA-n nagyon nehéz ilyen hirtelen ennyi teljesítményt találni, mert ezek már nagyon régóta elérhetők, és nagyon régóta fejlesztik rájuk a szoftveres hátteret. Az RX 480 csak a szokásos fejlődést követi. Jellemző, hogy mindegyik új architektúrát használó VGA gyorsul 7-10%-ot a megjelenéstől számítva fél éven belül. Ez azért van, mert az új dolgok megfelelő működését a szoftveres csapatnak ki kell tapasztalni, és annyira bonyolult ez a buli, hogy ez hónapokig tartó tanulási folyamatot von maga után. Az RX 480 ráadásul olyan dolgokat vezetett be, amelyeket soha egyetlen GPU sem tartalmazott, tehát nagyon sok az ismeretlen tényező. Emiatt nőhet a vártnál picit gyorsabban a sebesség az elején is egy-egy driverrel, mert teljesen ismeretlen vizeken járnak a rendszerprogramozók.
-
Abu85
HÁZIGAZDA
válasz
nonsen5e
#18737
üzenetére
Dehogyis nincs. Csak van egy funkció, amit a DX12-es kódnál a Warhammer hardveresen old meg, és nincs szoftveres backend. Ilyenek a jövőben is lehetnek, ahogy fejlődik a rendszer. Emiatt mondtam mindig, hogy törekedni kell a legújabb architektúrára, mert azok többet támogatnak.
Ez a táblázat egyébként segíthet eligazodni:
-
Abu85
HÁZIGAZDA
válasz
oAcido
#18734
üzenetére
Mennyit akartok még profitálni a HD 7970-ből? A GTX 680-nal volt egy szinten a startkor és most a GTX 780 és 780 Ti között van jelentősen lenyomva a GTX 680-at. A 290X a GTX 780 Ti-vel volt egy szinten és most a GTX 970-980 között van jelentősen lenyomva a 780 Ti-t. Plusz kaptak a vásárlók aszinkron compute-ot, ami szintén hozza a boostokat, úgy hogy a megjelenéskor nem DX12-re vették ezeket a VGA-kat. Plusz a 290X-szel futtatható a Warhammer DX12-es módja, míg a GTX 780 Ti-vel már nem. Nem ez lesz az utolsó példa erre idén.
Idővel minden felett eljár az idő. Természetes, hogy az AMD nem tudja beépíteni a Polaris újításait a kiadott hardverekbe. Ebbe bele kell törődni.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#18730
üzenetére
Az hátulról nem állapítható meg. Sok NYÁK-on van több bekötési pont, de aztán végül nem lesznek felhasználva. Az biztos, hogy maga a tápcsatlakozó nem a NYÁK-on lesz, hanem valahol kivezetve. Talán hátrébb. Kvázi hosszabbítóval lehet bekötni, amit gondolom bele is építenek.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#18720
üzenetére
Custom kellett volna oda. De annyira nehéz azt a hülye grafikont javítani, hogy úgy maradt.
(#18721) oAcido: Itt nem gondolnak az időre a mérnökök. Egyszerűen a Mantle tesztelésénél látták, hogy az eddigi limitek leküzdésével milyen limitek keletkeznek a rendszerben. Ezek eddig is ott voltak, csak korábban beleütköztél egy erősebb limitbe, így minden mögötte lévő limit érdektelen volt. Nyilván a skálázhatóság múlik azon, hogy a felszínre került új limiteket kezeljék, emiatt került be az utasítás előbetöltés. Ennek igazából minden játékra van már hatása, csak lehet csekély és sok, és az egész beállításfüggő. Viszont a hardveresen kezelt probléma a fejlesztők életét egyszerűbbé teszi, mivel persze észreveszik, hogy hol keletkezik a rendszerben a limit, csak nem kritikus fontosságú tenni ellene, mert a Polaris hardveresen kezeli. Sokkal egyszerűbb egy cégnek azt közölni, hogy vegyél Polarist, mint azt, hogy beküldök pár mérnököt egy szobába, és egy év múlva jön a patch.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
#85552128
#18711
üzenetére
Mi nem küldjük a méréseket a netre, nincs bekötve a tesztgép.
(elővigyázatosság, hogy ne frissüljön az alkalmazás). Persze lehet, hogy egyet-egyet a neten futtatunk, de amikor élesben megy, akkor sosem. Ezt nem tudom, hogy kinek van kedve a mi nevünkkel nyomulni, lehet, hogy nem mi vagyunk azok, mert nem PH-s nevet szoktunk használni. Persze az AotS-re van több accountunk. Az az app legalább háromszor megvan. 
-
Abu85
HÁZIGAZDA
válasz
#85552128
#18707
üzenetére
Az extreme preset csak a kiindulás volt. Azon még változtattunk. Közel van hozzá a minőség, de ahogy írtam megnöveltük a mintavételezést. Ezt azért tettük, hogy ráküldjük a hardvereket a futószalagozás határára. Ezt az összes előre konfigurált preset próbálja elkerülni, de mi pont arra voltuk kíváncsiak, hogy melyik hardver skálázódik, ha belefutnak a belső limitekbe. Egyelőre csak a Polaris.
A skálázás azért lényeges, mert nem mindenki fog hónapokat szöszölni a megfelelő preset konfiguráción, ahogy azt teszi az Oxide. Puszi a hasukra a lelkiismeretes munkájukért, de a valóság inkább az lesz, hogy ha egy stúdió belefut a limitekbe, akkor azt elkönyvelik hardveres gondnak. -
Abu85
HÁZIGAZDA
válasz
#85552128
#18695
üzenetére
Mi úgy állítottuk be az AotS-t, hogy sok legyen a mintavétel, ami növeli a rajzolási parancsok számát. Az RX 480 azért olyan erős itt, mert ez az első GPU, ami támogat utasítás előbetöltést, és nem ütközik bele a futószalag mélységének limitjeibe, ami a régebbi GPU-kra jellemző. Amint tízezer rajzolás fölé megy a jelenet komplexitása, azonnal hatékonyságot vesztenek a korábbi hardverek, mert 1 mikromásodpercük van egy rajzolásra, és az túl alacsony érték ahhoz, hogy a memóriaelérést átlapolja a többi szál. A Polaris esetében a határérték 100 nanomásodperc, vagyis 100-szor kisebb a futószalag mélysége, így addig biztosan skálázódik a hardver, ameddig az API. Talán tovább is, de értelemszerűen ezt a gyakorlatban nem lehet még megnézni.
-
Abu85
HÁZIGAZDA
válasz
Valdez
#18674
üzenetére
Mindig szükséges egy pilot projekt, hogy lássák jól működik-e. Az ID software vállalta most magára ezt a szerepet. A játék kiadása miatt itt az időpont nem lényeges már, mert az a céljuk vele, hogy lássák mennyire működik, ha a konzolon használt optimalizálásokat áttelepítik PC-re. Nyilván az AMD ebből csinálhat marketinget, de számukra is egy teszt az egész, mert eddig soha senki nem hozott át konzolról optimalizálásokat. Még a Mantle-re sem, mert az sem tartalmazta a szükséges függvényeket. Szóval a Doom önmagában senkinek nem lényeges. A lényeg az a kérdés, hogy ezt az egészet jól lehet-e alkalmazni PC-n, hogy innentől minden ID tech 6-os játéknál számoljanak vele. Illetve az AMD kérdése az, hogy milyen felkészültséget igényel az implementálás, hiszen aszerint viszik majd a többi fejlesztőhöz.
-
Abu85
HÁZIGAZDA
válasz
wjbhbdux
#18673
üzenetére
Az AMD-nél nem újdonság, hogy rendkívül szorossá fűzik a fejlesztői kapcsolatokat. Amióta kijöttek a konzolok azóta ezen munkálkodnak. Az NV fordítottan dolgozik. Ők egyre inkább kizárnák a fejlesztőket a fejlesztésekből, ami viccesen hangzik, de ez a fő cél. Volt is erről egy nagyon jó fejlesztői blog, ami mérgelődött ezen: [link]
Ezek stratégiai döntések. A piac jelen helyzetében nagyon is megéri az AMD-nek betelepedni a fejlesztők mellé, míg az NV-nek nagyon nem éri meg. Az az alapprobléma, hogy a konzolok miatt a fejlesztők mindent tudnak a GCN-ről, emiatt a GCN-es ismeretek szerint optimalizálnak. Az NV ezzel szemben azt akarja elérni, hogy ne optimalizáljanak. A PC megvan nélküle. -
#18672
Abu85
HÁZIGAZDA
Petykemano
#18667
Abu85
HÁZIGAZDA
válasz
Petykemano
#18667
üzenetére
Nézd meg a Radeonok teljesítményét DX12-ben. Ezért éri meg nekik. Például a legújabb esetet vizsgálva a végleges Warhammer patch-ben az AMD gyorsul, míg az NV lassul, ez elsődlegesen annak köszönhető, hogy az AMD-nél ott a knowhow arra, hogy miképp kell gyorsulni.
Azt sem tartom kizártnak, hogy a knowhow nem jár ingyen, bár ez már erősen üzleti alapú. Annyi biztos, hogy az AMD tapasztalata kell a fejlesztőknek, tehát nagyon előnyös a tárgyalási pozíció arra, hogy a fejlesztők beépítsenek exkluzív dolgokat is, ahogy például a Doom fejlesztői is Radeon-exkluzív eljárásokat raknak a Vulkan leképezőjükbe. Lehet, hogy megtennék maguktól, de az is lehet, hogy csak azért foglalkoznak vele, mert az AMD odaígérte nekik a tudást, és ezt kérték cserébe. -
Abu85
HÁZIGAZDA
válasz
TTomax
#18663
üzenetére
Elbeszélünk egymás mellett. Pár éve a Mantle volt a téma. Azt jóval egyszerűbb beépíteni. Nem azért, mert nagyon eltérő az API, hanem azért, mert aki azt kérte biztosan rendelkezett egy olyan motorral, amely strukturálisan megfelel a célnak, vagy ha nem, akkor rövid időn belül átalakítható. A DX12 és a Vulkan a vezető stúdiók számára hasonló, de az API-k gyártófüggetlen mivolta miatt nem csak a top stúdiók érdeklődnek, és olyan motorok is előkerülnek, amelyek strukturálisan nagyon messze vannak attól, amit ezek az API-k igényelnek.
Mondjuk, hogy egy Nitroust DX12-re felkészíteni egészen más jellegű munka, mint például a Crystal Engine-be belerakni a támogatást. Az előbbivel járó munka nem több pár hétnél, míg az utóbbihoz jópár hónap kell, de nem ahhoz, hogy a DX12-t belerakd, hanem ahhoz, hogy a motor struktúráját annyira átírd, hogy működjön. És akkor ez még mindig csak a működés, lásd Rise of the Tomb Raider. A sebesség ezután jöhet csak. Persze a stúdiók jelentős részénél ez is egy tekintélyes előny a DX11-es szopásokhoz viszonyítva. Még ha nem is hozza a DX11 sebességét, lényegesen kevesebb idő alatt érték el a megcélzott teljesítményt. Ez egy új motor fejlesztésénél nagyon fontos, mert 4-5 éve fejlesztett motoroknál már a DX11 leképező nagyon optimalizált. Tehát innen vizsgálva a DX12/Vulkan API-val egy új motornál hamarabb hozható a célzott teljesítmény.Itt egyébként az AMD már publikusan is árasztja el az ipart a tapasztalataival, és két hónapja elmondták, hogy milyen struktúra az ideális. [link] - na most egy "Stage 3"-ként jelölt struktúrához azért igen durva módosítás szükséges a legtöbb motorban. Ezek azok a tudások, amelyek hiányoznak, mert az AMD ezekről eddig nem beszélt nyíltan, és ugye a többi cégnek nincs három év tapasztalata egy explicit API-val, hogy ezeket tudják. És a beszámoló is csak a felszín, maga a kiindulási alap, onnan még rengeteg limitet kell leküzdeni, mire ebből gyors program lesz. Az iparág problémája innen részben az, hogy a leküzdéshez szükséges tudást is csak az AMD birtokolja. Nyilván három év múlva másnak is lesz ennyi tapasztalata, de a jelenben nincs sok választás.
(#18664) Gertrius: A Valve legfrissebb technológiája nem tartja a lépést a nagyokkal, így számukra annyira nem fontos, hogy kiemelt szerepet élvezzenek egy gyártónál. Tartják a kapcsolatot mindenkivel és fejlesztgetnek. A Valve "amikor kész lesz" fejlesztési modellje egészen más lehetőségeket jelent számukra. Nincs mögöttük egy kiadó, amely esetleg elzárja a pénzcsapot, ha sokszor mondod, hogy csúsznia kell a projektnek. A legtöbb stúdiónál az a probléma, hogy a kitűzött időpont az életben maradást szolgálja.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#18661
üzenetére
Azt nem tudom, hogy teljesen lemondtak-e róla, de borzalmasan messze van az aktuális állapot attól, amit el szeretnének érni. A kiadók általában nem szeretnek a játék megjelenése után olyan projekteket finanszírozni, amelyektől igazából lényeges extra bevétel nem várható. A DX12 leképezőt is a megjelenés után kezdték el fejleszteni, és ugye a játék használna ROVs-ot és konzervatív raszterizációt (TIER3-ast), de mindkettő hihetetlenül lassú. A konzervatív raszterizáció úgy felezi az fps-t, hogy annak elvileg gyorsítani kellene, így nyilván nem kell az Intelnek a Skylake-re. A ROVs meg egy teljesítménygyilkos. Intelen harmadolja, míg NV-n századrészre csökkenti a sebességet. Ez részben fejlesztői hiba is lehet, teljesen elmérték, hogy mire képesek a mai hardverek. A Microsoft sem kínál igazából tanulmányokat erről, ami szintén problémás, hiszen nincs kiindulópont. Csupán annyi van, hogy 4-5 éves távon fognak ezek a funkciók valamit érni, de ez a Microsoft hibája, mert miattuk nem történik itt előrelépés, hiszen úgy vannak vele, hogy 4-5 év múlva ráérnek foglalkozni a DX12 extra funkcióival, és kínálni hozzájuk működő példákat, fejlesztőeszközöket.
-
Abu85
HÁZIGAZDA
válasz
#25237004
#18600
üzenetére
Azért a DX12 beépítését segíteni nem olyan egyszerű, mint azt sokan gondolják. Általában egy fejlesztő, ha partnert választ több tényezőt veszi figyelembe. Az első a knowledge. Az AMD eddig 10 megjelent, explicit API-t használó projektet vezényelt le. Abból kilencet sikerrel, míg egy volt bevallottan a pilot. Az NV eddig 1 explicit API-s projekten van túl, ami szintén a pilot volt. Világos, hogy tudást hol találnak. A második a fejlesztőeszközök. Ezek az API-tól eléggé függetlenül fejlődnek, és két tényezőt vesznek figyelembe a fejlesztők. Az egyik a forráskódra vonatkozó licenc, míg a másik a kiforrottság. Az AMD MIT licenc mellett nyílt forráskóddal kínál DX12-es fejlesztőeszközöket. Az NV-nek viszont még ma sincsenek stabil DX12-es fejlesztőeszközei. A harmadik tényező a reklám, de ez igazából megegyezés kérdése, tehát bármit ki lehet hozni belőle, többek között itt lehet meggyőzni a céget arról, hogy még ha minden ellened szól is, akkor is téged válasszon. Ez leginkább a kis stúdióknál válik be.
Mindegyik cég dolgozik egyébként DX12-es játékokon. Elsősorban azért is, mert az AMD pokoli túlterhelt. A kapacitásaik végét járják, hiszen ők a partnerei a Deus Ex: Mankind Divided, a Star Citizen, a Watch Dogs 2, a Battlefield 1, a Dishonored 2 játékoknak, és már az Ark: Survival Evolved fejlesztőit is felvették, plusz van egy rakás be nem jelentett projekt is, na meg ott a Vulkan, amit használni fog a Doom. Az NV is hoz majd DX12-es játékokat, például a King of Wushu és a Squad című játékoknál segédkeznek. Az Intel tervez a DX12-vel, bár az F1 2015 és a Just Cause 3 frissítést lelőtték, mert a DX11-hez képest csökkent a teljesítmény.
-
Abu85
HÁZIGAZDA
-
#18398
Abu85
HÁZIGAZDA
FollowTheORI
#18397
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#18397
üzenetére
A Division csak bizonyos beállításokkal. A Polaris ezzel a fejlesztéssel menetesül a GameWorks egyes negatív hatásaitól is, amivel az összes többi hardvernek (még a GeForce-oknak is) meg kell küzdenie. A Divisionben a HBAO+ eléggé optimalizálatlan, így ezt bekapcsolva a Polarisnak kedvez a rendszer, míg a többi GPU bele van kényszerítve egy rakás NOP-ba (üres ciklus).
Mi ezért nem kapcsoljuk be ezeket az effekteket, mert nagyon mesterségesen ferdítik a valóságot. Ma főleg a Polarisnak kedvezve. -
#18394
Abu85
HÁZIGAZDA
FollowTheORI
#18385
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#18385
üzenetére
A Black Ops 3-ban azért ilyen, mert viszonylag optimalizálatlan játékról van szó, amiben sok a pipeline stall. Ezeket a helyzeteket a Polaris hardverből kezeli, míg a többi hardver a viszonylag optimalizálatlan kóddal nem tud mit kezdeni. Erre is a harmadik oldal ad majd választ.
Bár a fő fejlesztési indok az AMD-nél nem ez volt, de amolyan melléktermékként a Polaris iszonyatosan jól bánik az optimalizálatlan shaderekkel. Ennek a legnagyobb előnye az lesz, hogy már day0 jól mehetnek vele a játékok, és nem kell a shaderek cseréjére várni.
-
Abu85
HÁZIGAZDA
válasz
rocket
#18363
üzenetére
Az SM6.0 önmagában nem egy Polaris exkluzív valami. Az csak egy új shader nyelv. Annak vannak olyan dolgai, amelyeket bármelyik DX12-es hardver képes teljesíteni, és vannak kiterjesztései, amelyekhez speciális hardverek kellenek. Ezeknek a kiterjesztéseknek egy része lehetővé teszi, hogy áthozzák a fejlesztők a konzolos kódot. Például a barycentric, de ez egyébként ma is megtehető a GPUOpen kiterjesztésekkel, csak az ID például mondta, hogy amit erre írnak Vulkan kódot a Doomhoz és innentől minden játékukhoz, az nem lesz szabványos, tehát akkor sem fog futni nem AMD hardveren, ha a hardver esetleg tudja a magát az eljárást. Ezért jön szabványos formában. Emellett lesznek még további kiegészítések, amelyek még a GPUOpennek sem a részei. Például ordered atomics. Bár erre annyira nagy az igény, hogy hoz rá kiterjesztés az AMD még az SM6.0 előtt, de ez sem lesz szabványos.
Az SM6.0 tehát önmagában nem clickbait, csak az teszi azzá, hogy nincs elég tudásotok felfogni, hogy mi van mögötte, így csak rövidítéseket tudtok rugózni.
-
#18311
Abu85
HÁZIGAZDA
Malibutomi
#18308
Abu85
HÁZIGAZDA
válasz
Malibutomi
#18308
üzenetére
Mondtam, hogy béna ehhez a clickbait műfajhoz. Ez nem az ő terepe.
Nem akarok nagy szavakat használni, de erre születni kell.
-
#18307
Abu85
HÁZIGAZDA
Malibutomi
#18306
Abu85
HÁZIGAZDA
válasz
Malibutomi
#18306
üzenetére
Nem. Kyle, Fuad és Charlie ugyanaz, csak Fuad és Charlie ért hozzá, míg Kyle egyszerűen béna ehhez a műfajhoz.
-
Abu85
HÁZIGAZDA
válasz
füles_
#18264
üzenetére
Nincs különösebb gond a gyártással. A TSMC-nél nincs elég wafer biztosítva az NV-nek, mert gyártat az Apple, a Qualcomm, a MediaTek és a Xilinx. Ők a nagyobb rendelési tétel miatt az NV előtt vannak a, vagyis hiába épül folyamatosan a gyártósor abból az NV nem érez semmit. A kihozatal persze nem tökéletes, de egyáltalán nem katasztrófa. Mondhatni teljesen normális egy új node-nál. Egyszerűen csak annyi a baj, hogy a TSMC alul termel, és ezt a a legkisebb, jelen esetben az NV szívja meg a legjobban.
A GPU-gyártóknak általánosan el kell azon gondolkodni, hogy olyan bérgyártókhoz menjenek, ahol egy node-ra kevésbé nagy az igény a partnerek részéről. A TSMC mostantól káros az ellátásra, mert egy GPU-gyártó nem tud akkora mennyiséget gyártatni, amekkorát a fenti négy cég igénye.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#18067
üzenetére
Attól függ, hogy mire használják. Az itt közölt fejlesztésekből a Barycentrics az, amivel extra effekteket lehet csinálni, például jó minőségű analitikai élsimítást. De ez is használható teljesítménynövelésre, hiszen pixel shaderben is engedi futtatni azokat az eljárásokat, amelyeket eddig csak geometry shaderben lehetett megírni. Ebből például az Emil Persson-féle GBAA ilyen irányú portja sokat profitálhat.
De az egyébként jó hír, hogy a Microsoft a következő DirectX API-ban megköveteli a manuális interpolációt, tehát mindenkinek GCN-szerű interpolációs modellt kell kidolgozni, és az eddigi modelleket el kell dobni. Szóval azért haladunk előre a fejlesztésekkel. -
Abu85
HÁZIGAZDA
válasz
#65755648
#18065
üzenetére
Ez igaz, de az AMD a GPUOpennel eléggé beleköpött az állóvízbe. Nehéz megjósolni, hogy mik lesznek a GCN shader kiterjesztések hatásai, de a Doom és az új Deus Ex használja őket, szóval GCN nélkül ennél a két játéknál biztos nem lesz elérhető minden funkció. És akkor még jön olyan, hogy s_waitcnt/lgkmCnt/vmCnt, amik szintén nem kis fícsőrök, bár ezeket csak az Ubisoft kérte.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#18007
üzenetére
Ezen amúgy az NV tudna sokat javítani. Emlékszel a Dirt Showdownra? Na azt driver hozta helyre. Egyszerűen a játékra kellett szabni egy regiszterallokációs optimalizálást, ami a Keplernél mindig is nagyon fontos volt, mert regiszterhiányos az architektúra az ALU-nkénti 1,33 kB-nyi regiszterrel. A feldolgozók elvesztése egy másik probléma. Egy multiprocesszorba négy warp ütemező került hat felfűzött tömbhöz, vagyis két tömböt mindig különálló utasításokkal kell ellátni. Ez is orvosolható driverből a shaderek cseréjével, ha a fejlesztő nem figyelt rá. A gond az, hogy nincs meg az akarat a Kepler teljesítményén javítani, mert ha meglenne, akkor aligha lennének olyan játékok ahol egy R9 280 elveri a 780-at.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#17931
üzenetére
Én elfogult vagyok a PC-piaccal, és sosem tetszett, hogy ennek a piacnak a szépségét bizonyos gyártók semmibe veszik. Régen ezért szapultam az ATI-t, mert szándékosan értelmeztek félre egy nagyon fontos specifikációt, amivel rosszat tettet a PC-nek (R2VB erőltetése). Most sem tesz jobbat a PC-nek az NV úgy, hogy olyan eljárást választanak az egyes effektekbe, ahol ugyanazt az eredményt a geometry shader hatszor lassabban számolja ki, mint a vertex shader. Ez egyáltalán nem a piac érdeke.
Kettőnk között az a különbség, hogy én látom, hogy mikor vernek át, míg te nem akarod, vagy tudod megnézni.
[link] - és nem csak én látom ezt problémának.
-
Abu85
HÁZIGAZDA
Nem is vennék, ha nem tudnám elintézni a VGA-gyártókkal, hogy egy az egyben cseréljék az új VGA-kra a régi GeForce- és Radeonjaimat.
(#17929) Egon: Mert ők is hazudnak, de például az nem érdekel, hogy egy cég hazudik arról, hogy melyik VGA-val járok a legjobban, mert nyilván az az érdekük, hogy a legújabbat adják el. De az már érdekel, ha arról hazudnak, hogy az adott effekthez használt eljárások miért terhelik indokolatlanul meg az adott hardvert. Ennek nagyon prózai az oka, én nem hiszek a gépigény mesterséges növelésében, és nem tartom jónak, ha a PC-piacon ez az irány stratégiává válik.
-
Abu85
HÁZIGAZDA
válasz
imi123
#17908
üzenetére
Nem, csak azok akik azt hiszik, hogy jót tesznek a piacnak.
Az AMD is hazudik. Ők annyiban jobbak, hogy nem ölik a piacot. Felvették azt a működési modellt, ami az NV-re volt jellemző a G80-as időkben.
A véleményem mindegy, mindenki láthatja, hogy milyen szuperül működnek a GameWorks reformok. Hogy is van ez a politikában? A reformok működnek? Ugyanaz történik, az alacsony IQ kihasználása a lényeg. Persze nem fogják beismerni, hogy a hülyékre utaznak, de ettől tény, hogy gazdaságilag ez a kifizetődő.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Annyit hozzátennék még, hogy lehet játszani a textúraszűréssel a driverekben. Ez az AMD-nél a mintázat szűrés minősége, míg az NV-nél angolul Texture Filtering néven szerepel (magyarul textúraszűrés néven lehet). Ne tévesszen meg senkit, hogy nagyjából ugyanazok a beállítások (teljesítmény vagy minőség), mindkét gyártónál más az értelmezés. Például az NV magas minőségű (high quality) módjának az AMD-nél a teljesítmény mód (performance) felel meg a képminőség tekintetében. És az AMD minőség módja egy nagyon agresszív szűrési rendszer, amit a konzolokon kívül nem szokás alkalmazni, és más nem is alkalmazza. Ezeket tetszőlegesen, akár játékokra leosztva lehet állítani, mert nincs univerzálisan jó beállítás manapság.
-
Abu85
HÁZIGAZDA
Akkor leírom hosszabban. Az efféle jelenség oka az ordered dithering, ami csak szimulálja az átlátszóságot. Ezt igen sok régebbi játéknál használták a fejlesztők, mert fel lehetett húzni a háromszögekre egy dithering textúrát, és ezzel nagyon olcsón megúszható az átlátszóság kezelése. A ordered dithering hátránya, hogy nem ad jó eredményt, mert bár piszkosul gyors, és bőven megúszható a rakás overlap, de az algoritmust egyrészt a hardverhez kell igazítani, másrészt mindig lesznek a képen apró pöttyöcskék, amik a dithering textúra mellékhatásai.
A képen is látható, hogy mindkét hardveren megvannak a pöttyöcskék, csak más mértékben, mert más algoritmussal működik az ordering. 4xMSAA ezen sokat segít, de ott is látható, hogy a korlátnál az NV-n is marad pár pötty. 8xMSAA lényegében jelentősen megritkítja a jelenséget.Közben megnéztem a játék whitepaperjét is, és az Advanced Blending beállítás bekapcsolása, már nem ordered ditheringet használ az átlátszóság kezelésére. Az Advanced Blending egyébként OIT-t használ.
-
Abu85
HÁZIGAZDA
A Dirt Rally alatt biztos, hogy el lehet tüntetni a grafikai beállítások maximumra állításával. A 8xMSAA radikálisan csökkenti a jelenséget. A Tomb Raider esetében ez beállítástól független.
(#17880) PuMbA: Felőlem vehetsz NV VGA-t, de ugyanazzal a grafikai beállítással nem fog ez a jelenség eltűnni, mert ez program oldalán keletkező dolog. Se driver, se hardver nem fog mást számolni, mint amit a program kér.
-
Abu85
HÁZIGAZDA
Soha, mivel ezt nem lehet driverből befolyásolni. Az alkalmazás fejlesztője tudja korrigálni, de ez egyébként terv szerint működik így, még ha ronda is.
Van még így működő játék. Például a Two Worlds 2 maximális minőségben. Arra itt panaszkodtak a userek. [link]Ezek egyébként a PS3/Xbox 360-on használt technikák portjai. Azért ilyenek, mert nem módosították a motor leképezőjét PC-re.
-
Abu85
HÁZIGAZDA
válasz
rocket
#17854
üzenetére
Annyival magasabbra nem lőhették, mint tervezték, emellett a GDC alapján pontosan tudták, hogy mire számíthatnak, hiszen akkor az AMD már megmutatta, hogy miket hoz a GPUOpen-be és az NV-nél is tudják a mérnökök, hogy ezeknek a built-in függvényeknek a hatása eljárástól függően +20-70% közötti boost a végső teljesítményre. Elég csak azt figyelembe venni, hogy Tiago Sousa a PS4-en 3-5 ms-ot nyert a Doomban async és built-in függvényekkel. Szóval elég pontosan ki tudták számolni, hogy a legrosszabb eshetőség mellett is mekkora órajel kell ahhoz, hogy a specifikus kódokkal tarkított RX 480 előtt maradjon a GTX 1080.
-
Abu85
HÁZIGAZDA
válasz
rocket
#17851
üzenetére
Ők részben azért tértek át a GloFo-ra, mert a TSMC-nél csak a sorukra várnának, mert ők sem nagy megrendelők. A GloFo viszont kedvezőbb, mert egyrészt speciális szerződésük van kötelezettséggel, ami alacsonyabb waferárat is jelent, másrészt a legújabb dens libeket csak GloFóra fejlesztik, és ahhoz, hogy a TSMC-nél tudjanak FinFet GPU-t gyártani előbb át kell portolni a HPL-t. Na most ez borzalmasan költséges, mivel a TSMC-nél csak HDL-je van az AMD-nek, de azt már nem akarják GPU-khoz használni. Emiatt sokkal olcsóbb áthozni a gyártást a GloFóhoz, mint HPL-t portolni a TSMC-hez. Ez volt a fő szempont a váltás mögött. A többi járulékos előny csak adalék.
-
Abu85
HÁZIGAZDA
válasz
rocket
#17849
üzenetére
Azért annyira nem amatőrök. A 16 nm-es FinFet majdnem másfél éves alap, amit sokan gond nélkül használnak. Nem hiszem, hogy pont az NVIDIA tervezné annyira félre, hogy alacsony legyen a kihozatal. Ahhoz azért általában a bérgyártónak is bénáznia kell, ráadásul a TSMC biztos szólt volna, ha valami idióta dolgot csinálnak. Erre vannak a szakembereik.
Eddig minden lapkából csináltak B verziót, annak nem kell nagy jelentőséget tulajdonítani. A legtöbb esetben el sem jutott az üzletekbe a B-cucc.
-
Abu85
HÁZIGAZDA
válasz
nubreed
#17845
üzenetére
Az a Glofónál készül. Erős a valószínűsége, hogy az AMD azért mentek át, mert a TSMC-nél nehéz labdába rúgni a nagyobb megrendelőkkel szemben. Ráadásul nekik vannak oda is libjeik.
(#17846) =WiNTeR=: A memóriagyártók nem jelentenek gondot, mert lezárt specifikációjú gyártósorral nagyon gyorsan lehet reagálni. Maximum két hónap és annyi gyártósort építenek ki, amennyi kell. Már a HBM2 is tömeggyártásban van, szóval le van zárva a specifikáció.
-
Abu85
HÁZIGAZDA
válasz
rocket
#17841
üzenetére
Uh, ez így sokkal rosszabb helyzet, mert nem lehet megoldani két hónapon belül és nem fog javulni a GDDR5X gyártósorok kiépülésével. Még ha a Micron gyártani is fog elegendő mennyiségű GDDR5X-et, a TSMC-nél az NVIDIA csak a sokadik a sorban a sok SoC gyártó mögött. Ebből úgy jó fél évig hiány lesz.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#17784
üzenetére
Semennyit. Az effektek számításához szükséges idő ugyanaz DX11 és DX12 alatt. Az aszinkron compute átfedése jelenthet előnyt, mert úgy pár compute effekt ingyenesség válik. A DX11 azért lassabb sokkal, mert nem arra optimalizálták a játékot. Túl költséges és időigényes lenne ennek a módnak a teljesítményét a DX12 közelébe vinni.
Ez egy stratégiai játék. Fölösleges a 60 fps. Nem igényli a játékmenet.(#17783) gbors: Majdnem 100%-os hatékonysággal lehet aszinkron compute-ot futtatni. Az MLAA esetében biztos, mert olyan fázisba van berakva, ahol az ALU-k eleve csak malmoznának. A GPU particles esetében pedig majd meglátjuk.
-
-
Abu85
HÁZIGAZDA
Van róla egy részletesebb leírás, hogy milyen effekt mennyi időbe kerül 4K-ban. Persze ez az aktuális verzióra igaz.
A Warhammer implementációja az éppen aktuális AMD MLAA verzió másolata. Az nem eszik annyit, mint a Jimenez-féle konstrukciók, amelyeket például a Crysis is használ.
Nem különbözik a DX11 és DX12 alatt az effekt elvégzéséhez szükséges idő, mert ugyanaz a shader. DX12 annyiban jobb, hogy átlapolja a számítást a következő képkocka kezdeti számításaival, ahol ugye ez lehetséges. Emiatt pár hardveren még -1-2 fps sem lesz belőle. -
Abu85
HÁZIGAZDA
válasz
TTomax
#17768
üzenetére
Természetesen nem reprezentálja. Ebben a tesztverzióban még nem fut aszinkron compute-ban a GPU particles, illetve még nincs kész az a speciális MSAA, amit beleraknak a végleges DX12 kódba. Ettől függetlenül az bullshit, amit Hilbert az MLAA-ról összehord, hogy az akkora "performance hog". Maximum 1 fps-t képes levenni a végső sebességből, és ez nagyon maximum.
-
Abu85
HÁZIGAZDA
válasz
Valdez
#17765
üzenetére
Ezt nem igazán lehet így leírni, mert számos MLAA algoritmus létezik. Az AMD algoritmusa az egyetlen, amely compute shaderben számol. Ebből van kevés a játékoknál, míg más MLAA konstrukció elterjedt, például az SMAA is egy MLAA algoritmus, de nagyon sok játékban az AA csak AA-nak van jelölve és zömében MLAA-k azok is.
Ami miatt az AMD MLAA-ja kedvezőbb DX12-re az az asszinkron compute, mert az AMD konstrukcióját szinte változtatás nélkül be lehet főzni dedikált compute parancslistára, míg más MLAA/FXAA/CMAA konstrukciók esetében át kell írni az egészet előtte. -
Abu85
HÁZIGAZDA
válasz
TTomax
#17758
üzenetére
Megnéztem az MLAA-t mennyit eszik. A kapott adatok alapján 4K-ben a 980 Ti-nek 0,61 ms, míg a Fury X-nek 0,94 ms. Tehát a GeForce-on fut jobban úgy ~30%-kal (ez kb. reális, egyébként nagyjából ennyivel fog jobban az FXAA a Radeonokon.). Ugyanakkor a Radeon aszinkron compute-ban futtatja, így náluk ez ingyenessé válik. Mindenesetre annyira kevés erőforrást igényel maga az effekt, hogy maximum -1 fps jöhet belőle hardvertől függően. Nem értem, hogy a Guru3D miről beszél, gondolom ezt is benézték, mint az FCAT-ot az AotS-ben.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
joysefke
#17548
üzenetére
Négy hónapig nem tudtak elég HBM-et gyártani a Fiji-hez sem. Mindig ugyanez a probléma az új rendszereknél. A kísérleti gyártásból kevés gyártósor megy át, mert direkt nem építik ki azokat, hátha rossz a kísérleti gyártósor. Utána viszont három-négy hónap mire a végleges specifikációnak megfelelően felhúznak annyi gyártósort, amennyi a megrendelések kielégítéséhez kell.
(#17547) Habugi: A vége az lesz, hogy HBM lesz mindenen, de a nulláról a teljes átmenet annyira nagy időtartam, hogy a köztes megoldásokat is figyelembe lehet venni. De hosszabb távon valamelyik újabb HBM generációé a jövő, mert az ahhoz hasonló specifikációjú alternatív konstrukciók sokkal többet fogyasztanak. Az alsóházba pedig jön a valamelyik Wide I/O szabvány. Utóbbi teljesítményben nem sokkal jobb a GDDR5(X)-nél, de fogyasztásban szétveri őket.
-
Abu85
HÁZIGAZDA
válasz
rocket
#17535
üzenetére
Teljesen mindegy, hogy mennyi a kereslet. A probléma ugyanaz, mint a Fiji-nél a HBM miatt. Nem fognak tudni annyi memóriát gyártani, hogy kielégítsék az igényeket. Ugyanaz fog lezajlani a megoldás szintjén is. Kell három-négy hónap átfutás, amíg a rendelésekhez igazodik a memóriagyártó.
Teljesen mindegy, hogy a kereslet egy termék esetében többször nagyobb vagy többször kisebb a vártnál. A reakcióidő a hiányra vonatkozó problémára ugyanannyi, mert párhuzamosan is lehet gyártósorokat építeni.
(#17539) vitko: Májusban kezdték meg a tömeggyártást. Ha márciusban megkezdték volna, semmi baj nem lenne, mivel három hónap kell egy gyártósor üzembe állításához.
-
Abu85
HÁZIGAZDA
válasz
rocket
#17532
üzenetére
Computex. Később bővítik.
Egyébként az okozza a félreértést, hogy a tömeggyártásnál mindenki a nagy mennyiségű gyártásra gondol. Valójában ez nem igaz. A tömeggyártás beindítása azt jelenti, hogy a kísérleti gyártáshoz használt gyártósorokat véglegesítik, és azokon elkezdődik az igazi termelés. Ugyanakkor a gyártósorok kapacitása ettől nem változik meg, csak lehetőség van arra, hogy új gyártósorokat építsenek a lezárt specifikációra. Ez azonban sok időt vesz igénybe.
A probléma annyi, hogy nem éri meg előre kiépíteni sok kísérleti gyártósort, mert ha azok rosszak, akkor mindet le kell bontani. Ezért csinálják úgy, hogy kevés gyártósor készül az elején és a véglegesítés után nő meg ezeknek a száma. -
Abu85
HÁZIGAZDA
A GTX 670 DX12 kódjához képest van előnye. Keplerre a Crystal Dynamics nem optimalizált már program oldali memória menedzsmentet. Csak Maxwell és GCN optimalizált menedzsment van az új Tomb Riaderben. Bár ez egyébként a sebességen nem fog meglátszani, inkább az akadások számában.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#17474
üzenetére
A következő évben is érkezik VEGA, csak nem ugyanaz a lapka. Azt hozzá kell tenni, hogy nem biztos, hogy az első VEGA HBM2-t kap. Ez csak találgatás.
Ha erről kiderül valami biztos, akkor megírom.Igazából a roadmapek alatt ki van írva, hogy változhat. Nyilván december óta megváltozhatott, így más lehetett a februári roadmap, amit a GDC-re vittek. Tényleg nagy kérdés, hogy a VEGA decemberben hol volt, mert Q4 elejét csak január óta lehet hallani, igaz a VEGA-t is.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#17469
üzenetére
Az investoros dia egy termékcsaládra vonatkozó dia. Azt jelzi, hogy az adott év melyik termékcsaládra lesz fókuszálva. Ezért jobb a másik dia, mert az nem fókuszálásra van kialakítva, hanem arra, hogy az adott termékcsalád első lapkája mikor jön.
Amióta bármit lehet tudni a VEGA első lapkájáról azóta Q4 eleje a célkitűzés. Ez január végét jelenti, mivel ekkor kerültek a tervek a fejlesztőpartnerek elé.
(#17470) Cifu: Mert mondjuk az új TR DX12 kódja lassabb, mint a DX11-es.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#17467
üzenetére
A Vega az termékcsalád. Nem csak egy lapkából fog állni. De csak az egyik jön idén. Ezért van úgy jelezve a dián, hogy a négyzet nagy része 2016-ra van betolva.
Az investoros dia a 2015 decemberi bemutatóról származó dia másolata.Igazából már februárban lehetett hallani, hogy az első Vega Q4 elején jön. Ezt konkrétan a SEGA egyik stúdiójától hallottam.
-
Abu85
HÁZIGAZDA
válasz
he7edik.
#17460
üzenetére
Kis segítség a grafikonon szereplő év elválasztásához.
(#17464) sayinpety: Nem. Továbbra is október-november a target. Az történt, hogy pár média bekamuzta a 2017 elejét, aztán ezt a kamut úgy próbálják eladni, hogy az AMD előrehozta hirtelen (nyilván senki sem fogja azt mondani, hogy elbasztuk, szarok voltak az informátorok, vagy rossz volt a kristálygömb, stb. ... az is biztos, hogy az AMD nem fogja cáfolni ezeket, mert szabály náluk, hogy nem megjelent dolgokról nem beszélnek). Szóval az, amit neked mondtak pár hónapja továbbra is él.
-
Abu85
HÁZIGAZDA
Elég sok új játékban van lényeges előnye. Minden DX12-esben, vagy azokban, amik Mantle API-t használnak.
Bár azt hozzá kell tenni, hogy az előny nagy része annak köszönhető, hogy az NV már nem optimalizál a Keplerre regiszterallokációs rutinokat, illetve nem cserélik ki a shadereket Keplerhez való shaderekre, így elvesztik a magok 1/3-át. Ez például a Witcher 3-ban eléggé fáj. Sajnos ma egyedül az UE4 és a Frostbite használ Keplerre is optimalizált shadereket. A többiek szarnak rá. -
Abu85
HÁZIGAZDA
válasz
Habugi
#17282
üzenetére
Igazából ez csak egy alap, ami mutatja, hogy skálázódóvá teszi a játékot sok rajzolási paranccsal. Jelen formában csak azért adták oda a sajtónak, hogy megmutassák, hogy nem a játék működik rosszul, csak a DX11 nem bírja a terhelést. Később bekerül például az MSAA is, illetve a specifikus GCN optimalizálások.
-
Abu85
HÁZIGAZDA
válasz
joysefke
#17202
üzenetére
Egyrészt a Valve mondta, hogy a Vulkan itt csak teszt. Ráadásul egy wrapperen van rajta, vagyis egy magot használ csak, mint a Talos Principle. Ugyanakkor ki akarták próbálni élesben. Olyan kérdésekre keresik a választ, hogy mennyire megbízható több gyártóra levetítve a validátor, stb
Másrészt a Vulkan működése az aktuális motor alatt speciális, mert futtatási időben hoz létre számos szükséges adatot, amit a merevlemezen tárol majd a gépnek megfelelően. Ez azt jelenti, hogy kb. 15-20 percet kell játszani a játékkal, hogy minden meglegyen, és utána kerül tesztelhető állapotba a Vulkan kód. Ha hardvert cserélsz, akkor megint játszani kell ennyit a teszt előtt. Ez később nem lesz így, de az aktuális kód sajnos ilyen. Ha ezt nem teszed meg, akkor akadások és lassulások lehetnek Vulkan alatt. -
Abu85
HÁZIGAZDA
válasz
Valdez
#17142
üzenetére
Ha a validátor hibát jelez a kódra, akkor nem. A DX12-ben nincs kernel driver, hogy mindent ellenőrizzen futtatási időben. Ott az alkalmazásnak igen komoly jogosultságai vannak, ami egyrészt az egyszerűséget hozza el a programozónak, értsd sokkal hamarabb elérik a kívánt teljesítményt, de a jogosultságokkal lehet rosszat is tenni, és nem fogja ellenőrizni a driver, hogy amit a program ki akar törölni, az egyáltalán kitörölhető-e. Erre van az explicit API-khoz egy validátor, ami megmondja, ha a program hülyeséget csinál. Na most úgy nem szabad kiadni egy programot, amíg a validátor hibát jelez. Ezért nincs publikusan kiadva a DX12 benchmark, amit a sajtó egyébként már elér.
-
Abu85
HÁZIGAZDA
válasz
velizare
#17131
üzenetére
Nem. Egyszerűen csak nincs kiadható állapotban.
(#17132) Szaby59: A játékok 99,9%-a félkész. A gond az, hogy nincs elég idő megírni az egészet, hogy teljesen optimalizált legyen. Alig egy-két stúdió figyel oda arra, hogy egy rakás energiát beleöljenek a DX12 mellett a DX11-es kódba, de ez valójában nem éri meg, mert amit gyorsan elérsz a DX12-vel sebességet, azt a DX11-gyel jó másfél éves extra munkával lehet hozni. Puszi a hasára mondjuk az Oxide-nak, hogy ők ezt felvállalják, és véglegekig szétoptimalizálják a motort, de a valóság az, hogy a kőkemény határidőket szabó kiadók többségének nem éri meg a megjelenést másfél évvel eltolni. Ilyen körülmények között a DX12 előny, mert sokkal gyorsabban eljuttat arra a sebességszintre, ami a cél volt. A DX11-et pedig vagy befoltozzák az elkövetkező évben, vagy ráhagyják.
-
Abu85
HÁZIGAZDA
válasz
velizare
#17128
üzenetére
A Polaris startjához érkezik a DX12 mód. De van már a sajtónak DX12 tesztprogramja előzetes kóddal. Cirka 60%-os extrát dob még erős procival is. Nekem úgy jó 90%-ot gyorsít. Valószínűleg a DX11-es kóddal már nem foglalkoztak annyit a fejlesztők, így abból nem hoztak ki mindent. Túl költséges lett volna.
(#17129) Locutus: Akit nem érdekel a DX12, az vehet CF XDMA rendszert vagy egynyákos multi GPU-t és az DX11-ben is skálázódik.
-
Abu85
HÁZIGAZDA
válasz
velizare
#17119
üzenetére
A CF-ből is csak az XDMA, illetve az egynyákos megoldás működik. A hidas SLI/CF konstrukciók negatívba skálázódnának. Ezért tiltva vannak driverből, persze lehet, hogy találnak valami megoldást később. Ugyanakkor lesz a DX12-es módnak multiadapter opciója, ami már ugye nem azokat a szerencsétlenül lassú hidakat használja. Na az skálázódni fog mindenhol.
-
Abu85
HÁZIGAZDA
válasz
Laja333
#17086
üzenetére
Rosszul. Az AMD elég régóta csak multiprecíziós ALU-kat tervez, tehát minden ALU támogat minden műveletet, de nyilván ezt le kell osztani az igényekre, mert például az interpoláció nem ingyenes, így az elviszi az ALU-k egy részét. Viszont számos DX12 funkció manuális interpolációt követel.
Az Intel is hasonló konstrukcióval dolgozik, csak nem mindegyik ALU-juk multiprecíziós. Manapság az ALU-ik fele az.
Az NV nem használ multiprecíziós ALU-kat, mert nehéz megtervezni őket. Helyette dedikált egységeket raknak be az egyes feladatokhoz. Egy CUDA magban van FP és integer ALU is, és egyik sem tud speciális utasítást végrehajtani, ahogy az interpolációt sem oldják meg. Így nem tudnak támogatni számos DX12 funkciót, de dedikálva lesz a munkára a részegység. -
#17085
Abu85
HÁZIGAZDA
#Morcosmedve
#17076
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#17076
üzenetére
Ezeket az újításokat mindenki komolyan veszi. Mint írtam minden gyártónál vannak erre vonatkozó kutatások, csak nem ugyanott tartanak. Az AMD gyakorlatban is beveti az explicit API-k problémáinak megoldásait. De mondom nekik könnyű volt, mert ők 2012-ben már mértek, míg a többiek olyan szoftverkonstrukciókhoz csak 2014-ben jutottak, amellyel valóban mérni lehetett.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#17075
üzenetére
Az ALU szám olyan értelmezésben, ahogy ti nézitek nagyon csalóka, mert a nem megfelelő magyarázatok miatt csak FP32 ALU-t számoltok. Ezenkívül azért vannak még más ALU-k is, vagy nincsenek. Például az interpolációnál az AMD manuális megoldást alkalmaz. Emiatt képes támogatni a rendszer a konzolos analitikai AA-kat, illetve a GS emuláció nélküli VP/RT tömbindexet a shader lépcsőkből a raszterizálóig. Ezekre az NVIDIA architektúrái nem képesek, így az ezeket kihasználó konzolos effektek nem futnak majd le. Ezeket a konzolos kódokat át kell írni az NV-nek a nem szabványos dedikált interpolációs és viewport struktúrájára (ha majd lesz kiterjesztés). Viszont az NV a dedikált interpolációt SFU-ból csinálja.
Szóval ez az ALU szám=ALU szám nagyon elméleti alapú.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#17063
üzenetére
Ezekről még nem lehet beszélni, de jön pár olyan dolog a Polarisban, amelyek évek óta kutatási alapnak számítanak minden gyártónál, de senkinek nem sikerült még a gyakorlatban implementálni. Ezeknek a dolgoknak a többsége a hatékonyság drasztikus növelését célozza. Később más is előáll majd hasonló konstrukciókkal, amint végigfutnak a kutatások, és ténylegesen bevethetők lesznek. Itt azért van egy olyan időbeli probléma, hogy az AMD már 2012-ban tesztelte, hogy mi kell az explicit API-ra, míg a többiek csak 2014-ben tudták meg, hogy hol vannak a GPU-kban a szűk keresztmetszetek ezekkel az új irányokkal. Nyilván az egyes problémákra csak akkor lehet reagálni, ha ki tudod azt mérni.
-
Abu85
HÁZIGAZDA
válasz
mcwolf79
#17061
üzenetére
Az OnlyAMDFeature nem igazán volt cél korábban. Legalábbis törekedtek arra, hogy amit csinálnak az lehetőség szerint legyen szabványos. Ez már csak azért is kell, mert nem elég nagy a PC-piac, hogy speciális dolgokkal foglalkozzanak a fejlesztők.
A GPUOpen hozza, illetve hozta ebben a törést, amikor az AMD már nem csak a PC-re dolgozik, hanem a PC+PS4+Xbox One kombinációra. És úgy már elég nagy a piac ahhoz, hogy a fejlesztők speciális dolgokkal foglalkozzanak. Jött is az OOO-raszter, illetve az mbcnt. Mindkettő csak a kezdet, de ezeket kérik a leginkább a konzolról portoló fejlesztők. Jön még a ds_swizzle és a writelane, illetve az ordered atomics. -
Abu85
HÁZIGAZDA
válasz
keIdor
#17055
üzenetére
A dadogás attól jön, hogy állandó a vertikális szinkron. Ez nem a gyártók hibája, hanem az alkalmazásé. Amint 60 fps-ről leesik akármennyire picit az fps akadni fog egyet. De az MS ezt már megoldotta. Go Windows update és leszedi a két új flipchain API-t, ami ezt kijavítja. A Forza 6 Apex erre tartalmaz már egy implementációt is, ha frissíted az alkalmazást. Probléma letudva.
Igen, mert az AMD-n ütközött a hapsi. Ez egy játékbeli bug, ami ütközésnél előjöhet. Szintén javítva lett egy javítással. Ezek a dolgok a DX12-vel nem kizárhatók, mert a meghajtó már nem játszik szerepet, így az alkalmazásfejlesztő elronthatja a menedzsmentet. Nyilván ennek az előnye, hogy olyan, hogy képi driverhiba nem létezik többet, de a hátránya, hogy az alkalmazás oldalán kell megírni hibátlanra.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#17052
üzenetére
[link] - Forza 6 Apex DX12 390 vs 970.
Valójában az architektúra nem annyira fontos. A GCN1-2-3 között elég sok különbség van, de a lényeg az, hogy az alap, az ALU:Tex arány, a regisztertár, a gyorsítótárak kapacitása megegyezik mindhárom verzióban. Ez okozza azt, hogy a GCN1 is fejlődni tud még ma is, mert a multiprocesszor struktúrája nem változott meg. Az NV és az Intel is ilyen eltérésekkel dolgozik, de ott a főbb gond az, hogy a multiprocesszorok mindig változnak, mert nem találják az optimális arányokat, vagy az optimális arányra nincs elég tranzisztor, stb. Ez tesz be a programozóknak, és nem az, hogy az egyik Kepler, míg a másik Maxwell.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#16774
üzenetére
Miért szerinted normális, hogy nekik van egy eredménysoruk, és rajtuk kívül senki, ismétlem senki sem mért még csak hasonlót sem? De elfogadható úgy, ha nem frissítik a programot, mert ez nálunk is probléma szokott lenni. Időnként annyi eredményt kell áthozni régebbről, hogy kimarad a frissítés, és akkor a mi eredményünk is eltér a többi eredménytől. Persze manapság igyekszünk állandó jelleggel frissíteni, de biztos, hogy az Anand dolga egyszerűbb volt négy méréssel, mint a Guru3D dolga két tucat méréssel. Előbbiért megéri frissíteni, míg utóbbiért nem.
(#16776) Szaby59: Nem. De a CPU limitet is nagyon félreértitek. A GPU-k belül nem olyan homogén rendszerek, mint amilyennek le vannak festve. Valójában ezek rendkívül rendkívül heterogén konstrukciók, amelyeknek a belső kihasználása úgy nő, ahogy nő a kiszámítandó pixelek száma. Már csak azért is, mert a geometria jellege a jelenet szintjén állandó, miközben a pixelek mérete nem, így a raszterizálás hatékonysága is állandóan nő a felbontás növelésével.
-
Abu85
HÁZIGAZDA
Másfelé nem lehet menni. Ez igazából az egész iparágban ismert. Azóta kezdődött el az erős váltás, amikor bejött a compute shader. Ennek a váltásnak a közepén tartunk.
Az ALU azért lényeges a skálázás szempontjából, mert jóval kevesebb limitbe lehet ütközni ezekkel a konstrukciókkal, mint a tradicionális grafikai megoldásokkal. Mivel mindenki ezt az irányt erősíti, nehéz kétségbe vonni, hogy az ALU powa a nyerő. Legalábbis nem látom senkin, hogy megoldást keresne a sávszélproblémára, vagy a quad raszter problémára. Az ALU sem hibátlan persze, hiszen az új API-k miatt jönnek majd a futószalagidőből adódó limitek, de talán lesz erre valamilyen megoldás a jövőben.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#16767
üzenetére
Nézzétek terhelés mellett is. Ezeknek a VGA-knak a Full HD olyan, mint régen a 640x480 volt.
Egyébként a Guru3D eredményei manapság állandóan furcsák, valami van a tesztkonfigjukkal. Lassan pár hónapja össze-vissza mérnek. Persze az is lehet, hogy nem patch-elik a játékokat. Amilyen sok eredményt hordoznak simán elképzelhető, hogy nem fér bele mindent mindig újramérni. Emiatt viszont az eredmények sem elég frissek.
-
-
Abu85
HÁZIGAZDA
válasz
#85552128
#16763
üzenetére
Ne a Fury X gyorsulásához mérd ennek a gyorsulását. Közel sem tudnak annyit a Pascal GMU-k, mint amennyit a Fiji dedikált compute parancsmotorjai. Inkább a Tahiti GPU-hoz képest kellene megnézni, mert hardveresen kb. azon a szinten van a GP104 az aszinkron compute szempontjából.
-
Abu85
HÁZIGAZDA
válasz
stratova
#16709
üzenetére
Meg. Ezek nem szándékos dolgok, csak az idő szűkössége miatt nem mindig lesznek jelentve. Ez visszavezethető teszthiányra is. Például arra, hogy az ID csak a legújabb architektúrákon nézte meg, és azzal jó volt, így gondolták minden jó lesz. A legfőbb indok az explicit elérés mellett lényegében ez, hogy a meghajtótól ne függjön annyi, így a fejlesztők rá lesznek kényszerítve, hogy alaposan teszteljenek.
-
-
#16574
Abu85
HÁZIGAZDA
gainwardgs
#16572
Abu85
HÁZIGAZDA
válasz
gainwardgs
#16572
üzenetére
Tudtommal egy rasterizationorder kiterjesztésről van szó, ami igazából a futtathatóságot nem befolyásolja, csak jelentősen növeli a tempót. Jó lenne látni a kiterjesztés specifikációját. Ezért írtam, hogy ez nagy kérdés, amit izgalmas lenne kideríteni, csak mindenki hallgat, mint a sír.
-
Abu85
HÁZIGAZDA
válasz
Dyingsoul
#16566
üzenetére
vitko és Szaby: Szerintem januárban vagy még márciusban sem tudták a BF megjelenését. Ahhoz kell igazodni. Ez a lényeg igazából. Igazodni a DICE projektjéhez, hogy legyen hardver a Battlefield 1-hez!!!
Az igazán nagy kérdés egyébként az, hogy az a Vulkan kiterjesztés, amire a BF1 épít csak a Vega mellett érhető el, vagy a Polarissal is. Ezt azért fontos lenne megtudni. -
Abu85
HÁZIGAZDA
válasz
#85552128
#16563
üzenetére
[link] - ebben van a legfrissebb publikus. Amit beraktál nem tudom, hogy honnan veszed, hogy friss. A saját szememmel láttam a januári CES-es konferencia eladáson. Azóta a GDC-s roadmapot használja az AMD. De mondom van egy újabb, az elég részletes, de az nem publikus, így nem lehet kirakni. De lehet, hogy valaki kiszivárogtatja.
-
-
#16557
Abu85
HÁZIGAZDA
Malibutomi
#16555
Abu85
HÁZIGAZDA
válasz
Malibutomi
#16555
üzenetére
Maximum a dobozos termékeknél, de fontos tényező, hogy a 300+ dolláros szinten az eladott VGA-k 70%-a komplett gépben talál gazdára. Tehát fontos, hogy az OEM-eknek legyen valami marketingalapjuk az új komplett gépekhez.
(elővigyázatosság, hogy ne frissüljön az alkalmazás). Persze lehet, hogy egyet-egyet a neten futtatunk, de amikor élesben megy, akkor sosem. Ezt nem tudom, hogy kinek van kedve a mi nevünkkel nyomulni, lehet, hogy nem mi vagyunk azok, mert nem PH-s nevet szoktunk használni. Persze az AotS-re van több accountunk. Az az app legalább háromszor megvan. 
Ú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.
- Samsung Galaxy A16 / 4/128GB / Kártyafüggetlen / 12Hó Ganacia / BONTATLAN NULL Perces!
- Azonnali készpénzes nVidia RTX 3000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- BESZÁMÍTÁS! LG UltraGear 32GR93U-B 32 144Hz IPS UHD 1ms monitor garanciával hibátlan működéssel
- LG 32SQ700S-W - 32" VA Smart - 3840x2160 4K UHD - 62Hz 5ms - WebOS - Wifi + BT - USB-C - Hangszórók
- HP ZBook Firefly 14 i7-1165G7 16GB 512GB Nvidia Quadro T500 4GB 14" FHD 1 év garancia
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest