Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13326
üzenetére
Nem érteni kell hozzá, hanem pénz kell hozzá. És az MS-nek van pénze ahhoz, hogy az Epic pénzhiány miatt érdektelenné vált, jellemzően komolyabb fejlesztéseit kiegészítse, normálisan megcsinálja. Ennyi a titok. Csak sajnos ami hiányzik az Epicnél, az hiányzik azoknál a stúdióknál is, akik azért választják az UE4-et, mert a kezdés ingyenes.
Fel kell fogni, hogy abba az egyébként tényleg baráti üzleti modellbe, amit az Epic kínál már nem igazán lehet minden egyes platformra minőséget építeni. -
Abu85
HÁZIGAZDA
válasz
TTomax
#13323
üzenetére
Azt tudom, hogy a Daylight mobil leképezőt használt és azon ment is az AFR. A többi játékot annyira nem követtem. A Daylightot is csak azért, mert az első UE4-es cím volt, persze akkor még nem volt igazán jól optimalizálva a motor a mobil leképezővel sem.
A DX12 csak a PC-es leképezőre készült el. A mobil leképező Vulkan alatt lesz használható. Egyedül Metal API-val választható meg a leképező. Persze a DX12-es mód az UE4-ben elég gyenge. Nagyon sokszor abnormálisan működik, valószínűleg az Epic is azt várja, hogy a Microsoft odaadja nekik a saját DX12 portját, és ezt biztos megteszik, így az Epic számára nincs különösebb szükség ebbe pénzt rakni. -
Abu85
HÁZIGAZDA
válasz
Areturus
#13320
üzenetére
Radeonra talán át tudják hozni, de nem hiszem, hogy általánosan elég stabil a kiadásra. Az a baj, hogy az UE4-nek is van DX12 módja, de az elég rossz. Az ARK-nál írták egy módosítást X1-re és szerintem eddig jutottak. Az lenne a legjobb, ha a Microsoft DX12 leképezőjét beleraknák az UE4 main branch-be, mert az működik a Fable-ben.
DX12 drivert használó IGP kell és elég a GPUMMU mód. -
-
#13318
Abu85
HÁZIGAZDA
huskydog17
#13311
Abu85
HÁZIGAZDA
válasz
huskydog17
#13311
üzenetére
Többször írtam már, hogy az UE4-nek két leképezője van, és a PC-s leképező optimalizálása nagyon rossz. A Microsoft sem ezt használja, hanem írtak egy sajátot. Ez van. Az Epic számára a mobil leképező a fontos, és az nagyon is jó.
-
#13305
Abu85
HÁZIGAZDA
huskydog17
#13293
Abu85
HÁZIGAZDA
válasz
huskydog17
#13293
üzenetére
A Tencent több pénzt akar rakni a kutatásba, így nekik a GPUOpen nagyon fontos. Ők egy olyan modellt akarnak kialakítani, mint az EA, hogy mindent házon belül csinálnak. Ez amiatt is fontos, mert saját konzolt csinálnak, illetve ezt kiterjesztik egy saját operációs rendszerre, így bárki tervezhet a Tencent OS-hez konzolt. Szóval elég durván le fogják támadni a kínai piacot a közeljövőben. Van még VR projektjük is csak még nem jelentették be hivatalosan, de azt már elmondták, hogy a teljes kínai VR-piacot uralni szeretnék.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13267
üzenetére
A Feature levelt furcsamód a D3D12 legacy funkcióként specifikálja. Ergo egyetlen program sem írható meg aszerint, hogy a Feature level szintet lekérdezi a fejlesztő. Helyette egyenként kell lekérdezni az egyes funkciók meglétét. Ilyen formában ez egy szükségtelen paraméter, mert semmit sem definiál a program számára.
-
Abu85
HÁZIGAZDA
válasz
Areturus
#13264
üzenetére
Köszi. Igen az "and" egy hiba. Ki fogom javítani.
A sztereó 3D kötelező. A shader modell esetében is mindenki a legjobbat kell, hogy támogassa. SAD4 is kötelező lett, akinek nincs rá hardvere írnia kell a driverbe egy emulációt, de ezt a funkciót átrakták a DXGI-ba, hogy ne csak a DirectX érhesse el. A dedikált atomi számláló is kötelező lett, ha nem tudja a hardver, akkor emulálni kell annyit, amennyit az API megkövetel. Emiatt van kétféle ajánlás a DX12-nél. Az AMD azt ajánlja, hogy használj Atomicot, mert gyors, míg az NV és az Intel ennek az ellentétét ajánlja, mert az API már nem különbözteti meg a hardvert az emulációtól.
Az is. De a Full Heap mérete architektúránként más.
A Tiled Texture3D nem emulálható. Alternatív algoritmus írható csak.
-
Abu85
HÁZIGAZDA
Egész korrekt lett a Vulkan specifikáció. Just saying...
Nem olyan vagy mindent vagy semmit elvű a multi-engine koncepció, mint a DX12-nél. Vulkan alatt a Maxwell és a Kepler is aránylag normálisan tudja majd támogatni az aszinkron compute-ot. Legalábbis egyszerűen megoldható, hogy szabványos kódtól nem pusztuljon meg, így nem kell külön kódbázis rá, és még érni is fog valamit a párhuzamosítás. A Khronos most nagyon odatette magát, így szerintem a Vulkan jobb API lett. -
Abu85
HÁZIGAZDA
válasz
Areturus
#13240
üzenetére
Ezt egyébként tényleg nem értem, hogy miért gyártanak összeesküvéseket sokan. Én sem láttam még stabil UE4-es DX12 kódot. A Microsofté kb. stabil, de ennyi. Ha nekik nem stabil, akkor nem éri meg kiadni. Elvégre egy csomó dolog a driver eddigi munkájából átkerült a programkódba.
Azt is elmondta a végén, hogy az NV messze van az AMD-től ha a párhuzamosításról van szó, de ez is csak egy javítandó probléma. Mondjuk ezt nem írtam volna le a helyében, mert a következő összeesküvés az lesz, hogy megerősítette, hogy az NV-n nem megy jól. Biztos azért nem jön a DX12 mód.
-
Abu85
HÁZIGAZDA
válasz
nonsen5e
#13233
üzenetére
Az Epicet nem érdekli, hogy ki milyen Flappy Bird klónt készít vele, csak használják. Akármilyen semmi a játék a motor alatta lehet UE4, mert erre mentek el a licenckonstrukcióban. A bevételük zöme már innen származik, ezért fektetnek sokkal többet a mobil leképezőbe. Az egész jól működik. Az asztali leképező sajnos eléggé optimalizálatlan, ami arra vezethető vissza, hogy kevés pénzt raknak bele. Az, hogy nem lesz normális dGPU+dGPU szintű multi-GPU meg múltkor durván kiverte a biztosítékot, de az Epic helyzete érthető. Egyszerűen versenyképtelenek a Frostbite és a többi belsős projekttel, így inkább a tömegek igényeire mennek rá.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13231
üzenetére
Az ARK nehéz ügy, mert Unreal Engine 4-es. Az Epic nagyon kevés erőforrást fektet a komolyabb leképezőbe, mert a motort zömében mobilhoz használják. Az Android a célpiac, és az ahhoz készült leképező nagyon jól optimalizált, de nem ezt használja az ARM. Xbox One-on egyébként már DX12-ben fut a program, de csak azért, mert oda elérhető a Microsoft optimalizálása az Unreal Engine 4-re. Ezt elég sokára fogják visszaírni a főverzióba. Ergo vagy megoldják maguk az Xbox One kód alapján, vagy várnak az Epicre, amíg hajlandó ránézni a PC-re. Az a baj, hogy az Epic számára ez nem fontos. A multi-GPU-t is csak IGP+dGPU-ra írják meg, míg hagyományos formára nem. Azt is elmondta Sweeney, hogy nem éri meg pénzt költeni rá.
-
Abu85
HÁZIGAZDA
válasz
#45185024
#13223
üzenetére
De, hiszen a DX12 API-n fut.
A volumetrikus megvilágítás a Rise of the Tomb Raiderben multi-engine módban, vagyis aszinkron compute-ban van számolva a shadow mapokkal párhuzamosan.
Minden DX12 kód kötelezően multi-engine. Single-engine módot az API nem is definiál.(#13224) Szaby59: Nem fontos annyira, de nézd az MS nézőpontjából. Nekik pont az a lényeg, hogy megmutathassák a piacnak, hogy elég a kódot az Xbox One-ra megírni és az jöhet PC-re. Nekik ehhez példákat kell hozni.
A Frostbite-nak a Vulkan kedvezőbb, mint a DX12. Ők csak ott akarnak a Windows 10-hez kötődni, ahol muszáj, amúgy inkább platformfüggetlenül gondolkodnak. -
Abu85
HÁZIGAZDA
A RotTR-hez nem kell DX12 leképezőt írni, egyszerűen csak pár sor kell az Xbox One leképező elejére. Vagy az sem, mert előre beleírták. A Microsoft a játékaival ezt akarja demostrálni. Persze lehet tovább is optimalizálni PC-re.
Az új TR Xbox One-on ugyanazon a DX12 API-n fut, ami a Win10-hez van. -
Abu85
HÁZIGAZDA
-
#13204
Abu85
HÁZIGAZDA
Firestormhun
#13203
Abu85
HÁZIGAZDA
válasz
Firestormhun
#13203
üzenetére
A broad temporal ambient obscurance nem AO, hanem obscurance fields alapú technika. A AO mellette egy HDAO. Az sample distribution shadows map egy Z partícionáló kiterjesztés. Ez kiegészíti a CHS-t. Ettől hatékonyabb lesz.
Kizárólag az AMD-é a TressFX. A felhasználása szabad csak.
A VXGI AO only opció eleve egy DX11-es effekt volt még 2014-ben, amikor szó volt róla. Azt is elmondták, hogy Full HD-ben egy GTX 770 3,8 ms alatt számolja. Persze ez az akkori kód volt.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13197
üzenetére
De nem olyan dolog ez, hogy odamész és azt mondod, hogy légyszi cseréld ki. Azon a minőségi szinten, amit a Microsoft elvár ez legalább úgy egy éves procedúrával járna, amíg az odavitt middleware-khez úgy módosítják a leképezőt, hogy jó legyen. Egy hónappal a megjelenés előtt ilyet nem fog bevállalni senki.
(#13198) Gertrius: Az a Voxel-based Ambient Occlusion. Még az eredeti VXGI effektnek egy mellékága lett, mert a VXGI nem támogatja az animációt, de VXAO-val nem kötelező a dinamikus objektumokat számításba venni, így lehet csak a statikus geometriára dolgozni. Több cégnél is elindult ez a kutatás csak aztán leállt, mert az obscurance fields jobb eredményt ad, de csak töredéke a hardverre kifejtett terhelése és mozgást is támogat.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13195
üzenetére
Mire cserélnék a TressFX-et? Nem lehet csak úgy kicserélni ezeket az effekteket egy hónap alatt. Vagy marad minden, ami a konzolverzióban volt, vagy szimplán letiltásra kerülnek a PC-s verzióban. Az biztos, hogy az Xbox One-on van számos korábbról használt AMD-s effekt, mint a TressFX, a HDAO és a CHS, illetve van még egy mozaikos gyorsítással dolgozó részecskeszimuláció is, ami szintén az AMD-é, és a Dirt Rally már használta.
-
Abu85
HÁZIGAZDA
Na szóval a sikerült pár dolgot megkérdeznem. A Nixxes mondta, hogy valóban részt vesznek a portolásban, de ez csak mellékprojekt. Egészen pontosan a DX11-es leképezőn dolgoznak, illetve megpróbálják a 32 bites módot összehegeszteni, de inkább 64 bitre kell készülni, mert memóriából relatíve sok kell a játéknak. A többi hardverelem szempontjából nagyon alap igények vannak.
-
Abu85
HÁZIGAZDA
A Nixxes elég gyorsan frissül listájában csak az van, hogy Xbox 360-hoz készítették a portot. Mondjuk ettől a CD mellett ők is fejlesztők, csak kérdés, hogy a PC verzióra is azok-e, mert hivatalosan ők csak Xbox 360-ra vannak odaírva. Azért nem szabad elfelejteni, hogy ők már két projektet csinálnak, és ez nem egy nagy csapat. Csupán 20-30 fő közötti a létszám. Szóval összességében sok embert nem adhattak egy harmadik projekthez, de egy ember is elég ahhoz, hogy listázva legyenek. Az más kérdés, hogy ezt mennyire tekintik saját portnak.
Az meg logikus, hogy kell a Windows 10, amikor a játéknak tudtommal csak DX12-es (Xbox One) leképezője van. Ez nem meglepetés.
A Steam pedig elfogad 3rd party DRM-et, így jó a Winstore is, ahogy a Uplay is például. -
Abu85
HÁZIGAZDA
válasz
füles_
#13142
üzenetére
Kellene egy újabb driver, mert a DiRT Rally végleges kódja sokat változott az Early Accesshez képest. És az új drivert úgy értem, hogy az NV-nél még nem jelent meg olyan driver, amely megjeleníti az összes objektumot. Szóval ott még várni kell egy januári frissítésre. Ilyen formában ez a játék még nem jó tesztre, mert a végleges kód az eddigi optimalizálást elkaszálta.
(#13141) daveoff: Leírtam már régebben, hogy az AMD partnere a Nixxes, illetve a Square Enixnek az EIDOS csoportja. Ők is csak azért, mert nem hajlandók az NV-vel dolgozni. A Rise of the Tomb Raider nem kapcsolódik az EIDOS csoporthoz, vagy a Nixxeshez. A Microsoft technikai csoportja segített összerakni. Gyártói szerződést ők nem kötöttek, mert több régióban is a Microsofté a kiadás joga, de ha a gyártók megveszik megfelelően magas áron, akkor nyilván adnak kulcsokat. Az AMD-nek ez egy Star Wars Battlefront után nem ideális, mert az EA is olyan, hogy dömpingárat nem szokásuk biztosítani.
-
#13134
Abu85
HÁZIGAZDA
huskydog17
#13124
Abu85
HÁZIGAZDA
válasz
huskydog17
#13124
üzenetére
Éppenséggel esélyük lenne javítani rajta csak az egész projekt eleve pengeélen táncolt. A Raven's Cry eredeti fejlesztőit a fejlesztés közben kicsapták. Az AMD ekkor elvett minden segítséget a projekttől, mert a törlés szélére került. Ekkor jött a Reality Pump, akiket kijelölt a kiadó, hogy hozzák rendbe a játékot. Ebből lett végül a Raven's Cry. Viszont tiszta bug volt így is, ami érhető, mert marhára időre dolgoztak. A Reality Pump nagyon sok szempontból abból a tudásból él, amit az AMD otthagyott nekik a Two Worlds II kiegészítőjénél. 2012 végéig élt a szerződésük, és addig a GRACE 2-t optimalizálták. Többek között visszafejtették nekik a Keplert is. De 2013-ban már nem újították meg a szerződést, így a Reality Pump kvázi magára maradt. Ez meglátszik a technikán is, ami megragadt azon a szinten. A Maxwellt már senki sem segített nekik visszafejteni, pénzük pedig gondolom nem volt rá.
-
Abu85
HÁZIGAZDA
Többször leírtam az okot. A Kepler esetében a magok 33%-a elvész, ha nem optimalizálod jól. Érdekes, hogy sokan jól csinálják, és még a Maxwell is jó.
Nekem mindegy, hogy mit csinálnak, mert ez is csak üzlet. De nem értek egyet vele, mert honnan vagyok kibiztosítva, hogy nem csinálják majd ugyanezt a Maxwellel? Az persze, hogy a Kepler esetében nem tapsikolnak a userek a helyzetre reménykeltő.
A GameWorks esetében a probléma mindig is az volt, hogy rossz minőségű és optimalizálatlan, illetve átgondolatlan. Ez érint minden hardvert. Néha a Keplert jobban. Az igazi probléma a Keplernél a TWIMTBP.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13097
üzenetére
Pont az a lényege a multi-draw indirectnek, hogy ezt lecsökkentse. Az nagyon fontos még a Frostbite motorokban, hogy a pre-render egy natív motorbeállítás és nagyon eltérő a gyártók között. Az AMD csak egyet számol előre, míg az NV ötöt. Az Intel háromra van kalibrálva. Emiatt az AMD-t másképp kell kezelni a DX11-ben, mint a többi gyártót, mert jóval alacsonyabb az input lag. A DX12 és a Vulkan ezt is megváltoztatja. Ott mindenkinek egy lesz a pre-render. Ez nagyrészt egyébként meghajtókonfiguráció eredménye. Az AMD az elmúlt években sokat költött arra, hogy az input lag rohadt alacsony legyen, és a Crimson drivertől kezdve minden esetben alapértelmezetten 1 a pre-render. A többi gyártó az egyet nem kockáztatja meg, mert nem fektettek be ide szinte semmi pénzt. Inkább 3-5 közötti a pre-render.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#13093
üzenetére
Olvasd el a többi részét is a hsz-nek. Ezek a funkciók már működnek benne, de csak az AMD szervizkönyvtárán keresztül. A többi hardverre a DX12 és a Vulkan a megoldás, mert a DX11 nem támogatja szabványos formában a multi-draw indirectet. Az egészet azért fejlesztette ki a Frostbite Team, mert az AMD csinált hozzá egy kiterjesztést, és erre a kiterjesztésre építették a mainline kódot, mondván a DX12 és a Vulkan úgyis támogatni fogja a GPU-driven pipeline-t. Ennek a fő célja egyébként az overhead kezelése úgy, hogy ne essen le tartósan a sebesség az egyes helyeken, de ezt csak az AMD-re tudják "ma" megcsinálni. "Holnap" már másra is.
-
Abu85
HÁZIGAZDA
A Battlefronthoz annyit tennék hozzá, hogy az új Frostbite verziónak vannak olyan kiterjesztései, amelyek a DX11 API-ban nincsenek benne. Többek között az új Frostbite már GPU-driven pipeline-t használ, amit a DX11 nem specifikál. Emellett az NV és az Intel sem rendelkezik rá DX11 kiterjesztéssel, de az AMD-nek van egy AGSL 3.0-ja DX11-es multi-draw indirect kiterjesztéssel. Erre épül az új Frostbite kódja, míg a többi hardveren egy alternatív kódbázis van, amely multi-draw indirect nélkül is megoldja a rajzolást. Utóbbi viszont előnyösebb, mert töredék rajzolásból megcsinál mindent, tehát az AMD-nek az AGSL 3.0-val jóval kevesebb többletterheléssel kell számolnia, mint a Intelnek és az NV-nek.
A DX12 és a Vulkan ezt a multi-draw indirectet támogatni fogja szabványosan is. -
Abu85
HÁZIGAZDA
Nem. Te azt mondtad, hogy a hiba nem tuninghoz kötődik. Valójában ahhoz kötődik.
Ha szerinted normális, hogy a 780 a 960 szintjén van pár TWIMTBP játékban, miközben számos játékban a 970-nel küzd, akkor az a te dolgod. Szerintem viszont nem normális, és számos Kepler tulaj szerint sem az, aminek hangot is adnak még az NV fórumán is. Szerintem jól teszik. Próbálják elérni, hogy nagyobb teljesítményt kapjanak, hogy egy 384 bites egykori csúcsmodellt ne verjen el egy 128 bites új talicska, mert amikor megvették a 780-at, akkor bizonyosan nem erre számítottak.
-
Abu85
HÁZIGAZDA
De a tuninghoz kapcsolódott, mert az Overdrive modul onnantól működött rosszul, hogy megváltoztattad a venti szabályozást. Ha azt nem bántottad, akkor nem jött elő a hiba. Ezt onnan tudom, hogy az overdrive modult én használtam még a kiadás előtt, és három játékhoz beállítottam külön órajelet, hogy működik-e a játékokra lebontott tuning, persze a ventihez nem nyúltam, mert az elvégzi a feladatát tuninggal is, hiszen a BIOS-ban leírt profilnál úgy sem tudok neki jobban csinálni. Ilyen formában a venti nem ragadt be.
Természetesen addig eljutnak, hogy aktiválják a modul egyes elemeit, de pont az volt a baj, hogy a tuningra vonatkozott a hiba. Tuningot pedig már nem tesztel senki. Ameddig bekapcsoltad a funkcióit, addig nem jelzett problémát, márpedig az alap teszprotokoll kimerül abban, hogy aktiválják és működik-e. Ilyen formában átment a meghajtó, mert működött. Azoknál nem működött, akik megváltoztatták a tuningbeállításokat.
Arra kérsz bizonyítékot, hogy tuningot senki sem tesztel? Ez a legegyértelműbb dolog. Mit teszteljenek rajta? Nem fogják 1 MHz-enként és 1%-onként az összes nagyjából 1-2 millió kombinációt kártyánként ellenőrizni. Erre nincs kapacitás sehol. Azt csinálják meg, hogy aktiválják a funkciókat és az aktiválás működik-e. Ez működött. Ez az, amit reálisan lehet tesztelni kártyánként. Ez így is elvihet két napot.
Mondtam példát, csak nem tartottad elég jónak. Még linkeltem is az NV felhasználók fórumát, akik elégedetlenek azzal, amit az NV csinál a Keplerrel.
(#13037) ffodi: Nem arról van szó, hogy nem probléma, csak nem olyan probléma, amivel kapcsolatban bárki felelősségre vonható, mert egy olyan modulon belül volt a hiba, amelynek az aktiválásához el kell fogadnod, hogy a gyártó mentesül minden felelősség alól. Ez pont azért van így csinálva, mert képtelenség VGA-nként egymillió konfigurációt végigtesztelni. Tegyük fel, hogy egymillió lehetséges kombinációt kell tesztelni 100 VGA-ra. Az 100 millió teszt, és egy stabilitásteszt 8 órás. Tehát egy meghajtó tesztje 800 millió óra lenne. Ez képtelenség. Ezért jobb a tuningra nem vállalni garanciát.
A tönkretétel egy kamu volt. Egyetlen ember sem jelentkezett a twitteren azok közül, akik beírták, hogy tönkrement a Radeonjuk. Pedig felajánlották mindnek a cserét.
Az overdrive modul eleve a drivertől független settings modul része. Ha utóbbit nem telepíted attól a meghajtó működni fog.(#13038) FLATRONW: Én is arra gondoltam. Volt olyanom. Ma már nincs, mert a GPU PhysX leállt. A Witcher 3-ban is csak lassulást okoz.
(#13041) schawo: Nem hiszem, hogy akármelyik bíróság érvénytelenítene egy olyan EULA-t, amely azt fogadtatja el a felhasználóval, hogy a termék nem rendeltetésszerű használata okozta hiba a user felelőssége.
(#13042) Macka: Azokban a tuningprogramokban is van hiba, amelyeket a gyártók az GeForce-okhoz adnak. Csak az NVIDIA nem teszi lehetővé a tuningot egy gyári modulból, de registry módosítással lehet.
(#13048) Egon: Ez tévedés. A tuningra akkor sincs garancia, ha 1 MHz-et emelsz rajta, és hibátlanul működik. Megteheted, hogy tuningolod, de garanciát senki sem vállal rá. Akármilyen hiba jön elő a te felelősséged, mert egy olyan szerződés elfogadása után egyetlen programban sem lehet tuningolni, ahol te nem fogadtad el azt a feltételt, hogy az esetleges hibák téged és kizárólag téged terhelnek.
Ha aktiváltad az overdrive-ot attól még működött. Onnantól nem működött, hogy kézi ventivezérlésre kapcsoltad, vagyis bekapcsoltál egy tuningfunkciót.(#13050) daveoff: Azért nem csinálják azt, mert az AMD-nek PowerTune technológiája van a hardver vezérlésére és ez nem szoftveres, hanem teljesen hardveres rendszer. Ezt a technológiát annyira védik, hogy még a gyártóknak sem árulják el a működését, így a gyártói tuningprogramok is abból élnek meg, hogy az egyes PowerTune verziókat visszafejtik. Ezért késik mindig az új Radeon VGA-k tuningjának támogatása a 3rd party programokból. Az NV által használt rendszer félig szoftveres csomag, vagyis tulajdonképpen egy szoftvert kérdez meg a hardver, hogy az egyes állapotokra mit lépjen. Ezt jóval egyszerűbb lekövetni, mint az AMD PowerTune rendszerének szoftveres hátterét feltörni. Emiatt csak az AMD képes arra, hogy a PowerTune profilhoz szabott tuningfunkciót biztosítson.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#13029
üzenetére
Hibátlan meghajtó természetesen sosem lesz, de a gond amiről beszélünk nem jött elő mindaddig, amíg nem volt aktív a tuning. És ez nagybetűs TÉNY.
Akár tetszik akár nem a tuning az tuning. A garancia a tuningszolgáltatások aktiválásával elveszik, vagyis minden, ami erre vonatkozik nem rendeltetésszerű használat. Természetesen megteheted, hogy úgy használod a hardvert ahogy neked tetszik, de semmi jogod nincs reklamálni, mert elfogadtad azt az EULA-t, amelyben erről a jogodról lemondasz. És ez független az AMD-től. Minden gyártó ezt fogadtatja el veled a tuningra vonatkozó EULA-kban!(#13031) ffodi: Mert a tuning az tuning. Értsétek meg, hogy a gyártók megkülönböztetnek rendeltetésszerű és nem rendeltetésszerű használatot. Előbbi esetben teljes a teszt, de utóbbi esetben nem lehetséges olyan tesztprotokollt készíteni, amely minden eshetőséget lefed. Éppen ezért kerül ez a nem rendeltetésszerű használat csoportjába egy saját felelősségvállalásra vonatkozó EULA mögé.
Attól, hogy valaki nem olvassa el az EULA-t nem jelenti azt, hogy mentesül a feltételei alól.
A termék beüzemelhető a manual nélkül. Bár nagyon ajánlott azt is elolvasni.(#13032) TTomax: Ez nem jó példa, mert ilyen nincs. De olyan egyébként van, hogy a kocsi motorja szoftveresen le van fojtva. Ezt sokszor fel lehet oldani egy szoftveres tuninggal, amit számos műhelyben megcsinálnak, de arra a kocsi gyártója nem vállal majd garanciát. Ez teljesen normális. És igen a szoftveres fojtással is addig van tesztelve a kocsi, ameddig a tartományig a szoftver engedi a motort működni.
Nem értem, hogy miért beszélünk ennyire specifikusan. Az AMD feltételei a tuningra semmiben sem különböznek más cég feltételeitől. Amint aktív bármilyen tuningszoftver a garancia a normális működésre elvész. Ha ezt egy felhasználó nem képes megérteni, akkor minden cég úgy van vele, hogy jobb, ha többet nem vesz tőlük hardvert, mert csak a baj lesz a userrel.
-
Abu85
HÁZIGAZDA
Nem lehet, mert a meghajtó hibátlan volt a tuningmodul nélkül.
A tuningra egyetlen cég sem vállal garanciát. Ez nem az AMD egyedi dolga. Nem tudsz mondani olyan céget, amelyik bármilyen tuningfunkcióra garanciát vállalna.(#13027) TTomax: Nem kell annyin használnod. Számos olyan VGA van, amely másik hűtőt használ. Meg eleve a gyári hűtővel az én VGA-m nem megy 60°C fölé.
Akkor sem fognak a tuningra garanciát vállalni, ha most itt vért izzadva követeled ezt. Nincs olyan cég, amely a tuningfunkciók feloldása előtt ne fogadtatná el veled azt az EULA-t, amely kimondja, hogy tied a felelősség. Ez benne van az Afterburner, a GPU Tweak, a Trixxx, akármilyen más tuningprogram telepítőjében. Természetesen megteheted azt is, hogy nem fogadod el, és a program nem települ.Egészen félelmetes, hogy 2015-ben eljutottunk oda, hogy tuningszoftverre/funkcióra garanciát követel a felhasználó.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
Májkii
#13021
üzenetére
Volt. Természetesen. Ugyanazt a szerződést kellett elfogadni.
(#13022) TTomax: Dehogynem. Bármikor kiveheted a telepítőből a vezérlő telepítését. A meghajtó enélkül is működik. Custom telepítést kell kérni.
Az UELA arra vonatkozik, hogy ha aktiválod a felületet, akkor az AMD felelőssége minden hibára megszűnik. Olvasd el.
Az egyedi ventiprofil is tuning! Pont ugyanúgy a te felelősséged, ahogy az extra órajel. -
Abu85
HÁZIGAZDA
válasz
TTomax
#13017
üzenetére
Az overdrive modul nem a meghajtó része. Le van lakatolva!. Addig nem is érheted el, amíg nem fogadod el, hogy a lakat kioldása után nem vállal felelősséget az AMD semmilyen hibáért. Ha elfogadod, akkor pedig minden a te hibád. Te döntesz. A meghajtó az overdrive modul nélkül hibátlanul is működik.
(#13018) Macka: A tuning üzemképtelensége nem meghajtóhiba! Az sem meghajtóhiba, hogy az erre szolgáló modul hibás. Ez vezérlőhiba, de eleve egy olyan felületen, amelynek a kilakatolásával elfogadtad, hogy a felelősség a tied.
(#13019) gbors: Az, hogy nem teszteli a tuningmodulokat senki? Bocs, hogy felébresztettelek, de a tuning nem része sehol sem a tesztprotokollnak. Ha tetszik, ha nem, ez így van.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
imi123
#13010
üzenetére
A Mantle esetében azért jó 3000 sort kellett beírni. Plusz nem kevés shadert átírni. Illetve, ha a motorok nem voltak felkészítve strukturálisan erre, akkor azokat is át kellett írni. Utóbbi volt igazán időigényes. A jó hír igazából, hogy rengeteg stúdió írt Mantle leképezőt, csak azért, hogy a motorokat felkészítsék a DX12-re is. A Mantle ugyanis ugyanazokat az igényeket támassza egy motor felé, mint a DX12 és a Vulkan. Ha ezt megcsinálták, akkor másik back-endet lehet írni két hét alatt is. Szerencsére mindhárom PC-s low-level API annyira hasonló (kvázi ugyanaz az AMD-s forrás az alap), hogy nem szükséges választani közöttük. Elég könnyen megoldható mindhárom támogatása nagyrészt közös kódból. A legtöbb multiplatform fejlesztés erre megy rá.
A Microsoft ennél annyival ment tovább, hogy az Xbox One-ra szállítják ugyanazt az OS-t és ugyanazt az API-t, amit PC-re. Persze szállítanak egy még alacsonyabb szintű mono elérést, de ez most mindegy. Tehát ha a DX12-es elérést használja egy program Xbox One-on, akkor úgy is meg lehet oldani a portot, hogy az erőforrás-kreáláshoz szükséges ellenőrzéseket beírják az elejére és kész. Vagy, ha nagyon előre gondolkodtak, akkor ez már az Xbox One kódban is benne van. Ilyenkor tényleg copy-paste az egész.
Egyébként apró műhelytitok, hogy a Sony ugyanezt fogja csinálni a Vulkan API-val. Azt is támogatni fogják a libGNM és a libGNMX mellett. A Nintendo meg eleve a Vulkan API-t használja az NX-hez. -
Abu85
HÁZIGAZDA
válasz
imi123
#13007
üzenetére
Pedig ez az alapvető cél a Microsoft nézőpontjából. Ha megvan az Xbox One kód DX12-re, akkor az elejére kell írni pár sort és mehet PC-re. Persze nem biztos, hogy ez minden esetben jó ötlet, de garantáltan futni fog a program. Ahhoz, hogy ezt nyomatékosítsák demonstrálni kell pár programmal. A Fable Legends, az új Tomb Raider és a Gears of War felújítás lett kiválasztva első körben. A Fable Legends pre-alpha alapján ebből nem lesz gond. Persze ez azért nagyrészt annak is köszönhető, hogy a Microsoftnál értenek is hozzá, így eleve jó minőségű a kód. Az inkább kérdés, hogy más képes-e ilyen jó minőségű multiplatform kódot csinálni. Az Unreal Engine 4 D3D12 experimental build alapján az Epic nem volt képes erre és ez már aggodalomra ad okot.
(#13008) gbors: A drivernek csak az overdrive moduljában volt a hiba, amit eleve nem kell engedélyezni a működéshez, vagy ha engedélyezed, akkor el kell fogadni, hogy innentől minden a te felelősséged. A driver hibátlanul üzemelt, ha a tuningmodul nem volt aktív! Az overdrive modult elrontották ez tény, de ezt csak azokat érintette akik tuningolnak. Tehát rendeltetésszerű környezetben a meghajtó működött. Arra is mérget vehet bárki, hogy a tuningot a jövőben sem fogja senki ellenőrizni.
-
Abu85
HÁZIGAZDA
válasz
imi123
#13005
üzenetére
Tekintve, hogy az Xbox One-on nem létezik DX11-es API, csak DX12-es, így ha tényleg copy-paste lesz, akkor DX12 kell majd hozzá. A DX11-hez írni kell egy másik leképezőt, amire nem biztos, hogy erőforrást pazarol a Microsoft. Ezt szerintem nem véletlenül csinálja a Microsoft. Szimplán demonstrálni akarják a DX12 előnyét, hogy az Xbox One kód pillanatok alatt átültethető PC-re. Az új TR lesz a kísérleti nyúl.
-
Abu85
HÁZIGAZDA
Mi a baj vele? Már azelőtt felraktam, hogy megjelent és azóta működik, persze egy hete lefrissítettem az új verzióra.
A ventivezérlés is működik. Tuningnál nem működött, de azt senki sem ellenőrzi soha és sosem fogja, mert benne van az EULA-ban, hogy elfogadod a hiba lehetőségét.(#12998) Szaby59: Az új Tomb Raider PC-s kiadója a Microsoft lesz több régióban is és ők eleve nem érdekeltek a bundle-ökben. Nem is nagyon van lehetőség ilyenre a Windows Store-on belül.
Az AMD-nek egyébként biztos nincs sok köze a Rise of the Tomb Raiderhez a technikai segítség szintjén, mert nem a Nixxes portolja, hanem egyszerűen az Xbox One kódot adják ki PC-re tulajdonképpen copy-paste szinten.
A Nixxes az új Hitman és új Deus Ex játékokon dolgozik az AMD-vel. Azok nem csak szimpla Xbox One másolatok lesznek. -
Abu85
HÁZIGAZDA
Olyan a valóságban nem létezik. Minden API-nak van egy conformance tesztje, ahol az API tulajdonosa hitelesíti az összes meghajtót. Ha ott átmegy, akkor a meghajtó megfelel a specifikációknak. Viszont ma az a probléma, hogy ezek az API-k, ideértve a DX11-et és kiemelve az OpenGL-t. Az egyes problémákra számos megoldást kínálnak. Például az adatfeltöltésre az OpenGL-ben legalább másfél tucat alternatív megoldás van, és kis túlzással mindegyik hardvernek csak egy-kettő fekszik, vagyis ideálisan az lenne a jó, ha a program mindegyik lehetőségre tartalmazna egy implementációt. A DX11-ben is igaz ez csak ott azért a Microsoftnak volt annyi esze, hogy ne fogadja el ész nélkül minden újítást. A DX12 és a Vulkan egyik kritikus fícsőrje, hogy minden problémára csak egy gyors megoldás van, vagyis a fejlesztőknek elég arra építeni egy programot és az garantáltan gyors lesz minden hardveren. Nem biztos, hogy a leggyorsabb út lesz xy gyártónál, de elég gyors, ahhoz, hogy ez ne legyen gond. Ez egy nagyon kritikus pont. Nyilván ennek a hátránya, hogy akkora változást jelent a korábbi API-khoz képest, hogy a visszafelé kompatibilitás megszűnt, de ez más szempontból is így van. Nagyjából elérkezett az az idő, amikor megéri egy tiszta lapot indítani. A másik fontos dolog, hogy a gyártók ezeket az API-kat persze kiegészíthetik a saját eljárásaikkal, ami megint ugyanoda vezetne, ahol most tart a DX11 és az OpenGL. Erre viszont megoldás a validátor. Ez meg fogja akadályozni azt, hogy a gyártók ezt a csomagot is szétbarmolják a különböző kiterjesztésekkel, mert a kiterjesztéseket nem lehet majd validálni. Ettől persze a program szállítható lesz, csak a gyártók kétszer is meggondolják majd, hogy lecserélik-e a szabványos eljárásokat egy kiterjesztésben, mert validáció nélkül a következő generációs hardveren az a kód jó eséllyel nem fog elindulni. Kvázi bele lett kényszerítve mindenki a szabványos, specifikált, validálható eljárások használatába, ha azt akarják, hogy a játékok ne csak egy évig fussanak. Olyan kiterjesztés tehát nem fog érkezni a DX12 és a Vulkan API-hoz, amely például alternatív adatfeltöltésre vonatkozó specifikációt kínál.
-
Abu85
HÁZIGAZDA
Az egyébként a probléma jóval mélyebb. Az NV a GameWorksöt azért kezdte el, mert az AMD puccsolja a szabványalkotást. Ez is nagyon csúnya dolog. Az NV éveket és dollár százmillókat ölt abba, hogy elérjék az aktuális API-k eljárásainak folyamatos kiegészítését. Viszont sosem gondolták azt, hogy bárki, a kompatibilitást felrúgva hozzon egy új irányt. Az AMD azonban hozott, és erre épül a DX12/Vulkan. Az AMD megmondhatja a tutit a GAB/ARB-s vétójoggal. Hiába fog ordítani az Intel/NVIDIA/akárki, hogy a hardvereiknek az API tervezete rossz, vagy megszavazzák, vagy az AMD leszavazza az alternatív javaslatokat.
Látszik is a hatás. Az NV elment a Maxwellel egy irányba, amiből a Pascal visszatér a fermis alapokhoz. Nem azért, mert ez a jó, hanem, mert az AMD vétójoga kikényszerítette. -
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12947
üzenetére
Az NV-nek nem kell ebbe beszállnia. A fejlesztők az NV segítsége nélkül is elmondhatják a tapasztalataikat. Továbbra sem fogják tudni, hogy NV-n mennyi az egyes RT formátumok exportjának ciklusigénye, vagy mennyi a mintavételi sebesség az egyes textúraformátumoknál az egyes szűrésekhez, stb. Ugyanakkor azt leírhatják, hogy kinek melyik formátum vált be, és ilyen formában ez már egy kiindulási alap más számára. Ezek újra optimalizálást hozhatnak a PC-nek. Erre viszonylag nagy igény van, mert az NV nem mondja meg, hogyan lehet optimalizált kódot írni a GeForce-okra, ami nem fog megváltozni, de a fejlesztők rengeteg tapasztalatot megoszthatnak, így nem is szükséges az NV-vel kapcsolatot teremteni a fejlesztéshez.
-
Abu85
HÁZIGAZDA
válasz
jacint78
#12948
üzenetére
Nem azért teszik, hogy a konkurencia kezére adják. Az a cél, hogy optimalizált játékok szülessenek. Az elmúlt évben a hibás optimalizálásokért az felelt, hogy a GameWorks miatt egy rakás leképezőre vonatkozó optimalizálást PC-be nem lehetett szállítani. A játékosok pedig szívtak a veszettül növekedő gépigénnyel. A nyílt forráskód az egyetlen megoldás erre a problémára, mert ha az effekt ne adj isten nem kompatibilis a leképezővel, akkor az effekten könnyen lehet módosítani. A zárt forráskód azonban ezt lehetetlenné teszi, így a leképezőt kell hackelni, amitől a PC-s portok sokszor rosszak lesznek. A cél tehát a PC-s optimalizálás.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#12946
üzenetére
A Radeon SDK régebbi, mint a GameWorks. A GPUOpen sem más, csak megváltozott a licenc, így mostantól, ha az AMD-től visz valaki egy effektet, akkor arról nem kell az AMD-nek szólnia, illetve a módosításokat közzéteheti a GPUOpen portálon.
A fejlesztők régóta segítik egymást azzal, hogy bizonyos dolgokat a különböző rendezvényeken megosztanak. A GPUOpen célja, hogy ezt magasabb szintre vigyék.
A régi Radeon SDK-val az is gond volt, hogy a létező kutatások mikor kerültek visszaírásra. Például az Intel az optimalizációkat mindig gyorsan elkészítette, de volt olyan, hogy az csak egy év múlva került bele a Radeon SDK-ba. A GPUOpennel az Intel az optimalizálásait rögtön publikálhatja. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12919
üzenetére
Kétféle képi hibáról írnak az AMD fórumán. Az egyik az Eyefinity esetében fellépő probléma, de ott már leírták többször is, hogy két külön interfészt nehéz szinkronizálni belsőleg. Ahhoz, hogy a szinkron Eyefinity mellett is teljes legyen HUB-ot kell vásárolni. Ez szinkronizálja a három kimeneti képet.
A másik képi hiba amiről szokott szó lenni az a Fury-vel kapcsolatos, de ezt még nem sikerült reprodukálnia senkinek. Egyelőre úgy néz ki, hogy ez nem driverhiba, hanem kompatibilitási és csak bizonyos alaplapokban jön elő. Ahhoz, hogy ezt javítsák kell egy olyan teljes konfig, amin előjön. Aztán az alaplapgyártónak majd ki kell adnia rá egy új BIOS-t, vagy ha ez nem megoldható, akkor kell valami hack rá.
-
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12908
üzenetére
A WHQL-re eleve hibátlan olyan meghajtókat küldenek, ami biztosan átmegy. Csupán azért, mert ha kifizeted az tesztet, de nem kapod meg az aláírást, akkor az kidobott pénz.
Amit ti vártok, az az hogy tuningra is teszteljenek. Na most ezt se a WHQL, sem a gyártói tesztcsomag nem fogja megtenni. Erre hiába is vártok. -
Abu85
HÁZIGAZDA
Teszteletlen verziót senki sem ad WHQL-re. Az túl nagy kockázat lenne, mert az MS nem ad vissza pénzt. De a gyártók tesztcsomagjának csak egy részét képzik csak a WHQL tesztek. Maga a WHQL nem egy zárt dolog. Teljesen specifikálva van az egész, így a gyártók a laborjakon belül is ellenőrizhetik, hogy a meghajtó átmenne-e vagy sem. Ha átmenne elküldik és az MS aláírja.
Sosem megy el olyan driver, amely legalább a WHQL tesztcsokron ne lett volna tesztelve, viszont a teljes tesztsor nem biztos, hogy lemegy a WHQL drivereken. Túl sokáig tartana. Persze vannak meghajtók, amelyeket lehúzzák a teljes tesztsort, mint például az új Crimson.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12900
üzenetére
Minden gyártó azt ajánlja, hogy a hivatalos oldalon fellelhető drivereket telepítsétek. Amelyiket akarjátok.
(#12901) schawo: Ez nem ostobaság. A WHQL elvesztette a lényegét. A Microsoft nem kívánja megreformálni. A tesztek közül sok régen kötelező volt, ma pedig már meg is lehet bukni rajtuk. Ilyen formában az egész egy időbeli probléma. Letesztelik a WHQL tesztcsomagra, mert az MS nem ad vissza pénzt, de ennél több nem biztos, hogy megéri, mert a gyártói aláírás több időbe kerülne és a WHQL is később jönne. A béta esetében ez az időbeli probléma nem áll fent. Nem kell megvárni még a WHQL aláírást is.
Tuningot senki sem tesztel. Se a Microsoft, se a gyártók. Tehát tuning mellett bármilyen bug lehet. Erre a WHQL nem garancia. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12895
üzenetére
Igen a WHQL-re is ugyanolyan béták mennek. Attól lesz WHQL, hogy az MS aláírja.
A teljes teszt ezeken a drivereken elég komplex. Egy gyártói aláírás a saját tesztekkel simán elvisz két hetet. Ha lesz WHQL is az megint két hét. Négy hét nagyon sok idő, így jellemző, hogy a WHQL-re küldött meghajtókon csak a WHQL tesztcsomagot futtatják le a gyártók is, és a többi tesztet hagyják, amelyeket az MS úgy sem néz, ezzel nyernek egy hetet időben. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12893
üzenetére
A WHQL-en sajnos nem biztos, hogy mindent lefuttatnak a gyártók. Csak azt, amit az MS kér. Ezt azért teszik, mert egy aláírás így is benne lesz három hétben.
Valójában a driver az eléggé speciális terület. Egyrészt egy meghajtó sosem lesz kész. Másrészt sosem lesz hibátlan. Viszont, ha azt nézzük, hogy melyik megy át több teszten, akkor a béták a WHQL előtt vannak.
-
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12826
üzenetére
Az egész DX11-es működési modellnek nincs semmi értelme. Ezt már a Microsoft is elmondta az idei GDC-n. Lassan egy évtizede rossz irányba fejlesztettek, mert azt hitték, hogy ezzel jót csinálnak. Nem baj egyébként, mert nyilván nem szándékosan vágták maguk alatt a fát, de ha megnézzük a mi történt a régi DX-ekben, akkor az állapotblokkok, a nagy állapotcsoportok és végül a deferred context is totális bukás. Az első kettő alig ér valamit, míg a harmadik opció implementálása olyan drága, hogy másfél évig kell kódolni a működését. Nagyon sok motor elindult a deferred context felé. Még a Frostbite is, csak fél év után ráhagyták, mert nem éri meg. Most képzeld, ha egy EA azt mondta, hogy nem finanszírozza tovább, akkor egy kisebb kiadó mit mond...
-
#12829
Abu85
HÁZIGAZDA
Petykemano
#12825
Abu85
HÁZIGAZDA
válasz
Petykemano
#12825
üzenetére
Igazából a Microsoft ajánlásait csak az Intel követi. Az NV nagyon nem, míg az AMD a kettő közötti vonalat akarja megtalálni. Mivel nem a gyártóknál van a hiba, hanem az API-ban, így egyik sem jó megoldás. Az Intelé és lényegében a Microsofté azért nem, mert bár sok szabad processzor erőforrást hagy a programnak, a többi driver miatt ezekhez a fejlesztők nem nyúlnak. Az AMD megoldása azért nem jó, mert az ideálisnak vélt balanszra való törekvéssel az Intel és az NV iránya közé esik, és ez igazából a kétmagos HT-s gépeken ideális. Az NV megoldása pedig azért rossz, mert nem veszi figyelembe a kétmagos procikat és a kétmagos gépeken csökkent a minimum fps-en.
A megoldás erre az, amit az MS javasolt. Aki skálázódást akar menjen DX12-re. Ott nincs kernel driver, ami elvegye az erőforrást. -
#12824
Abu85
HÁZIGAZDA
Petykemano
#12823
Abu85
HÁZIGAZDA
válasz
Petykemano
#12823
üzenetére
Nem. Semmi köze az emulációhoz. Ahhoz van köze, hogy mennyi processzoridőtől érdemes megfosztani a programot. Le lehet programozni, hogy a driver elvegye az erőforrások többségét csak nem érdemes. Eleve azért nem, mert az MS arra kérte a fejlesztőket, hogy többet ne használják a deferred contextet. Azért hozták a DX12-t, hogy az elhibázott irányt kiváltsák vele.
-
#12821
Abu85
HÁZIGAZDA
huskydog17
#12820
Abu85
HÁZIGAZDA
válasz
huskydog17
#12820
üzenetére
Akkor az valami bug lesz. Nem így kellene működnie.
Ja igen, akkor már megjelent. Az első EGO sem sikerült jól a DiRT első részében. Ez ilyen tanulópénz szintű dolog. A nagy változások nagy kockázattal járnak. Majd lesz fejlesztett verzió jövőre.
Az EGO 3 stabilabb volt. A DiRT Rallyhoz jobban illett.
-
-
#12815
Abu85
HÁZIGAZDA
huskydog17
#12813
Abu85
HÁZIGAZDA
válasz
huskydog17
#12813
üzenetére
A legfontosabb kimaradt: GPU Particles
Az Advanced Blending az Intel effektje. Lehetővé teszi a korrekt megjelenítést az átlátszó felületekhez.
A program sokat változott, így meg kell várni az új drivereket, mert a mostaniakkal vannak benne hibák.
-
Abu85
HÁZIGAZDA
Csinálok egyébként egy DX12-es/WDDM-es/DXKG-s táblázatot a hardverekről, hogy mit támogatnak és mit nem. Ezt eredetileg angolra csináltam, de majd lemagyarítom. Addig is itt van belőle egy béta verzió:
Ez még nem végleges, le kell csekkelnem, hogy minden jó-e rajta. Karácsony előtt befejezem.
-
#12808
Abu85
HÁZIGAZDA
Petykemano
#12807
Abu85
HÁZIGAZDA
válasz
Petykemano
#12807
üzenetére
Ha nincs spanja, hogy lezsírozzon neki egy cserét, akkor el kell adnia a 960-at. Azt pedig nem tudja olyan drágán eladni, hogy megérje.
-
Abu85
HÁZIGAZDA
válasz
arcsi84
#12805
üzenetére
Most már semmit. Sokat buksz ha eladod.
A 970-en 4 GB van, csak fél GB-ot nem lehet elérni a teljes sávszélességgel. De ez is Maxwell v2, mint a 960.
A 390-nek tuti elég egy 500 wattos FSP. Az elég jó táp. Igen ez csak a GCN2. Ennek az a hátránya, hogy nem támogatja az FP16-ot. De ettől futni fognak a programok, csak GCN3-on bizonyos puffereket kétszer gyorsabban és feleannyi sávszéllel is ki lehet majd számolni.
A 380/380X egyértelműen jó választás a GCN3 miatt. De a legjobb a 285, mert az már olcsó a neve miatt és ugyanaz.
A 960 4 GB biztosan nem éri meg a felárért.
A PBR az egy új lehetőség a fejlesztőknek. Mennek előre. Normálisan megcsinálni nagyon nem egyszerű, így csak a top cuccok használják tényleg erőteljesen. Frostbite, CryEngine, Dawn Engine.
-
Abu85
HÁZIGAZDA
válasz
arcsi84
#12802
üzenetére
Itt az is nagyon fontos kérdés, hogy kit tekintünk játékfejlesztőnek. Aki szarik bele és áthozza az Xbox One kódot módosítás nélkül, vagy aki tényleg portolni fog.
Egyébként a DX12-nek nem lesz köze a sávszélhiányhoz. Sokkal inkább a PBR terjedésének. PBR-es motor például az új Frostbite. [link]
A DX12 maximum olyan dolgokat hoz csak be, mint az aszinkron compute, ami egy nagyon elterjedt funkció lesz a motorokban, hiszen kvázi ingyen lehet compute-ot futtatni. Ez nem jelenti azt, hogy a Maxwellel nem törődnek, csak az ingyen effekt az ingyen effekt.
Ha a Maxwell nagyon fontos megírják CUDA-ban is a kódot HyperQ-ra. -
Abu85
HÁZIGAZDA
válasz
#85552128
#12766
üzenetére
Az nem nagy üzlet, mert a HBM1 fenntartása nekik nagyon hátrányos. Nekik az volna a jó, ha mindenki HBM2-t rendelne. De ha nem sikerül implementálni, akkor meg rendelés sem lesz. És ez nem csak a Hynix problémája, hanem azé a vállalaté is, aki nem tudja implementálni. Ezért jobb a Hynix ajánlásait követni.
Csak két GPU-gyártó létezik, és az AMD a HBM1 után biztosan HBM2-re lép tovább. Az NV pedig a két új Teslához HBM2-t használ.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#12764
üzenetére
A HBM1-et használják majd mások. A Hynix továbbra is kiáll amellett, hogy nulláról senki se lépjen HBM2-re, így előbb a HBM1-re építsen. Túl nagy a kockázata, hogy a HBM2-es terméket törölni kell, ha nincs tapasztalat a HBM1-ről. Több FPGA dizájn használ majd HBM1-et.
-
Abu85
HÁZIGAZDA
Az 512 GB/s az 384 bitről van. Az 512 bit GDDR5X-szel nem ajánlott, mert vállalhatatlanul bonyolult. A 384 bithez is a maiaknál sokkal komplexebb routing kell és jobb PCB. Bár a Micron szerint 512 bit lehetséges, de nem látnak rá esélyt, hogy bárki bevállalja. Ahhoz aztán nagyon tök kell.
A GDDR5X célja egyébként egyértelműen nem a fogyasztás javítása volt. Ebből a szempontból a GDDR5 is jobb opció.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
A látvány terén is egyértelmű a különbség.
A Ryse nyilván teljesítményigényes program, de még így is jobban van optimalizálva, mint a többség.
Mindegy, hogy van-e PC-n az Order attól a leképező etalon.(#12715) huskydog17: De az említett stúdiók technikailag már teljesen lemaradtak. Nem baj egyébként, mert függetlenek, tehát nincs mögöttük egy EA, aki kinyitja a pénzcsapot bármilyen kérésre, de az biztos, hogy a függetlenként még technikailag magát úgy ahogy tartó Rebellion is kezd lemaradni. Egyszerűen ők is érzik, hogy nem lehet ugyanazt hozni, mint amit tud a Frostbite, ha az R&D tizedannyi vagy még kevesebb.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12709
üzenetére
Elsődlegesen azért olyan szép az Order, mert tényleg új generációs post-process pipeline-t alkalmaz. Abszolút nem erős az elmosása. Láttam sokkal rosszabbat is a TXAA-val, de az nem használ oversharp filtert.
PC-be azért kellenének ezek, mert az Order 1886 megoldott egy csomó aktuális grafikai problémát, mint például a specular aliassing, amire PC-n nincs megoldás még, de nyilván ahogy dolgozzák ki az új post-process pipeline-okat úgy fogjuk kivezetni az előző évtizedből beragadt technikákat. Ez inkább kutatás és idő kérdése, vagyis nem technológiai probléma. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#12703
üzenetére
Az nincs elmosva, csak borzalmasan komplex post-process pipeline-ja van, ami nem csak az adott képkockára számol, hanem temporálisan is vannak adatai. Az egész rendszer 12 analitikai élsimítási pipeline-ból áll össze, amelyek specifikusan reagálnak a problémákra. Hasonló rendszereket fogunk látni majd a PC-n is, ha végre eljutunk oda, hogy a mostani, lényegében előző évtizedből származó post-process pipeline-okat kidobjuk.
(#12702) imi123: Szerintem érdemes jobban megnézned. A Witcher 3-nál már az előző Frostbite is jobb volt Dragon Age-ben, az új pedig összehasonlíthatatlanul jobb.
-
Abu85
HÁZIGAZDA
válasz
imi123
#12700
üzenetére
Nekem mindegy, hogy mi számít nektek. Alapvetően már a futottak még kategória is szép. De az kétségtelen, hogy a Star Wars Battlefront, a Ryse vagy az Order 1886 grafikájával nem vetekszik semmi. Azt nem mondom, hogy ezek legyenek a normák, mert a legtöbb fejlesztőnek nincs arra pénze, hogy ilyen minőségű leképezőket fejlesszen. Ettől vannak a futottak még kategóriában.
Az említett három játék az előnyeit nem a rajzolásokkal szerezi, hanem a PBR megvalósításával. Ebben sokkal jobbak mindennél. Az Order még olyan gondokat is kezel, mint a specular aliassing, ami már régóta bassza a csőröm, és folyamatosan mondogatom az AMD/Intel/NV-nek, hogy kezdjenek már vele valamit. -
Abu85
HÁZIGAZDA
Pedig a PBR eléggé sávszélgyilkos. Jóval több bitnyi információ szükséges pixelenként.
Project Cars leképezője abszolút nem modern. A Witcher 3-ba pedig az eredetileg tervezett E3-on bemutatott leképező nem került bele. Ezek a játékok a renderer tekintetében messze elmaradnak attól, amire a Frostbite és a CryEngine képes. Még attól is elmaradnak, amit a leváltott Frostbite 3 tudott, pedig az már öregnek tekinthető.
Az a baj, hogy nagyon sokan vannak már a futottak még kategóriában, tehát nagy átlagban nem tűnik fel, hogy ezek mennyivel rosszabbak, mint amit el lehet érni, csak akkor, ha előveszünk olyan címeket, mint a Star Wars Battlefront, a Ryse vagy az Order 1886. -
Abu85
HÁZIGAZDA
A szávszélre vonatkozó takarékosság ma inkább pénzhiány, vagy mobil fókusz eredménye. Az idei évben nyilvánvalóvá vált, hogy csak pár tradicionálisan PC-s motor fejlődik igazán: a Frostbite, a Nitrous, a LORE és a CryEngine. A többiek vagy nem értékelik az asztali PC-t annyira, hogy pénz rakjanak bele, vagy szűkös költségvetésük van erre.
A piac láthatóan kettészakad. Lesz egy nagyon nagy, elsődlegesen mobil fókuszt előtérbe helyező csoport, és marad pár olyan stúdió, akik szerint az asztali PC még mindig megéri a befektetést. A két opció között viszont nagyon kinyílik az olló. Azt ne tekintsük optimalizálásnak, amikor szimplán pénz hiányában nincs lehetőség olyan szintű PBR-t használni, mint amilyet az új Frostbite használ például. -
Abu85
HÁZIGAZDA
válasz
#85552128
#12646
üzenetére
AAA nem biztos. Nagyon sokan csak úgy építenek low-level támogatást a játékba, hogy lefrissítik az új motorverziót. Az új Unity-ben és UE-ben a DX12 csak egy checkbox. A fejlesztőnek be kell pipálnia és köpi a kódot az SDK. Így készült el a Caffeine is. Bárki aki UE4-re épít, az innentől leszedheti az UE 4.9 DX12-es verzióját. Pipa be a DX12 elé és DX12-es a program. Eddig tart a portolás.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#12640
üzenetére
A userek a következő év első felében fognak ebből tömeges szinten profitálni. Ma csak pár DX12-es program van. De egyébként a shaderekkel mindenki küzdeni fog. Bár talán nem annyit, mint a Frostbite, mert nekik eleve az a problémájuk, hogy minden shaderük olyan nyelvben van, amit csak a Mantle fogad el. A többiek szerintem eleve szabványos nyelvre írják át a shadereiket. OpenCL C++ elég jó opció.
A Frostbite Team már ezzel nem akar foglalkozni. Marad ez a nyelv, és onnan fordítgatnak. -
Abu85
HÁZIGAZDA
válasz
nonsen5e
#12638
üzenetére
Az új Frostbite már van az NFS-ben és az SW Battlefrontban. A low-level patch attól függ, hogy mi lesz a megoldás a shaderekre, mert azokat szerintem hét szentség, hogy nem írják újra. Szerintem nekik a Vulkan a legjobb opció, mert írhatnak egy olyan fordítót, ami a meglévő HLSL ext. shadereket lefordítja SPIR-V-re. Azért gondolom nekik sem mindegy, hogy cirka 30-40 ezer kódsort újra kell írni, vagy csak fordítót használnak. És akkor innen maradhat az a fejlesztés, amit használnak. PSSL kódok, abból HLSL ext. konverzió, és ebből megvan az Xbox One és a PC port. PC-n SPIR-V-vel.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#12636
üzenetére
Olyan nincs, hogy komolyabban kihasználja, vagy kevésbé. Maga a DX12 és a Vulkan annyira különbözik a DX11-től, hogy teljesen új motorstruktúrát követel meg. A DX11-hez optimalizált struktúrával nem működik. És ez látszik az UE4-en, illetve a Unity 5-ön. Hiába van bennük a DX12 még sok helyen nem gyorsabb, mint a DX11, mert nem alakították át a működési struktúrát.
Ahol először működni fog az a Frostbite új verziója, mert ott már kész a motor struktúrája a low-levelhez. Viszont ott az a gond, hogy egy rakás kódjuk van a fejlesztőknek HLSL ext. nyelven. Ezt a nyelvet sem a DX12, sem pedig a Vulkan nem támogatja direkten. Szóval át kell konvertálni HSLS 5.1-be, vagy írni kell egy SPIR-V-re dolgozó fordítót hozzá.
-
Abu85
HÁZIGAZDA
Az AFR DX11-ben nagyon nehéznek tűnik a Just Cause 3-ban. A Waveworksnek van normál és temporális variánsa. A normál drágább, de működik vele az AFR, míg a temporális verzió gyorsabban dolgozik, viszont nem implementálható vele az SLI és a CF. Valószínűleg a temporális verziót választották, ezért nincs AFR. Ha meg a normál verzió fut, akkor lehet AFR.
-
Abu85
HÁZIGAZDA
Abban volt szó dollármilliókról?
Mi a szép? Az biztos, hogy a Thief fény-árnyék hatásokban verhetetlen jelenleg. De más stílus. A hangulaton nem tudom mit értesz, de ha az élményt, akkor technikai dolgokba szerintem ezt ne keverjük bele.
A Witcher 3 lehetett volna szebb is, ha berakták volna a tervezett effekteket. Ez szintén egy middleware probléma sajnos. Dying Light nem kimondottan szép. Elég rossz a LOD-kezelése, így távolra elnézve kifejezetten ronda lesz.Figyelj, erre azt tudom írni, hogy hozzanak bizonyítékot arra, hogy a GameWorks jól működik. Mind sebességben, mind minőségben. Amíg ez nincs, addig természetes, hogy kapni fogja a sarat. És természetes, hogy a PC-s játékosok itt a leghangosabbak, mert ők kerültek a fallosz rosszabbik végéhez.
-
#12483
Abu85
HÁZIGAZDA
huskydog17
#12482
Abu85
HÁZIGAZDA
válasz
huskydog17
#12482
üzenetére
Ezt félreérted. A Speedtree csak akkor middleware, ha úgy építed be. Van erre is licenc, de nagyon sokan nem így építik be. Egyszerűen csak fogják a forrást kiszedik, ami kell és azt beleírják a motorba, mintha őt írták volna az egészet. Ilyen formában ez közelében sincs a middleware implementációkhoz. Így már nem middleware-ként működik a Speedtree, hanem egy teljesen beépített rendszerként. Ennek nyilván az előnye, hogy rendkívül gyors. A hátránya viszont, hogy ha jön egy új Speedtree verzió, akkor a csere nem annyi, hogy betöltöd az új middleware-t, hanem konkrétan megint elölről kell kezdeni mindent. Ezért is adják a cégek drágán az efféle licenceket, mert aki egyszer egy verziót kért, az már nem kér újat soha. Tehát másképp kell fizetniük a technikáért.
Természetesen van olcsó licenc, de ott ne is álmodj róla, hogy be tudod majd integrálni a motorba. Viszont könnyen fejleszthető. -
#12481
Abu85
HÁZIGAZDA
huskydog17
#12480
Abu85
HÁZIGAZDA
válasz
huskydog17
#12480
üzenetére
De a Speedtree esetében a licenc nagyon rugalmas. A legtöbb nagy kiadó azt választja, hogy megveszi magának valamelyik verziót és onnantól kezdve szabadon fejleszthetik házon belül. Ez persze marha drága, viszont ilyen formában a Speedtree esetében tulajdonképpen kutatást veszel és nem konkrét implementációt, mert azt a kutatásra építve írod be a motorba. Vagyis ilyenkor a motorba másképp van implementálva a Speedtree. Kvázi nem middleware-ként, hanem a motor részeként. Ez sokkal inkább hasonlít ahhoz a modellhez, amit például régen követtek a GPU-gyártók az effektfejlesztéshez. Megcsinálták a kutatást, csináltak rá egy példaimplementációt, de a végén úgyis át írták a kódot a fejlesztő.
Ugyanilyen licence egyébként van a Havoknak is. Marha drága, de ezért működik bizonyos játékokban piszok jól. Ki van vágva a forrásból ami kell, és marhára mélyre be van integrálva a motorba.
-
Abu85
HÁZIGAZDA
válasz
imi123
#12475
üzenetére
Ez nem vicc egyébként. Ha a PC-s port minőségi, akkor az AMD sokat fizet. Ott van most a Star Wars Battlefront. Az több millió dolláros üzlet. Persze annak nem csak a kulcsok a részei, hanem az exkluzív reklám.
Sajnos az is előfordulhat, de az is fejlesztői hanyagság kategóriába sorolható. Méghozzá abba, hogy áthozták a DX12-es Xbox One kódot PC-re mindenféle reális optimalizálás nélkül. Ez egyértelműen legalább annyira rossz, mint ha middleware-eket használnának, mert egy Xbox One-hoz tervezett memória menedzsment, csak a GCN2-n fog jól működni. Abból még a GCN1 és a GCN3 is hátrányt szenved. Azt meg kell érteniük a fejlesztőknek, hogy a DX12-ben nincs kernel driver, ami helyettük optimalizálja a memória és az erőforrás menedzsmentet. Itt le kell ülni, és a motorba le kell kódolni egy általánosan jól működő modellt.
-
Abu85
HÁZIGAZDA
Ki mondta, hogy annyit perkálnak le érte? A millió dollárok csak akkor jönnek elő, ha kódokat vásárolnak. Ha megüti a játék azt a mércét, amiért megéri venni pár százezer kódot.
Én nem láttam még idén a Thiefnél jobban optimalizált játékot (60-70%-ra terheli a GPU-kat, egy mai év végi játék a 20-30%-ot sem éri el), vagy olyat, ami olyan skálázást csinál, mint a Dirt Rally. [link] - nem beszélve arról, hogy sosem láttam még olyan játékot, ami ennyire nem küzd a részecskeszimuláció szintjén a többletrajzolás problémájával. Egyszerűen nagyon konstans a sebesség, akármilyen közeli a kamera, és akármennyi a részecske.
Mondj egy olyan GameWorksös címet, amelyben a GameWorksnek nincs valami problémája a sebesség vagy minőség tekintetében. Nem véletlenül alakult ki a világon a Shitworksözés, vagy a Game(Don't)Worksözés. Szerinted van olyan fejlesztő a világon, aki bármit is tud tenni azzal, hogy az által kapott lényegében dll-ben szállított zárt kód nem működik jól? Nem ez a probléma gyökere, hanem az, hogy akármilyen minőséget elfogad az NV és fizet érte, de a GameWorks a probléma része, mivel hogyan várhatnák el azt, hogy a program optimalizált legyen, ha nem biztosítják a forráskódot a fejlesztőnek, hogy optimalizálja.
Nézd meg mi történik a világban. Kétféle általános fejlesztői nézőpont van most. Menjünk a middleware-ek felé (és nem csak a GameWorks, hanem mindenféle middleware felé), mert az olcsó és ennyi. Ilyet alkalmaz az Ubisoft, az Epic, a Rocksteady/Warner, stb. Az eredmény AC Unity, AC Syndicate, UE4 PC-s leképző, Batman AK. A másik opció az oké, hogy a middleware olcsó, de lassú és bugos, illetve esetenként zárt is tehát javítani sem lehet. Az efféle távolodjunk a middleware-ektől irányba megy az EA, a Square Enix EIDOS csoportja, a Crytek, stb. Az eredmény Star Wars Battlefront, Thief, Ryse. Az egészen egyértelmű, hogy melyik működik, mint ahogy az is egészen egyértelmű, hogy melyik irány oldható meg olcsóbban, sokkal olcsóbban. Létjogosultsága mindkettőnek van, ez vitathatatlan, mert bizonyos kiadók nem engednek a minőségből, míg bizonyos kiadók egyszerűen nem rendelkeznek akkora tőkével, hogy a PC-vel szimplán csak minimálisan is törődjenek. Ugyanakkor a PC-s játékosok szemszögéből a middleware-ek csak rossz portokat fognak jelenteni. Pusztán azért, mert meg kell küzdeni a bugjaival, a nehézkes integrálásával, és rosszabb esetben azzal, hogy szimplán a zárt kód miatt implementálni sem lehet megfelelően, mert nem tudod módosítani, hogy a leképezőhöz igazítsd. Egy működő leképezőt pedig szimplán egy middleware effekt beépítéséért nem fognak átírni. Ilyenkor jön a "Nézd a downgrade-et az E3-hoz képest!", lásd Witcher 3. Szemét fejlesztők nem ezt ígérték. Hát persze, de mit csináljanak? XY effektért készítsenek alternatív leképezőt, csak azért, mert az effekt nem igazítható hozzá a stabil és kész leképezőhöz? Inkább búcsút intenek az effektnek.
Nem olyan vagy mindent vagy semmit elvű a multi-engine koncepció, mint a DX12-nél. Vulkan alatt a Maxwell és a Kepler is aránylag normálisan tudja majd támogatni az aszinkron compute-ot. Legalábbis egyszerűen megoldható, hogy szabványos kódtól nem pusztuljon meg, így nem kell külön kódbázis rá, és még érni is fog valamit a párhuzamosítás. A Khronos most nagyon odatette magát, így szerintem a Vulkan jobb API lett.
Ú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.
- Konzol felvásárlás!! Playstation 5, Playstation 5 Pro
- Apple Watch Series 10 46mm Jet Black használt karcmentes 100% akku garancia 2026.10.26.-ig
- iPhone 17 Pro Max 256GB 100% (1év Garancia)
- Surface 3 - 13,5" 2k érintő, i5 1035G7, Iris Plus, 16GB RAM, SSD, jó akku, újszerű állapot, számla
- Értékcsökkentett gamer alaplapok /ASUS/MSI/AM5/Számlával/
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest