- Akciófigyelő: Humble Games Bundle - Nightdive FPS Remasters
- Call of Duty: Modern Warfare III - Új szezon, újabb ingyenes hétvége jön
- Hunt: Showdown - Jön az engine csere, befutnak az újgenerációs verziók
- Steamre tart a Crime Boss: Rockay City
- The Witcher - Befutott a TV sorozat folytatásának első rövid kedvcsinálója
- World of Tanks - MMO
- WoW avagy World of Warcraft -=MMORPG=-
- Escape from Tarkov
- Diablo IV
- War Thunder - MMO Combat Game
- Nintendo Switch 2 vagy amit akartok (találgatós topik most még)
- Forza sorozat (Horizon/Motorsport)
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- Xbox Series X|S
- Call of Duty: Black Ops 6
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
keIdor
#60453
üzenetére
Ez lehet, hogy nem volt világos. Nyilván a Refresht úgy van értelme megcsinálni, hogy mindegyikből kiadnak egy újat. Az 1-esből lesz 2-es és kész.
A +90%-ot ez a hsz. jobban kifejti: [link] - effekt szintjén kell értelmezni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#60455
üzenetére
Nézd a másik irányból. Kiadják a Vegákat, és ezek a packed math effektek dupla sebességgel futnak rajta. Tehát ha az NV a packed math eljárást használó játékokban is első akar lenni, akkor ki kell adni egy natív FP16-os Pascal generációt. Sokkal rosszabb az a megoldás, hogy a vezetőség elfogadja, hogy mostantól többek között minden Bethesda játékban elpicsázza a GeForce flottát a Vega. Ez alapvetően egy piaci verseny.
A fejlesztést pedig nyilván nem úgy fogják eladni, hogy aktiváltuk az eddigi hardverekben lekapcsolt fícsőrt, hanem csináltunk egy új steppinget és jól belefejlesztettük.
Tudod te, hogy ez nem igaz, meg én, meg innen még pár ember. A vásárlók 99,9%-a viszont nem tudja.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#60461
üzenetére
Per shader alapon. Van a friss DX verziókban olyan specifikált funkció, hogy minimum shader precizitás. A megírt shadereknél jelezni kell a szabványosan kezelt precizitások közül azt, amire minimum megoldható a futtatás. Ezt a fejlesztő választja ki. Tehát, ha egy shader esetében ez FP32, akkor a shader minden hardveren ezzel a precizitással fut. Ez ma a jellemző. Sok esetben azonban nincs szükség erre a precizitásra, mert nem lesz látható előnye az eredményben. Éppen ezért megadható minimum szinten az FP10 vagy az FP16 is. Ha FP16 a minimum, akkor az erre alkalmas hardverek ezen számolnak, és packed math támogatás esetén ezt kétszer gyorsabban teszik. A többi hardver FP32-vel számol. Ha FP10 a minimum, akkor FP32-höz képest, akár háromszor is gyorsabb lehet a számítás, de ilyen hardver nincs még. Talán nem is lesz, mert hardveres szinten ezeknek a képességeknek a kezelése azért nem olyan egyszerű.
A játékokban azért elég sok shader van, és jó részük igazából egy korábban megírt kód, amihez nem biztos, hogy megéri hozzányúlni, tehát a packed math lehetőségét az új shadereknél érdemes megfontolni. Leginkább az lesz a jellemző, hogy a nagy számításigényű effektek fognak packed mathot kapni, míg a régebbről hozott shadereknél marad az FP32. Nem beszélve arról, hogy a packed math csak akkor ajánlott használni, ha a kisebb precizitásnak nem lesz látható hátránya. Sok shadernél lenne, tehát ott már a minőség miatt is az FP32 a jó választás.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#60464
üzenetére
Sajnos alaplap is kell hozzá. Az elsődleges probléma most, hogy az AMD leadta az alaplapgyártóknak, hogy mennyi procit csinálnak, de az alaplapgyártók nem hitték, hogy ez a proci az ár/teljesítménye miatt ennyire kelendő lesz, emiatt relatíve kevesebb alaplapot csináltak a startra, mint amennyit proci készült. Április közepéig le fogják szállítani a megnövelt készleteket, de valószínűleg április végéig fog úgy normalizálódni a helyzet, hogy mindenhol lesz kellő alaplap a Ryzen készlet mellé.
Amíg volt kellő mennyiségű alaplap, addig az eladási toplistájának élén volt a termék a legtöbb webáruházban, de egy hete nagyon döcög az ellátás.Akciózni lehet. Az AMD már kompenzálja az árcsökkentést, mert ők is hibásak abban, hogy nincs elég alaplap. Így viszont a webáruház procikészlete annak ellenére is csökkenhet, hogy a vevő mondjuk nem tud hozzá alaplapot venni csak április közepe felé. Technikailag megérheti a vevőnek, mert így olcsóbban kap procit, mintha várna két hetet és visszaraknák az áruházak a normál árat.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#60469
üzenetére
Az OS-nél a teljes támogatást megoldja a Creators Update. Tehát az le lesz tudva áprilisban.
A játékoknál a detektálással van gond. Több fejlesztőt is felkerestünk ebben ügyben, és mindegyik azt mondta, hogy azért van gond a Ryzennel, mert a proci nyolcmagos, de a program oldalán az erőforrást detektáló kód az AMD-re négy szálig dolgozik. Ezt ki kell cserélni egy olyan kódra, ami képes legalább 16 szálat detektálni, mert az aktuális kódokkal csak a Ryzen negyede van befogva. Az AotS-nél van egy béta update, ami ezt megcsinálta. Gyorsult is 30%-kal minimum. De a DOTA 2-re is kaptam egy olyan választ, hogy jön egy patch, amiben már felismeri a program a Ryzent, és átlagosan 25%-ot gyorsít rajta. Na most nem fognak minden játékot felpatch-elni, de az újabbaknál már az AMD újabb ID kódját rakják bele.Erre egyébként mostanában dolgoznak ki újszerű detektálási formákat, mert a régi bevált módszer lehet, hogy jó volt a kettő-négymagos érában, de ha jön egy gyártótól egy nagyobb számú maggal rendelkező proci, akkor az extra magok addig nem számítanak, amíg a gyártói ID kód az adott családra nem bővül nagyobb magszámra.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Devid_81
#60481
üzenetére
Ma már nem olyan a szoftverfejlesztés, mint régen. A teljesítményért lemennek assembly szintig is. A Ryzennek az így beépített optimalizálások nem érnek semmit, mert ez egy új dizájn. Ha mondjuk az Intel vált egy új dizájnra, akkor ugyanezzel a problémával fognak szembesülni. Ha az AMD megint vált, akkor dettó.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Devid_81
#60656
üzenetére
Igen. Nagy különbség van a specifikáció véglegesítése és az implementációk megjelenése között. A specifikációt mindenképpen hamarabb kell kialakítani, mert arra lehet felhúzni a cégeknek az implementációkat. Ez nagyjából úgy néz ki, hogy a specifikációt egy ponton véglegesítik, és azután nagyjából két év, mire elkészül mindenki legalább egy implementációval, majd egy év még, mire a termékmintából tömeggyártásra alkalmas megoldás lesz.
A DDR5 egyébként inkább késésben van, mert eredetileg 2016-ban le kellett volna zárni a specifikációt. Hát ezt nem sikerült elérni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Puma K
#60700
üzenetére
Az AMD-nek ott a VSR-je. Azt is be lehet állítani 4K-ra, ha a hardver támogatja, de GCN3-tól felfelé mindegyik támogatja. Azért nem érdemes DSR-hez hasonlót fejleszteniük, mert az egy szoftveres megoldás, és a skálázásához a Lanczos resampling például eléggé drága. Ezért is alkalmaz az NVIDIA sima gaussian blurt, mert az relatíve olcsó megoldás, és még elfogadható mértékben mossa el a képet. Viszont az AMD a VSR-rel már Lanczost használ, mert ez van beépítve a hardveres skálázóba, és ha mondjuk építenének egy DSR másolatot, akkor annak lényegesen lenne a minősége a gaussian blurral. De ha mondjuk csinálnának egy DSR-hez hasonló szoftveres megoldást Lanczos resamplinggal, akkor azt meg azért nem használnák a felhasználók, mert a VSR-hez képest -15-20%-os lenne a teljesítménye, miközben ugyanazt állítja elő. A gaussian blurt például nem a minőségért választotta az NVIDIA, hanem azért, mert ez csak -2-3%-os tempóveszteséget jelent. Nyilván, ha a minőség számítana, akkor mennének a Lanczos felé, de az meg sokkal lassabb, ha nincs beletervezve egy fixfunkciós blokkban a hardverbe, ahogy az AMD-nél.
Itt egyébként egy csomó algoritmus eredménye ott van egymás mellett. Az alsó sorban összehasonlítható a guassian és a lanczos minőségkülönbsége:
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#60716
üzenetére
60 Hz-nél több nem igazán fontos, de a variálható frissítés lényegesen jobb bármilyen más vertikális szinkronnál.
Maga a V-Sync sem lenne rossz, csak egy erős extra késleltetést okozó szoftveres rétegen megy keresztül a Windowsban. A FreeSync és a G-Sync ezt a réteget megkerüli, pontosabban a Microsoft engedi megkerülni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
100k-ért TN panel egy vicc. De most komolyan. Ha már ennyit kiadsz, akkor már gyűjtesz egy picit és veszel valami használhatót.
(#60721) cyberkind: Az adaptívval az a baj, hogy ugyanúgy töri a képet, ha 60 fps alá kerülsz.
Egyébként pont a 60 Hz-es G-Sync miatt lett volna jó, ha elkészül a G-Sync ASIC. Mert az sokkal olcsóbb lenne, mint az FPGA, illetve lehetne bele normális skálázót is rakni. De így, hogy mindenki szarik a fejlesztésére, csak a rohadt drága monitorokon tud megjelenni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A TN paneleknél sajnos elképesztő különbségek vannak panel és panel között. Amiért ez gondot jelent az a G-Sync, mert ott a gyártó mindenhol megpróbálja behozni a licencköltséget, ezért sosem rendelik meg a legjobb paneleket, mert azok 50-70 dollárral több kerülnének. A jobb G-Sync kijelzőknél amik 800 dollár fölött mennek már nem szoktak spórolni a panelen, mert pusztán a magas árból egyszerű kigazdálkodni a 200 dolláros licencet. Mindenképpen érdemes a drágább kijelzőkre menni, hogy normális minőségű panel legyen benne, mert úgyis összespórolják a gyártók a komponensen az "olcsó" kijelző 200 dolláros licencét. Ez nekik is komoly pénz.
IPS-re csak azért érdemes menni, mert jóval kisebb a különbség panel és panel között.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az egy közepes minőségű AU Optronics M240HW01 panelt használt. Anno több 144 Hz-es TN paneles monitort ezzel szereltek. Se nem jó, se nem rossz, képminőségben abszolút középút a TN-ek között.
Hát azok az ASUS-ok sajnos nem véletlenül 200K-s cuccok. Mondom itt tipikus gondot jelent a G-Sync licenc költsége. Azt a 200 dollárt, ami csak egy engedélyre és egy tanúsítványra megy el, a gyártók megpróbálják magukon a komponenseken behozni. Hiába 120K egy kijelző, akkor sem fognak bele olyan minőséget rakni, ami jobb a G-Sync nélküli 50-60K-s kijelzőknél. Nem fér bele az átlagos nyereségre kikalkulált árba. Kisebb nyereségért pedig magát a G-Sync vonalat nem éri meg fenntartani, mert ennek is megvan a maga fejlesztési költsége. Szóval jó áron jót itt nem kapsz, mert egy papírlapért fizetsz be 200 dollárt az áron belül. Drágán persze van nagyon jó is.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#60768
üzenetére
Nyilván nem. De csak azért, mert egy régebbi AVFS verzió volt benne, míg az új lapkák megkapták a legújabbat, ami van a Ryzenben és lesz a Vegában.
Az 500-as sorozat tehát egy új AVFS-t tartalmaz, ami nagyobb órajelet tesz lehetővé, alacsonyabb üzemfeszültséggel.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#60773
üzenetére
A droop detektorok száma nőtt, de ilyenből kevesebb, mint egy tucat kell a chipbe. GPU-ról lévén szó valszeg nincs több benne 3-4-nél. Ehhez jön úgy kb. 10-15 hődióda, kb. ennyi teljesítménymonitor, és nagyjából 100-150 path monitor. Ebből a szempontból nem igazán változott a Polaris 10-hez képest.
A Ryzenbe azért kell 1300+ path monitor, 20 hődióda, 48 teljesítménymonitor és 9 droop detektor, mert nem csak négy state-et különböztet meg, mint a többi CPU, hanem százvalahányat. Ezért tudja helyenként verni a tízmagos i7-6950X-et, mert amíg ez a proci a 20 szálas terhelésre már ténylegesen alapórajellel dolgozik, addig a Ryzen 1800X még a rengeteg state miatt tud még olyan állapotokba kapcsolni, hogy 16 szálas terhelésnél is turbózzon az összes magon. Igazából az i7-6950X-ben is lenne ennyi tartalék, csak az állapotok között nincsenek finom átmenetek.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
keIdor
#60808
üzenetére
Addig örülj, amíg 1200 a max. Az AMD készül a második félévre egy 2000 dollár köré árazottal is. Annak még inkább nincs értelme otthonra. Na persze a Titan Z-t így sem fogják majd überelni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
#35434496
#60813
üzenetére
Amint lejár az NDA. Áprilisban kap Vegát a LiquidSky, szóval a gyártás már megkezdődött. Ugye a LiquidSky-nak ez lényeges, mert a publikus béta végéig minden GPU-t VEGA-ra akarnak cserélni a szervereikben. Ez nagyjából 35-40 ezer kártya. Szóval már bőven gyártani kell, ha a LiquidSky el akarja érni ezt a célt. Nekik ez már az üzemeltetési költség miatt is nagyon fontos, mert majdnem a felére csökken a fenntartási költségük a VEGA beszerelésével. Enélkül a lépés nélkül nem tudnak majd nyereséget termelni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
TTomax
#60943
üzenetére
De ez a butítás kell a jobb futáshoz egy nagy baromság. Teljesen általános, hogy ha egy programba beleölnek még egy rakás munkaórát, akkor optimalizálnak rajta annyit, hogy jobban fusson. Főleg egy olyan rosszul optimalizált programnál, mint amilyen a Bulletstorm volt az elején. Már amiatt is nagyon sokat lehetett benne javulni, hogy az UE3 leképezőjénél az UE4 megoldása sokkal gyorsabb. Ugyanazt legalább háromszor gyorsabban számolja ki. Öt év alatt olyan szinten lép előre pusztán szoftveresen egy motornak a teljesítménye, hogy a gyorsulás nemhogy furcsa, hanem egyenesen elvárt, hiszen extra munkaórák ezrei vannak a rendszerben, az ezekhez tartozó optimalizálással.
Nagyon korlátolt azt hinni, hogy gyorsulni csak úgy lehet, ha új hardver kerül a gépbe. Nem, a mai hardverek kihasználása igencsak alatta van az optimálisnak, és sosem fogja elérni a megfelelő szintet, viszont öt éves különbséggel az elégtelenről el lehet érni az elégségesre. Erre vonatkozóan még az anyagi teher sem akkora, hogy a vezetőség rögtön azt mondja, hogy nem szabad vele foglalkozni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#60952
üzenetére
A végeredmény eltérő, de azt kellene megérteni, hogy ennek igazából semmi köze nincs az alatta futó technológiához. Mindenből többet számol az új motor, és ez pusztán csak azért lehetséges, mert eltelt öt év és munkaórák százezreit rakták bele, hogy hatékonyabb legyen a motor.
A végső eredmény szempontjából pedig ott van egy olyan tényező is, mint a dizájn. A megrendelt tartalom minősége, a megváltoztatott paraméterezések, de ezekhez kevés köze van egy programozónak. Ezt a dizájnnal foglalkozó csapat beszélte át, és az új lehetőségeket mérlegelve változtattak rajta.
Azt le lehet írni, hogy esetleg a remaster új dizájnja nem tetszik, végtére is nem muszáj egyetérteni a fejlesztők döntéseivel a grafikai dizájnra vonatkozóan, ez viszont nagyon szubjektív. De az egyértelműen nem igaz, hogy nem fejlődött technológiailag a Bulletstorm. Lényeges a különbség az eredeti kiadáshoz képest, és számottevően többet is számol az új verzió.(#60942) Keldor papa: Ez Unreal Engine 4. Az UE3-nak nincs támogatása a PS4/X1 felé. Be lehet építeni, de sokkal több munkával jár, mint a motorváltás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#60968
üzenetére
Van Ryzen 5-ünk. Kettő is. Le is mértük már mindkettőt.
Amint lesz idő rá, kimegy a teszt. Csak most egy ember három tesztet csinál egyszerre. Nem egyszerű így dolgoznia. Gondoltuk, hogy nem lesz meg az NDA-ra. Az új VGA-kat megpróbáljuk megcsinálni időre, de ott is necces a dolog, amíg en a műtétből lábadozom, míg másnak is van egy csomó egyéb dolga.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
MiklosSaS
#60970
üzenetére
Egyébként minden gyártó tiszteli a PH-t, sőt minden médiát, nincs itt semmiféle harc senki között. Mi elsődlegesen azért vagyunk kiemelt státuszban, mert a legolvasottabb IT média vagyunk az országban. Nem tiszteletlenségből nem küldött az NV 1080 Ti-t, hanem azért, mert maga a piac nem akkora, hogy több VGA-val ellássák ezt a területet, illetve a vállalat szeretne inkább a Youtube felé nyitni, és a Youtubereket előnyben részesíteni a médiával szemben. Tehát, ha egy területre mondjuk csak két kiosztható kártya van, akkor egyre esélyesebb, hogy azokat elsőként Youtuberek, vagy üzleti partnerek kapják meg. Egyre többen mennek ilyen irányba, mert nagyon lényeges, hogy a Youtuberek rosszat nem mondanak a termékről.
Egyre inkább az lesz az irány a gyártóknak, hogy a youtuberek és az ismert streamelők kapnak kártyát elsőként, hogy a rajongóik vegyék meg azt, csak azért, mert a "hősük/sztárjuk" már azzal játszik. Ezután jönnek majd a tesztek. Ez egy nagyon kritikus üzletstratégiává fog válni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#61072
üzenetére
Semmi jelentősége nincs neki a sorrendben. A Division még ilyen beállítások mellett sem zabál 4-5 GB-nál több VRAM-ot (benchmarkban konkrétan 4 GB alatt van a 4K és a 200%-os res. scale, direkt megkérdeztük). A Radeon elsődlegesen a DX12 miatt van előnyben ebben a tesztben, mert a fejlesztők ezt utólag rakták bele, és csak olyan formában, hogy GCN-re van optimalizálva a memóriamenedzsment (ezt is elmondták). Az NV-re való optimalizálás sosem készült el, illetve sajnos olyan pufferformátumokat is használnak, amelyeket nem lehet bekötni a root signature-be, és az NV-nek erre is szüksége lenne. Elméletben tudna gyorsulni egy GeForce a DX12-ben a mostani eredményhez képest is 8-12%-ot, amit az Ubi régebben el is ismert, de csupán ezért nem fogják újradizájnolni a leképezőt (ez már végleges döntés). Emellett a DX12 a GeForce-on is gyorsít egy kicsit a DX11-hez képest, tehát annyira nem elégedetlenek vele, de tény, hogy Radeonon sokkal többet gyorsít.
A DX11-ben más lenne a sorrend, de ott mindegyik hardver lassabb lenne.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Vegának semmi haszna nincs ebből a beállításból. Ahhoz, hogy előnyt kovácsoljon belüle 16 GB-nyi VRAM igényének kellene, hogy legyen, de ennek a negyedével is beéri 4K+200% res. scale alatt is. Innentől kezdve a Vega előnye ebből semmis. Abból lehet, hogy esetleg a memóriamenedzsmentje az Ubisoftnak nem ideális, de elmondásuk szerint az Xbox One-ról hozták át, ezért túl sok tartalék nem maradhatott benne a Radeonra nézve.
Igazából a DX12-ben egy alapvető optimalizálási tényező van. A root signature esetében elhelyezhetők a buffer viewek magában a root signature-ben, vagy beköthetők a leírótáblákban. Utóbbi esetében van kezelve minden pufferformátum, ezért a Microsoftnak ez a hivatalos ajánlása. DE!!! A GeForce-oknak hardveres szinten ez nem ideális, mivel így pixel shader teljesítményt vesztenek, ezért az NVIDIA azt ajánlja, hogy a buffer viewek közvetlenül kerüljenek bele a root signature-be. Na most ezt egy játék vagy betartja, vagy nem. A közvetlen bekötésnek az a hátránya, hogy nem mindegyik pufferformátum kezelhető. Hiába NV-s cím a Division, ha a pufferformátumok olyanok, hogy nem köthetők be közvetlenül. Csak emiatt nem fogják a leképezőt átalakítani, mert túl sok időt vinne el, és eközben a játék már ki van adva, a gyártók is megcsinálták rá a shaderekre vonatkozó optimalizálást a driverben.
A két opció között a Radeonon és az Intel IGP-ken nincs különbség, de a GeForce a közvetlen bekötésekkel 5-15% közötti mértékben gyorsabb lehet, mint ha a fejlesztő a Microsoft ajánlásai szerint a leírótáblákba kötné a buffer vieweket. A helyzet az, hogy közvetlenül bekötött buffer viewekkel csak a Rise of the Tomb Raider dolgozik, tehát hiába ez a rosszabb megoldás a piacnak (elvégre a GeForce lassul tőle, míg a Radeon és az Intel IGP-k immunisak rá), a konzolról áthozott leképező miatt PC-n is maradnak ugyanazok a pufferformátumok, amelyek az esetek többségében csak közvetve köthetők be.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#61082
üzenetére
Akkor lehet, hogy a DX11-es driverek fejlődtek. Sajnos az NV-t a DX12 nagyon hátrányosan érinti, ha nem a GeForce-hoz való root signature modellt használják a fejlesztők. Ez van. A Voltánál már megoldják ezt a problémát.
Senki sem írt a GameWorks middleware-ről, mivel annak a DRM-je nem kompatibilis a DX12-vel. Ahhoz, hogy ezek az eljárások működjenek DX12 alatt új DRM-et kell alkalmazni. A régebben DX11-es, de később DX12-es móddal kiegészített játékoknál azért nincs GameWorks, mert a motort a DRM-hez is fel kell készíteni, és nagyon nehéz azt megoldani, hogy a rendszeren belül működjön DX11 és DX12 módban is a GameWorks különböző DRM-mel. Ezért van az, hogy esetenként a HBAO+-t csak úgy odaadják forráskód szintjén, mert gyakorlatilag képtelenség middleware-ből beépíteni. Forráskódból már nyilván megoldható, de a többi effektet nem adják oda. A GameWorks esetében tehát vagy eleve a két DRM-hez kell igazítani a motort, vagy választani kell a DX11-es és a DX12-es verzió között. Az Ubit ez az egész különösebben nem érdekli, mert nem náluk van a megoldás kulcsa. Ők nagyon szívesen beraknák, ha az NV lenne olyan kedves és odaadná nekik a forráskódot.
MSAA-val és SSAA-val sem pont annyi pixelt renderel, amennyi megjelenik a kijelzőn. Sőt, ha nagyon szigorúan vesszük, eleve jóval több pixeled lesz, mint amennyi megjelenik, és a raszterizáció hatásfokától függően egy részük még el is lesz dobva. Emiatt vált egységesen a felbontás mérőszámává a frame pufferbe került kép felbontása.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#61084
üzenetére
Inkább PIX-szel érdemes nézni, mert az pontos is. Ezek a külső programok ezen a szinten már nem jók semmire. Maga az API nem teszi lehetővé, hogy egy alkalmazás által menedzselt memóriaterületre más alkalmazás egyáltalán ránézzen. Ezért is jobb ezt megkérdezni a fejlesztőktől, mert ők tudják, hogy mennyi VRAM-ot eszik, hiszen ők állították be DX12 alatt a konfigurációt.
A felbontások maradtak. A kiírt képpontszám került a frame pufferbe. Oda van írva, hogy minden maximumon volt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#61086
üzenetére
A benchmark részre ez lényegtelen. Az Ubi írta, hogy annyira kevés ideig fut maga a teszt, hogy nem fog előjönni ez a driverbug. Direkt rákérdeztem, hogy féljünk-e tőle, mielőtt DX12-re átraktuk a DX11-ről a Divisiont. Ha azt írták volna, hogy három perc alatt előjön, akkor maradtunk volna a DX11-es méréseknél.
(#61087) akoska07: Semmiféle nem létező VGA-ra nincs paraméterezés. Nem lehet ráállítani a programot. Ez hoax. Az 1080 Ti-re lőttük be a beállításokat. A Division esetében direkt kikértem az Ubisoft véleményét, mert kétségek merültek fel a DX12-re való átkapcsolásról, főleg amiatt, mert az NV nagyon nem ajánlja, de az Ubi írta, hogy nyugodtan menjünk DX12-re, mert három percen belül végez a teszt, és ezalatt nem fognak előjönni a driverbugok. Ha az Ubi azt mondta volna, hogy a kétségeink jogosak, akkor maradtunk volna a DX11-nél.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#61097
üzenetére
Az SSAA-t azért ne keverjük a res. scale opcióval. Az SSAA esetében esetleg lehetnek még különböző negatív LOD eltolások is, amelyeket a res. scale nem alkalmaz. Az igaz persze, hogy a képkockák szintjén a számításigény nagyjából hasonló.
A DSR/VSR-t sem igazán érdemes egy programba épített túlmintavételezéssel összehasonlítani, mert nagyon sok különbség lehet a skálázásra használt eljárásban. Már a DSR és a VSR között is elég nagy az eltérés.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#61099
üzenetére
Lehet más is a látvány, nagyon más is. Ezért nem érdemes ezt összehasonlítani.
Amikor a túlmintavételezésről beszélünk, akkor egy meghatározott mintavételezés esetén például 4K-s kép lesz visszaskálázva Full HD-be. A képszámítás tekintetében ugyanannyi pixel van, viszont a visszaskálázás már nem meghatározott, az történhet például guassian blurral, catrom, esetleg lanczos resamplinggel. Ezek között a képminőségkülönbség igen jelentős. [link]. Például az NV DSR guassiant használ, míg az AMD VSR lanczost. A Division beépített rendszere catromot. Azért nincs egyértelmű választás, mert például a legjobb minőséget simán a lanczos hozza, viszont ha nincs a hardverben egy fixfunkciós skálázó rá, akkor viszonylag drága shaderről van szó (ezért használja csak az AMD, mert ők raktak egy fixfunkciós lanczos resamplinget a hardverbe, tehát nekik ez így a VSR-en belül a végeredményben ingyenes). A guassian rendkívül olcsó eljárás, viszont ez adja a legrosszabb minősége. A catrom amolyan középút, se nem minőségi, se nem lassú, de a guassiannal jobb az előállított kép, és csak viszonylag kevés extra terheléssel jár. Ebből látszik, hogy hiába gondoljuk ezeket az eljárásokat ugyanannak, messze nem ugyanazok.
Az SSAA esetében is hasonló a helyzet. A mintavétel meghatározásán túl lehet rotated, regural, ordered, sparse és jittered grid megoldásról szó, illetve alkalmazható negatív LOD eltolás is. Utóbbi persze nem tipikus, de például az AMD driverébe épített megoldás (ami egyébként sparse grid) 2x esetén -0,5-ös, 4x esetén -1-es, 8x esetén pedig -1,5-ös LOD-dal dolgozik. 8xSSAA-nál ennek ez a hatása (a háttérben lévő falon tökéletesen látszik): normál LOD és -1,5-ös LOD. Ilyet például egy túlmintavételezéssel nem csinálnak. Lehetne, csak a legtöbb leskálázási algoritmussal eleve elveszik a minőség egy része, így a negatív LOD hatása jóval kevésbé lenne érezhető, mint SSAA esetében. A játékokba épített SSAA-k az utóbbi időben úgynevezett sztochasztikus megoldások, ami a jittered grid egy speciális formája. Az a lényege, hogy a mintavétel pozíciója teljesen véletlenszerű, ami segít leképezési hibák elrejtésében, így annyira nem szükséges LOD korrekciót alkalmazni.Igazából nincs olyan megoldás, ami optimális. A túlmintavételezésnél a lanczos resampling a legjobb, viszont ez is a legdrágább. Az élsimításnál a sparse grid SSAA adja a legjobb eredményt autoLOD funkcióval, viszont megint ez a legdrágább. Egy alkalmazásnál a fejlesztőknek figyelembe kell venni, hogy azért nincs végtelen erőforrás a rendszerben, tehát valahol kompromisszumot fognak kötni. Ez még a gyártókra is jellemző, lásd az NV DSR-t, amely csak azért guassian blurt használ, mert arányaiban annak van a legkisebb erőforrás-igénye, hiába van több jobb skálázási algoritmus helyette, akkor is ez éri meg az összes tényezőt beleszámítva. Az AMD a VSR-nél is simán guassian blurt használna, ha nem építettek volna direkt fixfunkciós lanczos skálázót a kijelzőmotorba. Így nekik ez ingyenes, de amúgy egyértelműen nem érné meg a lanczos, ha a shadereken futna, hiába jobb a képminősége.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az MSAA az egyértelműen más. Ez csak azt vizsgálja, hogy a háromszög mennyire fedi le az adott pixelt. Technikailag az MSAA nem számít ki több majdnem végső pixelt, mint amennyi bekerül a frame pufferbe, de sokkal több Z-tesztet csinál. Ezért terjedt igazából el az MSAA a többi AA helyett, mert a fill rate-et nem terheli meg. Egy SSAA vagy mondjuk egy túlmintavételezés már a fill rate-et is lezúzza.
Arányaiban az MSAA minőség/teljesítmény hányadosa a legjobb, csak nem biztos, hogy kompatibilis az új motorokkal, és ekkor már speciális MSAA-kra van szükség, ami leronthatja annyira a teljesítményt, hogy más AA, esetleg maga a túlmintavételezés jobb választás lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Én csak segítek megérteni. Valójában a teszthez semmi közöm nem volt. Nem vettem részt benne a műtéti lábadozásom miatt. Ezért sem érti senki az elfogultság dolgot, mert az ég világon semmit sem tettem ehhez hozzá. Még a beállításokról sem döntöttem.
(#61118) akoska07: Valószínűleg csak copy-paste miatt. Eléggé időre dolgoztak a srácok, így erre már nem figyeltek. Különösebb jelentősége ennek nincs, de levettem, ha ez segít.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Puma K
#61151
üzenetére
Alice Madness Returns-ben a hajnak semmi köze nem volt a PhysX-hez. Ez a fejlesztőknek egy saját CPU-s megoldása volt, aminek a szimulációs alapja egyébként a Bullet volt. Hajra és szőrre PhysX-et sosem használt senki.
A ruha igazából szakítható lenne, ahogy a karaktermodellen is keletkezhetne sérülés. Emellett maga a környezet is rombolható lehet, akármikor. Ami miatt ez nem történik meg, az a befektetendő munkamennyiség. Middleware használatával ez nehezen kivitelezhető, mert erre kell felkészíteni az egész motort, és ez igen nehézkes. Ezért nincs például most fejlesztés alatt PhysX cím, mert megjöttek az új konzolok, a régi motort újra kell cserélni, és megint kezdődhet elölről a middleware integrálása, a DRM-jének a kezelése, és egy rakás dolog, amin csak azért kell átnyögnie magát a fejlesztőnek, hogy egyáltalán működjön a rendszer. A régi, PhysX-szel már integrált környezetekre már nem lehet építeni, mert ezek nem támogatják az új konzolokat. Ezért torpant meg most a piac ebből a szempontból, na meg persze azért is, mert az NVIDIA annyira átírta a PhysX 3.4-et, hogy az már nem kompatibilis a korábbi verziókkal, tehát ha az új 3.4-es verziót és a régit is támogatni akarják, akkor nem egy, hanem két middleware-t kell integrálni ugyanarra, mindezt duplaannyi munkával, duplaannyi teszteléssel, ami egyértelműen nem célja most senkinek. Inkább megvárja mindenki, amíg letisztul a szoftveres kép. Ugye itt nem az új verzióval van a gond, hanem azzal, hogy az NVIDIA a régit kiveszi-e a driverből, hogy csökkentsék a fejlesztésük komplexitását. Emiatt nem akar most senki sem lépni, mert nincs garancia arra, hogy az NV nem húzza ki a saját middleware-je alól a padlót, és akkor a befektetett munka ellenére úgyis az új verzióra kell menni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az 1080 Ti lapkája is tud ennyit, csak le van fojtva a GPU, ami a kártyára kerül. Emiatt a meghajtó minimum precizitásnak FP32-t jelez vissza a DX12 API-nál. Esélyes, hogy a GeForce 20 series már tudni fogja ezt a képességet, és akkor ugyanaz a GPU dupla teljesítményt fog leadni FP16 módban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez már nem a DX12-ről szól. A Microsoftot a wave operation intrinsics esetében én sem nagyon értem. A fejlesztőknek ma is vannak gyártófüggő opcióik a problémákra, lásd AGS4.0 a DX11-re és DX12-re. Oké global ordered append függvények még nincsenek benne, de belerakhatók, csak döntés kérdése.
A probléma sokkal inkább az, hogy nyoma sincs az egységesítésre vonatkozó kísérleteknek. A WaveBallot csak azért tér vissza 64 bites maszkkal, mert az Xboxon 64 bites egy skalárregiszter. Semmi más reális oka nincs annak, hogy ez így legyen. A Vulkan esetében kisebb maszk tér vissza, és lesz belőle baja valakinek? A GCN-nek biztos nem, a többi gyártó pedig örül neki, mert hatékonyan implementálható lesz tőle másnak is a Ballot. Szóval ez a puskapor nem korán van ellőve, hanem rosszul van megtöltve a fegyver. Egy API-nak az lenne a feladata, hogy találjon valami mindenki által elfogadható megoldást a problémákra, nem pedig az, hogy kijelöljön egy hardvert, ami PC-s piacon még csak nem is tényező, majd annak a specifikációjára szabják a rendszert. Az ilyen elven történő fejlesztés azért gond, mert egy csomó dolgot így még a Volta sem tud majd megoldani hatékonyan.
Ha valaki 64 bites maszkkal visszatérő Ballotot akar, akkor használjon AGS4.0-t. De nehogy már a szabvány legyen egy ilyen követelményre felhúzva. Ez szembe megy a józan ésszel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
akoska07
#61272
üzenetére
Q4 lesz szerintem az a Q3. Azért ennyit előreugrani nem lehet. Pár hónapja 2018Q1 volt a target. Egy negyedévet lehet faragni gyors munkával, de kettőt nem igazán, azért a gyártás előkészítése eléggé fix időtartammal történik.
A Pascal pedig itt lényegtelen. A Vega ellen kell egy hasonló képességekkel rendelkező hardver, kiemelve a general purpose memory paging képességet, ami a következő nagy ugrás a GPU-k területén, ez az "új unified shader". Olyan hamar hozzák, majd emennyire hamar tudják.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Nem ezt nézi az Intel, hanem azt, hogy idén ők is úgy számolnak, hogy nagyjából 50 explicit API-s játék jön. Ezen belül is írták, hogy ezek 90%-a nem, hogy 16, hanem 24 szálig is lineárisan skálázódik (hint: ezért hoznak 12 magos/24 szálas verziót). Ergo tök jó, hogy vannak négymagosaik, de az új játékok nyolc mag alatt lényegesen gyorsabbak lesznek. Ezért kell a frissítés, még az őszi-téli játékdömping előtt. Semmi bajuk nincs amúgy a négymagosokkal, csak ez a magszám lesz az új belépőszint. Nem véletlen, hogy az új platformból lesz két négymagos belépőnek, és aztán jönnek hat-, nyolc-, tíz- és tizenkét magosok. Úgy tudom, hogy tíz- és tizenkétmagosból csak egy-egy jön.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Devid_81
#61355
üzenetére
Tokozásban elvileg jó lesz az LGA1151-be a Kávétó, de a VRM specifikációk annyira megváltoztak, hogy nem biztos, hogy a 100-as chipsetekkel is működni fog. Ez friss adat. Na meg magunk között szólva az alaplapgyártók sem elégedettek a 200-as sorozatú vezérlőhidas alaplapok eladási adataival, tehát lehet, hogy a háttérben megy egy kis "ne legyen már jó a hatmagos a 100-as sorozatba".
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#61399
üzenetére
A PC-be hoztak már egy olyan újítást, ahol ha 19 játék erejéig is, de leverhető a konzol késleltetése.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Szóval szerencsére ez már nem általános. Bár nektek a Raden Chill elérhetetlen, de ennek a jóval régebbi, csak DX9-et támogató verziója a HiAlgo Chill.
Az AMD még nem szüntette meg a honlapot, így az általános 0.4-es verzió elérhető. [link]
Még korábban kipróbáltam vele a Skyrim-et és azon működött, de sajnos a programnak az lett a veszte, hogy nagyon driverfüggő volt, ezért is adták el magukat a srácok az AMD-nek, hogy gyártón belül folytassák a munkát, mert úgy néz ki, hogy ez általánosan nem megoldható. De próba szerencse. A programot mentsétek későbbre, mert ki tudja, hogy meddig lesz elérhető.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#61446
Abu85
HÁZIGAZDA
Firestormhun
#61409
Abu85
HÁZIGAZDA
válasz
Firestormhun
#61409
üzenetére
Ez nem csak azért van, mert figyelnek, hanem konkrétan megkapják a lehetőséget, hogy figyeljenek rá. Egy PC-n senki sem ad direkt hozzáférést a hardverhez. A GPU-k esetében az UMD kezeli az allokációt még az új API-kkal is, míg a rendszermemória esetében a Windows. A fejlesztő csak annyit mondhat meg, hogy melyik allokációt akarja törölni, vagy akar lefoglalni egy új területet, de minden mást egy hardver feletti réteg végez, amihez a programnak nincs hozzáférése. A konzolon konkrétan az van, hogy a memória egy része le van választva. Az operációs rendszer a rendszermemóriának egy területében dolgozik, és a maradékot egyszerűen nyersen megkapja a program. Olyan dolgokat csinál benne a fejlesztő, amit akar, mert se egy driver se egy OS nem fogja megakadályozni a lehetőségeket. Például konzolon simán valós időben defragmentálják a memóriát, mert nem kell virtuális memória, és egy rakás köztes dolog, amelyeket igazából csak a hardverek közötti különbségek elfedésére hoztunk be, de az előnyeik mellett akkora fékek, hogy az sokszor nagyon fáj. Tehát ha a PC-n valaki figyelni akar erre, akkor még ha akarná sem tehetné meg, nincs meg az a szintű kontroll, ami ehhez kell.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Puma K
#61451
üzenetére
Ez a foglalatkérdés bonyolult, mert minden foglalat sérülékeny, de a PGA típusú foglalat mellett elsődlegesen azért maradt az AMD, mert az jóval kevésbé sérülékeny, mint egy LGA. Ez két okra vezethető vissza. A processzort nagy nyomás mellett is a NYÁK-on fogja a tokozás, tehát sosem történhet meg az, hogy a proci NYÁK-ja elhajlik, lásd Skylake bending. Másrészt az is sokkal ritkább jelenség, hogy tűk elhajlanak, mert akkora nyomás kifejtésére van szükség, amekkorát csak hibás lefogatók tudnak megoldani. Emiatt maradt a consumer holmi a PGA-nál. Nagyságrendekkel kisebb a sérülékenység. Az LGA előnye, hogy alapvetően olcsóbban gyártható vele a processzor, de sérülékenyebb az egész rendszer, emiatt nagyon kell vigyázni, hogy a megvásárolt hűtővel a kifejtett nyomás ne legyen az adott proci NYÁK-ja által elviselhető nyomás felett.
Az ominózus esetben az történhetett, hogy a hűtés felszerelésénél az egyik sarokban kicsit jobban be lett szorítva a csavar, ami a két szomszédos csavar lefogatása mellett már meghajlította az alaplapot. Ezért érdemes előbb rákapatni mind a négy csavart, majd utána mind a négy csavarponton csak egy teljes kört húzni rajta sorban. De nyilván a PGA tokozás strapabírása miatt még egy nagy oldalsó nyomásra sem keletkezik fizikai sérülés. Egy LGA-val már hajlott lenne maga proci NYÁK-ja és a lábak az alaplapon, ugyanis azok viselték volna el a nem arányos nyomást, nem pedig a masszívra tervezett foglalat.
Felsőbb szinten egyébként az AMD is az LGA-val dolgozik, mert ott inkább rámennek az olcsóságra, tudva azt, hogy a szerverholmikat azért tapasztalt emberek rakják össze.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Puma K
#61534
üzenetére
A szimpátia lényegtelen tényező egy foglalat megválasztásánál. Egyértelmű, hogy az LGA típusú foglalatok olcsóbbak a processzorgyártó számára, mert nem nekik kell a tűvel hülyéskedni, vékony lehet a NYÁK, és igazából, ha rossz is a nyomáspont, akkor sem a proci megy tönkre, hanem az alaplap.
A probléma inkább a user oldalán keletkezik, mert a PGA típusú kivitelezéshez képest egy LGA típusú megoldást nagyságrendekkel könnyebb tönkretenni, amiatt, hogy a tűk viselik a hűtő nyomását, és egy rosszul behúzott csavar, vagy egy rossz felfogatóval rendelkező hűtő, elhajlítja a procit és a tűket az alaplapon.
Egyébként dalolva mennének az LGA-ra, ha nem lenne ennyire sérülékeny, mint ahogy a szerverben is LGA-t használnak, mert sok tűre már ez az ajánlott, de ilyen 1500 alatti tű mellett egy user sokkal jobban jár a PGA típusú megoldással, mert az LGA-ra kivethető nyomás kétszeresét is kibírja a hardverek fizikai sérülése nélkül. De kétségtelen előnye az LGA-nak, hogy olcsóbb, nem véletlen, hogy az Intel erre ment rá.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az elején lehet gond az ellátással. De a hiányokon már túl van a piac. Alaplapból is van elég április közepe óta, mivel jóval többet gyártanak az alaplapgyártók is. Prociból pedig már közel napi százezret tud szállítani az AMD, ez a kezdeti mennyiség többszöröse. Kizárt, hogy elfogyjon a nagyobb áruházakból. Addig van baj, amíg tízezres szinten van a napi szállítás, de ilyen csak márciusban fordult elő. Egyébként nem véletlen, hogy az R7-tel jelentek meg először, mert azok drágák és a kezdetben kevés volt a leszállított mennyiség is. Azért jött az R5 áprilisban, mert már a kezdeti mennyiség többszörösét gyártja a GloFo. Az R3-ra jön a következő bővítés a gyártókapacitásban. Akkor már napi szinten jóval százezer felett is tudnak majd szállítani. Áprilisban már szállít az AMD az OEM-eknek is, tehát az a piac is kezd becsatlakozni. Az elején azért volt csak DIY only a Ryzen, mert napi kb. tízezer termék nem elegendő a teljes világra, ha az OEM-eket is kiszolgálják.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
tailor74
#61635
üzenetére
Nem csak a Vulkan marad. A Vulkan csak a legjobb alternatíva, mert eléggé független az OS-től. De nyilván lesznek olyanok, akik inkább a DirectX 12 felé mennek. Van olyan stúdió, amelynek ez a jobb út, de a többségnek a Vulkan jobb.
A legacy API-kat pedig nyilván ledarálják az újabb motorokról. Azok csak fékek a lehetőségek előtt. Például, ha egy játék Vulkan API-t támogat, akkor semmi szükség rájuk, mert Vulkan van mindenhol. Azt az erőforrást, amit beleölnek két API támogatásába, szimplán bele tudják ölni a Vulkan mód optimalizálásába. Az ID Software számára ezért egyszerű a választás. Hátrány nélkül léphetnek előre.Nem csak az ID gondolkodik így. A Nitrous esetében is a Vulkan lesz hosszú távon fejlesztve, illetve a Star Citizen is a korábban bejelentett API-k (DX11, Mantle, DX12) helyett csak a Vulkánt támogatja majd.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
tailor74
#61638
üzenetére
A DX12-nek eddig sima útja volt. Elvégre a leggyorsabban terjedő API, amit valaha készítettek. A Vulkan útja nehéz, mert nem lehetett hozzá HLSL shadereket fordítani, de a Microsoft új fordítóstruktúrája segít ezen, mert nyílt forráskódú lett. Emiatt kezdett most feltüzelődni ez a pro-Vulkan hangulat a fejlesztőknél, mivel így már könnyű SPIR-V-re fordítani sokszázezer sornyi HLSL-t.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Tudod te, hogy ez nem igaz, meg én, meg innen még pár ember. A vásárlók 99,9%-a viszont nem tudja.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Szóval szerencsére ez már nem általános. Bár nektek a Raden Chill elérhetetlen, de ennek a jóval régebbi, csak DX9-et támogató verziója a HiAlgo Chill.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen