- Honor Magic V5 - méret a kamera mögött
- Szuperkijelzővel készül a Huawei Mate 80 RS
- MIUI / HyperOS topik
- Milyen okostelefont vegyek?
- Szívós, szép és kitartó az új OnePlus óra
- Apple Watch
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Fotók, videók mobillal
- Minden a BlackBerry telefonokról és rendszerről
- Xiaomi Smart Band 10 - a hetedik napon megpihen
Hirdetés
-
Mobilarena
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
#9732
Menthirist
veterán
gbors
#9730
Mi a franc köze van a játékélménynek a textúrafelbontáshoz? Régi játékok 100 mega vramot nem ettek, mégis jó volt a játékélmény, de ez most teljesen lényegtelen. 3 giga vrammal a játéknak lehetősége van szebben kinézni, magasabb felbontású, élesebb textúrából jelenhet meg több, több effekt, nagyobb látótáv. Egyszerűen jobban tud kinézni. A játék ettől függetlenül olyan élményt nyújt, amilyet. De ezzel az erővel legyen csak 1 giga a csúcskarikon, mert ha jó a játék akkor elég az is -.-
megjegyzem nem a g-sync vásárlókat balekoztam le, hanem azokat, akik a Titan-ért is képesek voltak egész addig pakolgatni az 1000-1100 dolcsikat, amíg az nv alájuk nem vágott egy jó 40-50%-al olcsóbb 780 Ti-vel, mert kijött a 290X. A titan-t pedig mindenhol az oldalán ugyanolyan játékkártyának állították be mint a 780-at, szóval a súlyos felár ez alapján nézendő. Az nvidia-nak szokása szép magasan tartani az árait amíg csak lehet, ami ugyan üzletileg érthető, csak épp felfordul tőle a gyomrom.
-
HSM
félisten
Ó, tudom én.
De egy ennyire komoly megrendelésnél sem tűnik reálisnak az 50 dolláros ár PCB-vel, memóriával, és azzal az óriás FPGA csippel. 
Ami a feltételezésed illeti, szvsz az A-sync fejlettebb, érettebb megoldásnak tűnik a G-syncnél. Nincs okunk azt feltételezni, hogy ne működjön majd legalább olyan jól.
A BF4-re amúgy igaz, hogy 2GB-nál nemcsak a mérő szalad feljebb, hanem jelentősen rosszabbul is fut 2GB-os kártyán. De anno volt ez téma valamelyik topikban, ott volt még pár játék, ahol hasonlókat lehetett tapasztalni. Főleg GTX680-ról 780-ra, vagy 7970-re váltó userektől. Persze, a GTX680 topikban mindenki szentül meg van győződve róla (meg úgy általában minden 2GB-os kártya tulaj), hogy bőven elég az a mennyiség... Ami jó sok játék esetén nyilván igaz, viszont másoknál csak azért gondolják ezt, mert nem látták még több VRAM-os kártyán.
-
HSM
félisten
Ami pedig a VGA sales-t illeti, van egy adu ászuk. Akire rásóznak egy ilyen G-sync csodát, már AMD-t nem vehet, ha ki akarja a G-syncet használni, tehát sanszosan bebetonozták magukat a usernél, míg megvan a monitora.
A VGA sales vesztésre pedig az ászuk, hogy az új GPU-ik, pl. a 970/980 csendben tudja az eDP1.4-et, amivel a Freesync támogatás elviekben megoldható.... -
#9722
Menthirist
veterán
gbors
#9720
A star citizen konkrétan megeszik annyit amennyid van. De a Farcry 4 is hajlamos rá, akárcsak a Shadow of Mordor vagy a bf4. Ha 2 gigád van, akkor csak annyit tölt be, ha van 3, akkor annyit, ha több, még többet.
A g-sync pedig nem a freesync-től marad 200 dolcsi vagy esik, hanem simán csak az nvidia szokásos árazásától. Egy ideig túráztatják a balekokat a 200 dolcsival, aztán majd engednek. Feltűnhetett az elmúlt években hogy ez a módszerük. Persze ez nekik marha gazdaságos, valakikből ki is kell termelni a szép kis profitot...
-
HSM
félisten
-
HSM
félisten
Hű, pedig egy GTX680 erejéhez már nagyon kéne 3GB.
Jópár játékhoz 2GB nem elég, amikor maga a GPU míg vígan ficánkolna.A kereskedelmi kérdést nem hagyhatjuk figyelmen kívül, ugyanis a 4GB-os verzió nagyfokú túlárazottsága révén nem volt valódi alternatíva.
Az A-sync monitorok ára szvsz addig lehet csak magas, míg nagyon kevés modell tudja. Ha beindul az árverseny, máris nem ez lesz a helyzet. A G-synces monitorok ára viszont nem igazán fog tudni csökkenni, mivel maga a G-sync modul a komoly FPGA-val később sem lesz sokkal olcsóbb 200 dollárnál, ami elhagyhatatlan extra hardverköltség. Ha pedig eddig nem csináltak rá ASIC-ot, már sanszosan nem is fognak.
-
HSM
félisten
Pár megjegyzés...
"az időtállóbbságot az utóbbi 10 évben egy AMD kártyának sem sikerült bizonyítania (az utolsó ilyen talán a 9800XT volt)"
Közelmúltból jó példa lenne a HD5850. Olyanom volt, 3 éven keresztül mindent vitt maxon, vagy közel maxon, kedvező fogyasztással. (Egy-két játékban kellett kisméretű butítás, nem szerette az extrém tesszelálást és az 1GB videóramra kellett figyelni néhány címnél.) Maximálisan hozta, amit elvárhattam azért az árért időtállóság tekintetében."a Te 7970-ed ellenfele, a GTX680 is pont ugyanannyira jó / nem jó most, mint a 7970"
A GTX680 megfizethető árú változatai egytől egyig 2GB-osak voltak, horror feláron volt a 4GB, még 770-ből is, konkrétan a 780-as olcsóbb volt nála. Namost, a 2GB már egy éve is bukó volt a 7970-el szemben. Másfelől DX12 esetén szvsz sokkal több félnivalója van a GTX680/770-nek, mint egy 7970-nek. Előbbinek a szűkös belső adatutak mellett a 256bites busz szűkösségével is meg kell küzdenie, ami első blikkre sokkal komolyabb gátnak tűnik, mint a 7970 esetén a 2 compute +1 grafikai ütemezőlista.Ami a "G-sync megy neki"-t illeti, nem neki megy, hanem a +200 dolláros kütyünek, amit megvásároltatnak veled a monitor árába építve. Másfelől, ha van egy 144hz-es monitor az asztalon, akár G-sync, akár A-sync, akár bármilyen, azt a 7970 is meg tudja 144hz-en hajtani, és máris alig veszed észre a sima V-syncet is, mivel 17ms helyett már csak 7ms a maximális várakozási idő.
-
HSM
félisten
Mondjuk IPS terén én annyira nem élném bele magam a 144hz-be. Nem vagyok biztos benne, hogy bírnák a jelenlegi panelek. Mondjuk 80hz-et már a jelenlegiek közül is jópár tud, szóval 100hz magassága sanszos mindenképpen. Mondjuk az is már bőven jó szvsz. Akinek az nem elég, annak az IPS lassabb panelje amúgyis bukó lenne.
Remélhetőleg jön majd a 300-as széria is hamarosan... Nagyon várom már a GDC-t, hátha.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Egy Pitcairn frissítés is nagyon kéne a portfólióba a Tonga alá. -
HSM
félisten
Ha azt írja, ma vagy holnap kellene érkezzen, akkor eléggé sanszos, hogy megvásárolható lesz márciusban.
Videókártya van hozzá, a Hawaii/Tonga/Bonaire kapható már egy ideje.
(#9564) Televan: Addig bőven lesz olyanod... Márciusra voltak ígérve, úgy látszik már jönnek is az első fecskék.
-
CsonkaImo
addikt
Értem. Én most egyébként is kihagyom a rajtot. R9 290X-et a második hullámban vettem meg (az első készlet 1 nap alatt elvitték, ha jól emlékszem), amikor megjelentek a custom hűtős példányok. Akkor volt 175K a Tri-X. Nem mondom, hogy megbántam de a régi 7970-emmel még vígan ellennék, így a 290X nagy bukó volt számomra. Mennyit is ér most? 90 ezret?
-
daveoff
veterán
Érdekes amit mondasz, mert pl. a 290X a megjelenés utáni első héten olcsóbb volt, mint a későbbiekben. Lehet akkor is az árfolyam ingadozás miatt lehetett, ezt nem tudom, de így volt. Az első néhány darabot 150-155k-ért meg lehetett venni, utána nem igen volt 160 alatt egy darabig, ha jól emlékszek. Tehát ez az első hét felár nem feltétlenül törvényszerű, de szerintem is 200k felett lesz.
-
HSM
félisten
Szerintem meg egy több okból is mesterségesen lefojtott asztali kártya tulajdonságai nem mérvadóak.
Azért én az ütemezésre a legkevésbé sem mondanám, hogy statikus.
Nyilván az AMD se hülye dedikálni hardvert egyszeri műveletekre. 
Mellesleg az AMD elég jó úton halad az innovációi piacra kényszerítésével. Elég, ha a DX12-t nézed, Mantle nélkül megnézném, hogy állna.
(#9283) proci985: Az FCAT arra készült, hogy a képkockák megjelenítésének egyenletességét mérje, tehát valós frametime-okat, ezt elemzi a szoftver a "színcsíkokkal". Ugyanakkor azt nem méri, mennyi idő telt el az input és a hatására megjelenő output között.
Az elméleti megközelítésed alapján az FCAT egy pontos mérés, de nem azt méri, amit "kell".
Amit a BlurBusterék mértek, és ahogy az egy véleményem szerint jóval kevésbé pontos mérés, de tökéletesen azt méri, amit kell, a valós input lagot a gombnyomástól a kijelzőig.Azért amúgy ha megnézed, elég feltűnő különbség volt itt, BF4-ben 70ms körül volt, mire megjelent valami a képen az inputodból, míg CS:GO alatt 25ms, ha nem számolom bele a G-sync 144hz-es "bugja" miatti 40ms-eket. Szerintem ezen a téren javít a Mantle is nagyon sokat, lejjebb viszi a valós input lagot. Az Anand-os cikk meg is magyarázza, sokan miért nem tapasztalták, hiszen csak gyors egér és gyors monitor mellett lehet igazán érezni ebből bármit is.
-
daveoff
veterán
Végül is elképzelhető, legalább lenyomják az 980 árát, mondjuk már amúgy is érik ott is az árcsökkentés, csak várják a megfelelő löketet. Ha a 390X 180K körül fog itthon nyitni, és nem megint valami kazán lesz, gyenge hűtéssel, akkor jó vételnek ígérkezik, már amennyire lehet jó vételnek nevezni 180-ért egy VGA-t....
-
#9304
Malibutomi
nagyúr
gbors
#9301
Malibutomi
nagyúr
Én arra tippelek hogy ha nem is mindet, de lesz amit megkap lehetöségekhez mérten, bolondok lennének ha nem kapna meg amit lehet. Az új elnevezés számomra komolyabb változásokat sejtet, de ez lehet csak én vagyok.
(#9303) tailor74
A kompakt szerintem csak a 390/x-en lesz azon sem minden. Az én tippem az hogy ha csak beérni tudják a 980-at akkor árban is a 970-980 között lesz a 380/X, a 390/X pedig felette, valahol ott ahol a 290x is indult. -
#9294
Menthirist
veterán
gbors
#9291
-
namaste
tag
Ha az SMM-eknek van kitüntetett ROP/L2/MC egysége, az megbontja az egész rendszer szimmetriáját, főleg az SMM-ek letiltása esetén.
A működés során egy SMM egyforma eséllyel olvashat adatot mindegyik ROP/L2/MC egység felől, ilyen szempontból szimmetrikus.
Meggyőző lenne egy tesztprogram, ami bizonyítaná a priorizált adatutakat.Az NV hétfői válasza hihetően magyarázza a működését, a szombati az valóban mismásolós volt.
-
HSM
félisten
A tranzisztorszintű (+HDL) optimalizálás az AMD-nél is megvan folyamatosan. PL. HDL-ben tudtommal manapság a Tonga a legerősebb GPU, ott tudták a legnagyobb tranzisztorsűrűséget elérni. Ez kapásból fogyasztásra is hat, rövidebb "vezetékek"-->kisebb fogyasztás.
A priorizált adatutak helyett én úgy egyben kezelném, hogy áttervezték az egész memória-szervezését, elérését a GPU-nak. Ennek a fogyasztásra nagyon jó hatása van, kérdés, nem-e fog más területeken kevésbé előnyösen hatni. Ennyire sajnos nem látok bele a GPU-k lelkébe, de az eléggé nyilvánvalónak látszik, hogy így azért kevésbé rugalmas rendszerről beszélünk.Ezt jól látod, én úgy gondolom, hogy a fogyasztás drasztikus csökkentése azonos technológia mellett csak a funkcionalitás megnyirbálásával lehetséges, lásd pl CISC vs RISC architektúrák. Ugyanez volt fordítva a Fermi Cypress esetében, ott a Fermi volt egy nagyobb tudású, bonyolult csip hatalmas fogyasztással, a Cypress pedig egy kisebb, hatékonyabb, de kevésbé robosztus megoldás. Ott konkrétan 3 év alatt sem volt ebből szerencsére semmi gondom, de nem véletlen lépett tovább az AMD egy másmilyen szervezésre. A sors furcsa fintora, hogy most az Nv kezdte el kidobni a fogyasztókat a csipjéből.
"az AMD az újdonságaival az adott generációban szanaszét rúgja a konkurencia seggét. ezt hiányolom 2010 óta."
Itt az a bibi, hogy az AMD nem elég ehhez. Szoftverek is kellenek, ahhoz pedig szoftverfejlesztők. Márpedig a szoftverfejlesztő sem hülye, neki akkor buli az egész, ha Nv-re is el tudja adni a szoftverét. Márpedig ha az AMD-n seggszétrugósan megy, Nv-n pedig döcög, ott a PC-s gamer társadalom legalább fele igencsak zabos lenne, ami nem igazán tenne jót az eladásoknak. Ez némileg meg is magyarázza, miért nem látunk seggszétrúgást, olyan helyeken sem, ahol egyébként láthatnánk, gondolok pl. a Mantle-re. Ettől függetlenül meg kell jegyezzem, a sokak által ledegradált Mantle pl. BF4-ben olyan játékélményt adott, amit réges rég nem tapasztaltam egyetlen DX-es FPS-ben sem.
-
Abu85
HÁZIGAZDA
Miért csak az FPS-ben lehetnek konkrétumok? Ott a folyamatosság, a minimum sebesség, vagy a képminőség. Minimum sebességben láthatod az előnyt: [link], [link] A folyamatosságot ebből ki lehet találni. Aztán ott a Civilization BE. Mantle alatt van SFR több GPU és jobb az élsimítás minősége a fedettségminták miatt. A Sniper Elite 3-ban is jobb minőségűek maradnak a textúrák a stream algoritmus miatt a DX11 módhoz képest.
-
Abu85
HÁZIGAZDA
Az, hogy a GCN-en mindenkinél egy évvel korábban futtatták a Nitroust úgy, hogy nem halt meg RTS módban egy műszaki előny. Ma már a szoftver kéz a kézben jár a hardverrel. Számtalan műszaki előny van még, amely idén fókuszt kap. Például az aszinkron compute/DMA, amik az egyik legfontosabb újítások lesznek, hiszen végre nem kell GPU-limitet kiáltanunk akkor, ha a hardver számítási kapacitásának csak a 20-40%-a van kihasználva, mint ahogy az manapság nagyon jellemző.
A VR nem olyan távoli jövő már. Számtalan szoftveres és hardveres probléma van, amit meg kell oldani, de a GDC-n fel lesz vázolva, ezek jó részére egy-egy GCN-en működő megoldás. Persze a szabványos megoldásokra még várni kell, de az Oculus ezekre már építhet, amikor kiadja az első VR eszközét. -
Abu85
HÁZIGAZDA
Ez tévedés. A kettő nagyon összefügg. A fejlesztők mindig kiválasztanak egy domináns architektúrát, amelyre megéri kutatni. Ez most a GCN, részben a konzolok miatt, részben pedig azért, mert dokumentált és van disassembler is hozzá, és persze nem lehet amellett elmenni szó nélkül, hogy azt a stratégiai szerepet, amit az NV betöltött a G80 időkben, most az AMD tölti be, részben azért, mert az NV elzárkózott.
A kutatások szempontjából ott a StarSwarm, ami először mutatta meg, hogy milyen a magas többletterhelés nélküli jövőkép. Idén lesz egy új példaprogram, ami a GPU-limit megszüntetésére helyezi a hangsúlyt, és ott lesz a VR. Utóbbiról maga az Oculus programozója mondta, hogy az AMD megoldása az etalon. Ezek a váltások három alapra épülnek: tudás, nyíltság és igények kiszolgálása. -
Abu85
HÁZIGAZDA
Nézd meg hova jutottak. Biztos emlékszel még az R600-as időkre, és utána. Az EA, a Square Enix, a Capcom, a SEGA, mind az NVIDIA partnerei voltak. Ma egyik említett cégnek sincs szerződése az NVIDIA-val, és mindegyik cég az AMD-vel fejleszt. És ebből ma mi látszik? Az AMD Gaming Evolveden belül érkezett játékok jól optimalizáltak. Ezzel szemben az NV-nek maradt az Ubisoft és a Warner, mert belőlük az AMD sem kér. Kapott a piac Watch Dogs-ot, AC: Unity-t, most Dying Lightot, amelyek abszolút nem erősítik meg arról a usert, hogy PC-s játékosnak lenni jó.
Az AMD a stratégiájával az összes olyan kiadót maga mellé állította, akik képesek optimalizált PC-s portokat lerakni az asztalra, míg meghagyták az NV-nek a csőcseléket. Mi ez ha nem eredmény? -
HSM
félisten
Mire gondolsz fogyasztáscsökkentő megoldásként, ami nem ment a tudás rovására a Keplerben, Maxwellben?
Én abból indultam ki, hogy olyasmiket tudok (hasznos dolgokat is), amit a GCN tud, és a Maxwell sem, nemhogy az elődei, de olyat nem, amit a Maxwell tudna, de a GCN nem. Persze, rá lehet fogni, hogy úgysincs kihasználva, meg hasonlókat, de azt azért nem árt látni, hogyha be sem épülnek dolgok, akkor nem fog az ipar sem fejlődni.
Nyilván az AMD is kidobhatná a belső buszait, +kidobhatna pár funkciót a GCN-ből, és csinálhatna egy hasonló fogyasztású cuccot, mint a Maxwell, de szerintem ennek pont semmi értelme nem lenne. Az Nv ultramobil irányba indult el, érdekes, hirtelen az asztali GPU-ikba is mennyire fontos lett az energiatakarékosság (insert troll face here), az AMD pedig abba az irányba, hogy hogyan lehetne tovább okosítani, illetve hatékonyabbá tenni a már meglévő architektúráját.Nekem 100X szimpatikusabb az AMD üzleti modellje, stratégiája, persze, el tudom fogadni, ha mások nem így gondolják.
-
Abu85
HÁZIGAZDA
Vegyük a Tahitit. Az első hardver volt, ami támogatta a bindless modellt, az erőforrások korlát nélküli kezelését, a stateless compute képességet, az aszinkron DMA lehetőséget, a PRT-t.
A bindless modellt az NV-nél a GK204 vezette be, míg az aszinkron DMA lehetőséget a GM204.
A PRT főbb képességeit a GK204 részlegesen, míg a GM204 teljesen támogatja.
Az erőforrás-kezelés szempontjából nő limit: SRV: Fermi->Kepler-Maxwell esetében 128->1024768, UAV: Fermi/Kepler/Maxwell1->Maxwell2 esetében 8->64 ... nyilván nem korlát nélküli, de látszik az irány.
Később lesz a konkurensek oldalán is stateless compute, és a többi dolog, amit a GCN bevezetett. Ennek az architektúrának a képességei után mennek a konkurensek és másolják le azokat, részben vagy teljesen. -
HSM
félisten
A preempció nem elsősorban a játékok, inkább a VR miatt fontos, bár nem tartom elképzelhetetlennek, hogy más jellegű dolgokra is hasznos lehessen, pl. számolhat extra procedurális fűszálakat a GPU egy jelenetbe, amíg nem érkezik fontosabb feladat.
A perf / watt az nem fejlettségi, hanem hatékonysági mutató szvsz. Igazad lesz, a Tahiti is DP1.2-es. De ettől függetlenül nem gondolom, hogy ez egy túl nagy update lenne, hogy működjön.Írtam, hogy fogyasztás terén jobb lehetne, de azért közelsem lenne olyan drámai előrelépés, mint amilyennek a HBM ígérkezik.
-
HSM
félisten
Szerintem jó a kifejezés. Pl. a preempció támogatása határozott fejlődés az architektúra szempontjából. Persze, lehet "funkciónak" is csúfolni.
Az A-sync támogatásnál inkább úgy mondanám, újabb verziójú DP kell, amit a GCN1.1-es kártyákba raktak bele. A delta-color cucctól azért én nem estem hanyatt, nyers erőben bőven kompenzálja az 512bites memóriabusz. Persze, nyilván jobb lenne, ha benne lenne, de inkább olcsóbb kártyákban látom ennek fontos szerepét, pl. a Tongában.
Más kérdés, hogy sanszosan jobb fogyasztás/teljesítmény lenne elérhető egy Hawaii-kategóriájú csippel is, ha kicsit kisebb memóribusza lenne kevesebb csippel és delta-colorral, de az egy másik történet...(#9190) stratova: Kérdés, van-e bármi értelme. Valahogy nem igazán lett egy széleskörűen alkalmazott dolog ez a tesszeláció a megvalósítás buktatói miatt.
-
Departed
őstag
Így van, ha nem a fix 60 fps minden játékban a cél FullHD-ban akkor még ma is tökjól el lehet lenni egy négyéves akkori felső kategóriás kártyával, a 6950/70-nel. Ha nem lennének ilyen cserélgetős emberek akik újra meg újra sokat buknak az egyre drágább kártyák vételével akkor végre rá lennének kényszerülve a vga gyártók hogy normális áron valódi fejlődés legyen.
-
Televan74
nagyúr
Akkor én egy "állat" vagyok,mert én évente háromszor veszek új vga -t.És csodálkozom,hogy nem játszom.Mások meg milyen jól megvannak és játszanak az olcsóbb kártyáikkal.Jó lenne már visszalépnem a középkategóriás kártyához, és végre használni azt.És nem valami idillikus álmokat kergetni,dédelgetni.
-
HSM
félisten
Végülis jó cucc volt a Titán, 6GB ram, jó sok nyers erő, főleg kicsit húzva, minőségi és jó cucc volt, csakhát 1000 dollárért? Én a félprofi felhasználásban sem láttam benne túl nagy fantáziát, tisztességes duplapontosságot a konkurens Tahitis Radeonok feleennyiért hoztak. Persze, biztos volt olyan együttállás, amikor az volt a jó termék, dehát na...
-
HSM
félisten
A fuckoff kategória az nálam amúgy a Titan és a Titan Z volt, 1000 meg 3000 USD, WTF?
Én azért most is azt látom, van bőven verseny árban.
(#9027) Televan: 3 év alatt vesztett a VGA-ja 100 000 forintot az értékéből, szerinted ez jó? Szerintem katasztrófa. Bár mindig ez van a csúcskártyákkal. Nekem 60K volt az 5850-es radeonom, amit 3 évvel később 25K-ért el tudtam adni, na az normális. Így +50K-ért kaptam akkoriban egy vatta új 7950-et, összesen 75K-ért, ami még ma is, 2 évvel később is megérne még 40-50K-t. Ezek normális értékvesztések, de 100 000K 3 év alatt, az nagyon nem.
(#9029) Departed: 300 dollárért már 290X-et adnak, 250-ért meg sima 290-et, mint annak idején a 4850 nyitóára. Ez hol nem versenyképes?
-
Departed
őstag
Köszönjük hogy leírtad, nagyon tanulságos.
Manapság divat a forintot okolni mindenért, pedig ahogy leírtad, 7970-től elszálltak az AMD árai is. Eredmény: azóta nem is vettem tőlük kártyát, inkább elvagyok a mostanival. Remélem másokat is befolyásolja ez az elbaltázott döntés és remélem alaposan lecsökkentek az eladások. -
Abu85
HÁZIGAZDA
A DX12 nem akar annyira mélyre menni. Bár alacsony szintű API, de inkább a Metal és a Mantle közötti absztrakcióval rendelkezik. Bizonyos legacy funkciókat próbálnak átmenteni és így pár területen kompromisszumra van szükség. Például a friss Win 10 érkezésével kiderült, hogy a memória menedzsmentje nem teljesen explicit. Nagyrészt az, de bizonyos pufferek fölött a WDDM fog babáskodni. Ez megnehezíti az explicit GPU menedzsmentet is. Nyilván nem lehetetlen, de nem olyan egyszerű, mint mondjuk az AMD API-jánál. Kell pár kiegészítés az API-ba is.
-
HSM
félisten
Nem vagyok teljesen benne ezekben a fizikás dolgokban, de a PhysX el nem terjedésének azért voltak tudtommal más okai is fejlesztői oldalról. Pl. a szándékosan egyszálúra hagyott CPU-s mód, illetve a GPU-kon is csak bizonyos eye-candy effektekre való alkalmazhatósága. Ugyanis míg a régi PhysX kártya teljesértékű gyorsító volt, addig tudomásom szerint a GPU-s megoldás nem az. Ezek együttesen terelték emlékeim szerint a fejlesztőket más fizikai motorok mellé.
-
HSM
félisten
Óriási különbség a Mantle és a PhysX között, hogy az előbbi nyílt, míg az utóbbi zárt szabvány. Másfelől az egyik az egy óriási, évek óta létező, valós problémát olda meg, míg a másik kb. csak egy jópofa szem-kényeztető, egy teljesen nélkülözhető csomag.
A GTX480 egyébként szvsz elég jó cucc volt, a fogyasztását, hőtermelését leszámítva.
Mondjuk a GTX580-ra már egész emészthetőre kigyúrták, és jó hűtést is kapott. -
7time
senior tag
hogy a 200-as lineup fele feature téren elavult kártyákból áll...
Az Nvidia is volt hasonló helyzetben nem is 1x, most az AMD van ez nem egy tragédia a cég helyzete pedig olyan mértékben érdekel hogy legyen konkurencia és olcsón vegyek VGA-t, jelenleg ha ínovációról van szó az Nvidia az aki hátráltatja mert használhatna mindenki Mantle API-t ami sokkal jobb mint a DX de ebbe most nincs időm, kedvem belefolyni.
Az a leg viccesebb mikor Nvidia fanok szólják meg durván a pirosakat hogy milyen hülyeség egy cég termékei mellett kitartani de a Fermi is fogyasztott 420W amikor az AMD 350 -et. -
Abu85
HÁZIGAZDA
Lehet, hogy félreértjük egymást. Tisztázzuk azt, hogy a DX11 pipeline modellje megváltozik. Tehát a különálló pipeline modell eltűnik, vagyis nem úgy működik majd a DX12, hogy a lépcsőkhöz (legyen az shader vagy fixfunkciós) hozzá kell rendelni egy hardver állapotot. Ehelyett lesznek a PSO-k. Maga a futószalag állapotobjektumként lesz reprezentálva, tehát a futószalag lépcsői be lesznek vonva egy objektum alá, amelyek a létrehozásuk után megváltoztathatatlanok. Ezt főleg azért vezette be az MS, mert a hardverek bizonyos DX11-ben még megkülönböztetett állapotokat az eszközszinten valójában egységes állapot alatt kezelnek. Tehát közelebb került az API működése a hardverhez és a sok többletterheléstől is mentesülünk. Ugyanakkor maga a DX12 még mindig megkülönbözteti a vertex, pixel, geometry, akármi shader lépcsőket. Ezeknek megvan a maguk szabályozása, hogy milyen erőforrásokhoz férhetnek hozzá, stb. Ebből a szempontból a Sony PS4 és az AMD saját API-ja másképp működik, mert ott igazából a vertex, pixel, geometry bár logikailag megkülönböztethető, de mindegyik shader ugyanarra képes, ugyanazokhoz az erőforrásokhoz férhet hozzá. Tehát nincs olyan, hogy a vertex shader nem írhat xy bufferbe, ha a fejlesztő írni akar oda, hát akkor írjon.
Arról nincs szó az eddigi leírásokban, hogy a tesszellációs lépcsők a DX12-ben kivághatók lennének. A PS4-en és az AMD API-ján biztosan azok. De igazából már a DX12 PSO is ad arra lehetőséget, hogy olyan formában optimalizálj, ami korábban nem volt lehetséges. Például, ha egy vertex shaderben számolt értékre később biztos nem lesz szükség, akkor az kiszűrhető, és nem kell, hogy a futószalag többi elemét tovább terhelje. Ebből a szempontból a PSO is lényeges előrelépés a DX11-hez képest.
-
Abu85
HÁZIGAZDA
Senki sem a compute shadert bírálja, amikor a bajokról beszél. Sőt, ez a shader lépcső segít abban, hogy begyorsítsák a programot. Az egyetlen fejlesztés, aminek igazából haszna volt a DX11-ben. Ellenben jött még számtalan újítás. Például a deferred context, amit mindenki, ezen belül ma már maga a Microsoft is rossz megoldásnak tart.
Az eddigi pipeline nem fog lebomlani a DX12-vel. A Microsoft csak az Xbox One-on engedi meg az egyszerűsített erőforrás-kezelést, ami minden shader lépcsőt egységesnek tekint.
-
Abu85
HÁZIGAZDA
Te is pontosan tudod, hogy a programfejlesztés elmélete mennyiben különbözik a gyakorlattól. És itt jön elő az anyagiak problémája. Természetesen az egész levezethető egy elméleti alapon, hogy bizonyos, alapvető optimalizálással nem elérhető, de igazából szabad erőforrások hozzáférése mennyi munkaórát, pénzt, programozót igényel. Erre bárki képes, aki tapasztalt a modern játékfejlesztésben. És mivel jutunk előrébb, akkor, ha kiderül, hogy tudnak +10%-nyi erőforrást nyerni, ha még egy évet optimalizálnak? Maximum az EA engedheti meg magának, hogy erre pénzt áldozzanak, mert őszintén szólva +10%-ért baromira nem éri meg belekezdeni.
Ha a Nitrousból való ábrákat felhoztad, akkor érdemes kiemelni, hogy ez egy három éves fejlesztés. Három év alatt jutott el oda a motor, hogy DX alatt az erőforrásokat úgy kihasználja, ahogy a képen van. Ezzel szemben a Mantle erőforrás-kihasználása hat hetes munka eredménye volt akkor. Tehát mit is várunk tőlük? Hány évet öljenek még bele az optimalizálásba? Ha egy kiadó lenne a hátuk mögött, aki időpontra kérné a programot, még ilyen kihasználást sem érhettek volna el, mert nem engedték volna őket három évig dolgozni. Egyedül Brad Wardell fanatizmusának köszönhetik, hogy minderre meglett az anyagi lehetőségük. Valljuk be a mai világban nem sok Brad Wardell szaladgál, inkább Bobby Kotick kaliberű cégvezetők vannak a szoftveriparban. És amíg ez az egész egy nagy üzlet lesz, addig nem fog ez a felállás megváltozni. Bobby Kotick is azt fogja nézni, hogy a low-level kóddal ötödannyi erőforrást sem kell befektetnie, kellenek a halálnak a pénznyelő API-k. Mostantól még olcsóbb lehet a következő Call of Duty, hurrá.Nem kell ahhoz várni, hogy meglásd mennyit fog fejlődni az AI. Csak elő kell kapni pár konzol exkluzív játékot. Ezeknél már rég túlléptek a PC-s szinten.
-
Abu85
HÁZIGAZDA
Pont ez a baj, amit leírsz. A driver önmagában nem félelmetesen sok processzoridőt, viszont a kiszámíthatatlan működésével hozzáférhetetlenné teszi azt. Ha optimális lenne a driver processzorkihasználása, akkor nem kellenének új API-k, mert elveszi magának az erőforrást, és amit nem használ az csak úgy elérhető lenne. Mindenki boldog lenne egy ilyen modellel, csak nem ez történik, hanem elveszi az erőforrást és ennek következményeként hozzáférhetetlenné tesz még egy csomó processzoridőt, amin valóban kimutathatóan nem csinál semmit, csak ettől még ez a processzoridő nem lesz elérhető a programnak. Lásd a korábbi slide-ok.
Maga a rendszer black box jellege kiszámíthatatlanná teszi az egész feldolgozást, programozóként nem leszel ura a hardvernek, és így pedig borzasztóan nehéz elvárni a stúdióktól, hogy újítsanak.
-
HSM
félisten
Én nem látok itt ellentmondást. Ott az erőforrás, de nem tudod használni, mert összeakadsz a driverrel és rossz lesz az eredmény.
Tehát a driver elveszi az erőforrást, hiszen fenn kell neki tartani, tehát nem férsz hozzá, nem tudod használni.
Tehát a jelenlegi modell rossz hatékonyságú emiatt. Ráadásul ott van még az API overhead-je is. -
Abu85
HÁZIGAZDA
Az erőforrás tényleges elzárásához nagyon ritkán nyúlnak a mai driverek. Profil nélküli játéknál nem is alkalmazzák.
De az elzárás nem is szükséges ahhoz, hogy gond legyen. Önmagában az is baj, hogy a driver feladatai szimplán futnak a program mellett. 2006-ban már készültek olyan driverek, amelyek 2 szálat is futtattak és ma az 5-7 szál az általános. A fejlesztőknek ezzel az a baja, hogy ha még nem is zárják el az erőforrást, akkor is összeakadnak a programszálakkal, és a driver annyira feketedoboz jellegű rendszer, hogy semmilyen lehetőség nincs a működését normális keretek között kontrollálni.
Ezért alakult ki az az igény az új API-knál, hogy ne legyen kernel driver. A DX12-ben ugyan lesz, de az csak egy fail-safe dolog, vagyis csak azt biztosítja, hogy a program lefagyásától ne fagyjon le az operációs rendszer. Valójában nem fog erőforrást elvenni, mert tényleges számítást nem csinál majd. -
-
letepem
aktív tag
Szerinted az nem válasz, ha leírja Abu, hogy mamár nem csak a dx működése és a program futtatása emészt fel erőforrást, hanem a növekvő kritériumok miatt még az aggresszív driver működése is? Valamint dx működéséből fakadóan a fejlesztő nem is látja a rendszer egészét rgo meg van kötve a keze! Emiatt választani kell, hogy az eyecandy grafikát választod, ami messzemenően túlnyúl a jelenlegi dx működésén vagy megtartod a szuper játékmenetet és ai-t. Gondolom észrevetted merre mentek el a stúdiók.
Nekem ez jött le a mondanivalóból, a piti személyeskedést pedig inkább felejtsük el! Köszi! -
Abu85
HÁZIGAZDA
Akkor itt a félreértés. A deferred context nem feltétlenül kell a többszálúsításhoz, az csak a parancslistát kreálja több szálon, de a beírást már amúgy is egy szálon végzi. Az immediate context manuális többszálúsítással jobb eredményekre képes, és innentől kezdve az egész probléma megszületik, mert a kezdetektől ezt az irányt választották a fejlesztők, ehhez még DX11 sem kellett. A DC csak egy alternatíva volt, ami nem működött végül. Viszont a driverek már 2006-ban több szálon működtek, tehát az erőforrást elvették.
Igazából a low-level API-k előnye nem is feltétlenül a többszálú modell megújítása, az is nagyon jó, de a legfőbb előny az, hogy a grafikus kernel driver nem futtat szerver szálakat a programszálak mellett, így az erőforrást sem veszi el. -
Abu85
HÁZIGAZDA
De volt rengeteg előrelépés. Csak nem PC-n. Ez a fontos. A PlayStation 3-on pár exkluzív címben sokkal jobb AI van, mint ami PC-n valaha is létezett. Ezzel példálóznak a fejlesztők évek óta. Nem tudják igénybe venni az elméletben létező erőforrást, ha gyakorlatban nem érhető el, és ezért ma egységesen a DX API, jelenleg DX11 van hibáztatva. Aztán ezt vagy elhisszük nekik vagy sem, de tény, hogy a PS3 és Xbox 360 exkluzív játékokban valamiért tudnak jobb AI-t csinálni, míg PC-n nem.
-
Abu85
HÁZIGAZDA
Én igazából azt nem értem, hogy a problémán mit nem lehet érteni. Kiindultunk abból, hogy a FEAR AI-jához képest a mai PC-s játékok AI-ja hasonló szintű. Ezt a fejlesztők azzal magyarázzák, hogy a DX11 nem teszi lehetővé, hogy a processzoridőnek a nagy részét kihasználják. A konzolon ott az Uncharted 3 sokkal jobb AI-val, amivel a FEAR rendelkezett. Ott tehát működik a dolog. Mi az oka annak, hogy számos bizonyítékkal a hátuk mögött nem hisszük el a fejlesztőknek, hogy nem ők a bénák, hanem tényleg a rendszer dolgozik ellenük PC-n? Még ha egy fejlesztő lenne, aki az ellenkezőjét mondja, de nem, mindenki szerint rossz az a programozási paradigma, amit a DX11 rájuk kényszerít.
-
Abu85
HÁZIGAZDA
A driver mindig igényelt erőforrást a működéshez. Másképp aligha tudná ellátni a feladatait, a baj, hogy egyre több kell neki. Viszont ennek nem kellene úgy lennie, hogy erőltessük a DX11 határain túllépő PC-s grafikát. Elfogadhatnánk azt is, hogy ebben annyi van amennyi, és akkor lenne erőforrás a gameplay szimulációra. Viszont ezt nem fogadtuk el, és ennek az a következménye, hogy a fejlesztőknek nincs több erőforrásuk a programra, mint sok éve.
De mondhatjuk azt, hogy a fejlesztők szimplán bénák DX11-ben, a Microsoft is csak félrebeszél, amikor nem ajánlja a deferred contextet, és a Mantle is csak azért működik, mert annak a 3000-4000 soros kódnak a beírását a fejlesztők tehetségesebb "skizofrén" énjük hozta össze. -
Abu85
HÁZIGAZDA
Melyik erőforrásért? Amit a driverek elvesznek? Szapulhatjuk a fejlesztőket, de valójában a többszálú feldolgozásra van egy olyan rendszerük a DX11-ben, amit ma már a Microsoft sem ajánl használatra, mert káros hatásai vannak. A problémára az elvi megoldás valóban a deferred context, ami viszont a gyakorlatban a programfejlesztők és a Microsoft szerint sem működik. Érteném a logikát, amit írsz, ha valaki azt mondaná, hogy márpedig ez működik csak ki kell nyújtani a "kezet", de nem. Ilyet még soha senki sem mondott. De olyat már sokan mondtak, hogy: nézzétek, a konzolon ki tudjuk nyújtani a kezünket! És 2014-ben ki lett kiáltva bűnösnek az API, így kaptunk négy új low-level API-t, vagy egy részükre bejelentést, hogy készülnek.
-
Abu85
HÁZIGAZDA
#1 2007-ben kezdtek el normálisan terjedni a többmagos procik. Elsősorban kétmagosok. Viszont a program nem jutott több erőforráshoz ezekkel sem.
#2 2010 után annyi változott, hogy a grafika fejlődött, és a DX túl lett terhelve, tehát olyan driverek kellettek, amelyek a 2010 utáni grafikát is megjelenítik, vagyis még több erőforrást elvettek a programtól. Ez a folyamat tart máig. Összességében nincs több processzoridő a szimulációra, mint régen.Két tény: a fejlesztők azt mondják, hogy a probléma az API. A Microsoft nem konkrétan a DX11-et látja gondnak, hanem azt, hogy a fejlesztők túlterhelik, és a gyártók ehhez igazodnak a driverekkel. Ez is bőven igaz. Az API tud valamit, és ahhoz lehet butítani a grafikát, de ezt fentebb megbeszéltük, hogy miért nem jó a PC-s gyártóknak.
-
Abu85
HÁZIGAZDA
Akkor sem szartak rá, de nem nehéz meglátni az időpontok összefüggéseit. A FEAR 2005-ös. Tekintsük úgy, hogy ahhoz hasonló AI van a mai PC-s játékokban is (most ne számítsuk a picit jobb-picit rosszabb dolgokat, a konzolt meg pláne, mert ott jelentősen jobb AI is létezik). Ha Daniel Baker API-s előadásait megtekinted (amit ajánlok, mert ő az egyetlen játékfejlesztő, aki GAB tag, és iszonyatosan nagy rálátása van az egészre, hiszen ő maga is részt vesz a DirectX fejlesztésében), akkor láthatod, hogy szinte mindig elmondja a saját hipotézisét, hogy szerinte mi csúszott félre. Ezt az alábbi ábrán jól prezentálja:
Ugye a narancs a GPU-k teljesítménye a GFLOPS oszlophoz mérve. A piros a batch teljesítmény a Batch/Frame oszlophoz mérve, ami a driverekből jön/jött, míg a szaggatott vonal a terv, ami nem jött be.
És az egész pont az általad megjelölt 2007-2008 körül kezdődött, amikor a több mag elkezdett terjedni.
És itt tartunk most:
Az a kis kék rész maga a program, és az elméleti processzoridő pár százalékán fut, a maradék "Unused CPU Time" pedig azért van piros csíkokkal lesatírozva, mert nem lehet hozzáférni. A DirectX 11 és az API-hoz készült mai modern driverek nem teszik elérhetővé. Programozóként láthatod a profilozóban, de nincs semmilyen mód, hogy hozzányúlj ehhez az elméletben szabad processzoridőhöz.
Ezek után mondhatjuk azt, hogy a fejlesztők a bénák, és ezért nincs fejlődés, de valójában igazságtalanok vagyunk velük, mert ők a DX11-gyel jelenleg egy olyan programozási modellre kényszerülnek, amellyel az elméletben elérhető erőforrások nagy része elérhetetlen.
Ezt Daniel Baker bizonyította az alábbi képpel, hogy ne csak a levegőbe beszéljen:
Látható, hogy egy alpha kóddal is képes használatba venni az elméletben elérhető processzoridő ~50%-át, de ehhez nem a DX11-et, hanem a Mantle-t használta. Ezzel bebizonyította, amit sokan sejtettek, hogy a probléma forrása a DX11 és a hozzá tartozó modern driverek.
És amikor a lustaságról beszélünk, akkor vegyük figyelembe, hogy Daniel Baker már elérte a 85%-os kihasználást is az új motorverziókkal, ugyanis zölddel van jelölve az az "Unused CPU Time" rész a képen, vagyis optimalizálással a gyakorlatban is hozzáférhető, és a nagy részét már hasznosította is. Nehéz azt mondani rá, hogy lustaság miatt nem csinálja ezt meg a DX11 alatt. Főleg úgy, hogy a Nitrous, vagyis a saját motorja sokkal hatékonyabban működik DX11 alatt, mint akármelyik más fejlesztő motorja. Kvázi ő az egyetlen programozó a világon, aki nagymértékben optimalizál DX11-re. -
Abu85
HÁZIGAZDA
Erről beszélnek kb. jó ideje a fejlesztők. Hiába nő a teljesítmény, ha ahhoz nem lehet hozzányúlni, mert valami megakadályozza. A DX API akadályozza meg ezt alapból, de ez a probléma többszintű, mert a DX API nem lenne annyira korlátozó tényező, ha a mai grafikus driverek úgy működnének, mint három éve, csak akkor meg a grafikát kellene lebutítani. Régebben nem igazán törődtek azzal a fejlesztők, hogy mik a grafikus driver igényei. Ma ezek annyira máshogy működnek, hogy követni kell a gyártók ajánlásait, mert más irányból megközelítve rossz lesz az eredmény. Főleg az NVIDIA ajánlásait érdemes követni, mert a GeForce driver nagyon agresszívan kisajátítja az erőforrást, így ha DC mellett nem kap három, illetve IC mellett kettő magot, amihez a program onnantól kezdve hozzá sem nyúl, akkor sok esetben káros lesz a sebességre és a stabilitásra a driver működése. Persze ezt nem minden modern motor követi, például a Frostbite 3 csak egy magot ad a drivereknek, és azért éri el így is azt a jó teljesítményt, amit tud, mert minden lehetséges módon megakadályozza a drivert abban, hogy elvégezze a feladatának egy részét. Azt a részét, amelyet amúgy a Frostbite már elvégzett, tehát felesleges lenne még egyszer erőforrást pazarolni rá. A Frostbite 3 ma az egyetlen motor, amely például DX11 alatt az állapotváltások szűrését csak egyszer futtatja, és azután a rendszer elzárja az adatokat a DX API és a driver elől, hogy az a programszál, amely arra létrejött ne futtasson több szűrést ezeken. A driver szimplán várakozásra van kényszerítve, és addig vár az adatra, amíg a program fut. Nem elegáns megoldás, mert ez a várakozás programfagyást eredményezhet (sőt egyszer biztosan fagyni fog, de kb. 20 óra után, ameddig nem sok ember játszik egyhuzamban). A BF4-nél vagy a PvsZ:GW-nél a DX11-es kód igen sokáig bírja anélkül, hogy a Frostbite 3 driver működését akadályozó modulja device hung hibát eredményezne, amivel ugye kilépne a program. A DA Inquisition az ellenpélda. Ott DX11 alatt sajnos igen sűrű a fagyás. Jelenleg 15% az esélye, hogy a program egy óra játék után device hungot dob és kilép. Ezen nagyon dolgoznak a fejlesztők, mert ez sokkal rosszabb arány, mint ahogy a korábbi játékok működtek, igaz azok nem a legújabb Frostbite 3-at kapták meg.
Felelősöket nem érdemes keresni, mert a probléma többszintű. A legtöbb fejlesztő az új grafikus driverek agresszív erőforrásigényét nevezik meg problémaként, de valójában az, hogy ma öt-hét szálat simán futtat egy driver annak az eredménye, hogy a DX11 2000 batch/frame-es limitjét nem teljesítik a fejlesztők, tehát az NV-nek és az AMD-nek sincs igazából sok választása, valamilyen módon meg kell oldani, hogy meglegyen a 3000-5000 batch/frame-re is a teljesítmény. Nehéz azt mondani a fejlesztőknek, hogy márpedig butítsátok le úgy a PC-s port grafikáját, hogy beférjen a DX11 limitjébe. Saját maguknak ásnák a sírt, ha ezt mondanák a PC-ből élő gyártók, mert a konzolon ezt nem kell megtenni. Szóval a probléma alapja egyértelműen a DX11, amely képtelen kompromisszumok nélkül kiszolgálni a fejlesztők igényeit.
Jelenleg nagyjából három opció van a fejlesztők előtt DX11-re:
- betartani a DX11 limitjeit, így maga az API optimálisan működik, tehát viszonylag sok erőforrás marad a szimulációra, de cserébe a grafikát a konzolos szint alá kell belőni
- túllépni a DX11 limitjeit, így a drivernek rengeteg magot adni, hogy egyáltalán optimálisan működjön, azaz hozható legyen a konzolos grafikai szint, cserébe a szimulációra nem lesz több erőforrásod, mint amennyi tíz éve rendelkezésre állt, sőt, lehet, hogy kevesebbel kell kalkulálni
- kidolgozni egy olyan rendszert a motorba, amely nem engedi a grafikus drivert működni, így sokkal optimálisabban lehet a hardver kihasználása és grafikai butítás nélkül is lehetőség lesz több erőforrást kinyerni a szimulációra, cserébe nem lesz stabil a program, illetve egy ilyen rendszert csak a leggazdagabb fejlesztők engedhetnek meg maguknak, mert extrém mértékű tesztelést igényel
És igen, az utolsó pontot fel lehet úgy fogni, hogy csak pénz kérdése a dolog, de valójában cseppet sem optimális az, hogy meghúzol egy határt, hogy mennyi potenciális fagyást tekintesz még elfogadhatónak. Hidd el pont annyira káros a PC-s játékosoknak, hogy DX11-ben 15% az esélye annak, hogy az új Dragon Age lefagy egy óra alatt, mintha lebutították volna a grafikát. -
Abu85
HÁZIGAZDA
PH-nak.
Egyébként csak egy példa: Kevin Floyer-Lea - sok mántlis szöveg ... stb ... de a lényeg:
- ...
- Scope for increasing scene and world complexity
- Ability to increase the CPU budget for other systems like AIThe last two points are more relevant to our future games, ...
Tehát jelenleg a Rebellion, független stúdióként is elkezdte kutatni a jobb AI és jelenetkomplexitást, amire mostantól lehetőségük van.
Egyébként a FEAR pont jó példa. Annál komplexebb AI-t PC-be nem igazán implementált játék, rosszabbat vagy közel hasonlót kaptunk, tehát lényegesen jobbat nem. És a FEAR 2005-ben jelent meg. Azóta kvázi nincs előrelépés, és nem a hardverekkel van baj, mert azok gyorsulnak, csak nincs lehetőség ezt az erőt befogni. És persze ebben benne van, hogy a DX11-nek a többszálúsítása az MS szerint is rossz, illetve nagy egészében vizsgálva az elmúlt nagyjából egy évtizedben a potenciális megoldások sorra elvéreztek a gyakorlatban. Ezért látjuk most a radikális megoldások előretörését, mint például az AMD és az Apple low-level API-ja.
Viszont azt távolról sem lehet mondani, hogy a FEAR viszi az AI-ban a csúcsot. A PC-ből kilépve ott a PS3, aminek van Uncharted szériája, ahol a 2-3. részben például iszonyatosan látszik, hogy az AI csapatban dolgozik, bekerítenek, amíg páran folyamatosan tüzelnek. Visszadobják a gránátjaidat, és nem mindig rád, hanem esetleg a környezetre, hogy az rád omoljon. Megsemmisítik rakétával vagy gránáttal a potenciális fedezéket. Folyamatosan zárótűzben tartják az előnyös helyeket, hogy ne juss el oda. Tehát nem a programozók bénák, van lehetőség jó AI-ra, ha hozzátudsz nyúlni a gép erőforrásaihoz.
-
HSM
félisten
Én azért ezt nem így gondolom.
Az AI is azért fejlődgetett az utóbbi években és a fizika is. Pl. a BF4-ben is elég komoly a rombolható környezeti elemek, ilyen azért korábban nem sok volt... A fizika is fejlődő pályán van. A mai napig ott figyelnek pl. bizonyos játékokban a PhysX effektek, amik bár annyit nem érnek, hogy Nv-t vegyek, de igen szép dolgokra lehet felhasználni jó sok év óta, és fel is használják.(#8637) Abu85: Igen, pontosan így látom én is.
Jut eszembe a gameplay dolgok vs CPU témáról, a TrueAudio-ról mi hír a fejlesztők oldaláról? -
Abu85
HÁZIGAZDA
Nyilván van egy törekvés arra, hogy a lehető legjobban biztosítsd a szoftvert megvásárló rétegnek.
Az AI-ra és a fizikára nem tettünk magasról, csak nincs esély komplexebb számításra. Egyrészt lassú a processzorok fejlődése, másrészt a driverek egyre több processzoridőt igényelnek, hogy értékelhető sebességű legyen a megjelenítés. Tehát az elérhető processzoridő szempontjából effektíve évek óta nincs nagyobb teljesítmény a gameplay elemekre, sőt konkrétan romlik a helyzet. Eközben a kutatások futnak, bár nyilván csökkentett kiadások mellett, hiszen úgy sem lehet beépíteni az eredményüket.
-
Abu85
HÁZIGAZDA
Azt is tudják a fejlesztők, csak a 285 túl új termék. Viszont arra állandóan panaszkodnak, hogy a mai gépvásárlási norma eltolódott a VGA-k felé. A fejlesztők összevont statisztikát is kérhetnek, és abból látszik, hogy akinek drága CPU-ja van az többnyire olcsó, illetve akinek olcsó CPU-ja van az többnyire drága VGA-t használ. Nagyon kevés a kiegyensúlyozott gép. Abszolút nem igaz az a norma a valóságban, hogy a drága VGA-k mellett drága proci van. Ez egy éve még rosszabb, mert az USA-ban elterjedőben van az a tévhit, hogy a konzolban gyenge proci van, és erős a GPU, tehát a PC-be elég a legolcsóbb proci, hogy minél több pénz maradjon a GPU-ra. És nem tudod megmagyarázni egy átlagembernek, hogy a konzolt máshogy programozzák.
-
HSM
félisten
Igenám, de az Intel vezérlőit leszámítva kellően kiforrottak a mai architektúrák alapjaiban, ilyen téren drasztikus változásokra nem számítok, persze, ettől lehetnek. De ha annyira más cuccok jönnének, akkor ott más API-kkal is lehetnének gondok.
Vész esetére pedig lehetnek alternatív renderelési módok.A második bekezdésben erre próbáltam reagálni: "sure, elvi síkon szép, hogy pusztán szoftveres úton a legolcsóbb CPU-k is alkalmasak játékra, thanks to AMD...."
-
HSM
félisten
A low level API-k esetében ez az architektúrára optimlizálás nem tűnik akkora érvágásnak, mint amennyit nyerni lehet vele. Meglássuk, majd mi sül ki belőle.
Azt felejted ki az érvelésedből, mennyi mindent csinálhatna az erősebb CPU is a felszabaduló CPU-időben. Gondolok itt komolyabb fizikára, AI-ra, csomó mindenre lehetne használni. De nem lehet, mert a DX esetére meg szabadon kell hagyni.
-
Abu85
HÁZIGAZDA
Elmondom, hogy a Square Enix Steames felmérése szerint a Thiefet megvásárló személyek 72%-ának van az enyémnél gyengébb processzora. Sarokeset lenne tehát? Maximum egy szűk rétegnek, akik azt hiszik, hogy mert megengedhetik maguknak az erős négymagosokat a világ nagy része is ezt fogja venni. A statisztika viszont nagyon jól jön a fejlesztőknek, mert a Steam megmondja, hogy ki milyen gépet használ.
Takarékra van véve a render. Az a gond, hogy a drivert nem akarják befolyásolni, mert úgy járnak, mint az EA. Le fog fagyni a program, ahogy a Dragon Age is fagy DX11 alatt. Ez rosszabb, mint a kávészünetnyi lépésidő. Ezért mondják azt ezek a fejlesztők, hogy a DX11 nagyon rossz API, mert kompromisszumra kényszerít.
-
Abu85
HÁZIGAZDA
De mi a probléma ezekkel a CPU-kkal? A teljesítményük egy normális, hangsúlyozom normális API-val nem limitált. Nem a hardver a rossz, hanem a DirectX 11! Ma azért fizetsz, mert tíz éve képtelen a Microsoft összehozni egy olyan API-t, ami nem pazarolja el az elérhető erőforrás 90%-át.
Az a baj a driverrel, hogy borzalmasan rosszul működik a virtuális szálakkal. Azért nem javasolják ma a minimum gépigényeknél az i3-at, mert a grafikus drivernek nem jó a Hyper-Threading. Ez persze nem a hardver hibája, hanem a DirectX 11 kényszerít a fejlesztőkre egy rossz programozási modellt. És egyszerű innen azt mondani, hogy változtassanak rajta, de a Civ6 azért olyan amilyen, mert a rendkívül rossz kialakítású szoftveres réteg mellett ez a valóban nevetséges működési mód a legjobb.
-
Abu85
HÁZIGAZDA
Más, hasonló teljesítményű CPU-val is így viselkedik. Athlon 5350-en is kipróbáltam, amivel DX11-ben csak 13-15 fps-t kaptam, de az AMD API-jával maradt 40 fps körül.
Sajnos a mai driverek nem úgy működnek, mint a régebbiek. A Civ5-höz képest számos korlátozást kapott a Civ6. A mai driverek ahhoz, hogy elfogadható teljesítményt nyújtsanak nagyon agresszívek többszálú optimalizálásokat kaptak, ami azt eredményezi, hogy kíméletlenül elveszik a processzoridőt az alkalmazástól. Ma az az optimális, ha a legalább három magot kap a driver (ez az NV előírása, és az AMD is hajlik efelé). Ezért is ajánlanak ma minimum 4 magot a friss játékoknak, de inkább 5-6 kell. Így lesz a legjobb az általános folyamatosság. Persze a minimumok nagyon esni fognak, de a DX11 ma a kompromisszumról szól.
-
HSM
félisten
Én a jelenről beszélek elsősorban... 3 éve jelent meg a Tahiti, DX12 Tier 3 azaz full tudással. Ehhez képest, az Nv a mai napig nem képes ezt nyújtani a legfrisebb Maxwell csipjeivel sem. Sőt, még dokumentációjuk sincs.
Korábban, ahogy jöttek az okosabb hardverek, jöttek hozzá az okosabb API-k is rövid időn belül. Ez most megszakadt, ugyanis az egyik játékos a kvázi kétszereplős piacon nem igazán akarta tudásban követni a másikat, így semmi kényszer nem volt a Microsofton, se senkin. A játékfejlesztőknek pedig évekig együtt kellett élni a DX11 nyűgjeivel, amit mára már nagyon kinőttek a nagyobb koponyák. Gondolj bele, olyan talán még sosem volt, hogy ott legyen a HW-ben a tudás (GCN, ahogy mondtad korábban, "túl okos"), amit a mai napig nem lehet DX alól kb. semennyire kihasználni, és legkorábban a kiadás után 4 évvel lesz hozzá alkalmas API, a DX12....
Ha az Nv is meglépte volna már a Keplernél, hogy okosabb csipet tesz le az asztalra, már rég előrébb járhatna ez az egész API-s történet és a PC játékok az én véleményem szerint. -
Abu85
HÁZIGAZDA
Sajnos leesik. GTX 770-nel sem volt több, mint az R9 285-tel. Ez egy API limitáció. Nem tudsz ellene mit tenni.
Dragon Age nehezebb ügy, mert ott van valami programhiba. Már jeleztem a Bioware-nek, hogy ledobja magáról a hardver. Írták, hogy tudnak róla, de jelenleg nem teljesen stabil a DX mód. Azt mondjuk aláírom, hogy ez nem a gyártók hibája.
Nem veszek csak azért gyorsabb processzort, hogy teljesen felesleges számításokat végezhessen el egy elavult API.A Civ6 DX alatt az AI egy szálon számolja. Ráadásul négymagos procin azon a szálon, amelyiken renderel, mivel a másik három mag a driveré. Az AMD API-ján minden szálat igénybe vesz. DX alatt is próbálkoztak a többszálú optimalizálással, de csak lassabb lett, így végül maradt az egyszálú számításkorlátozás.
-
Abu85
HÁZIGAZDA
Mert nem próbáltad ki sosem élesben. Én nem tudnék játszani a Thiefen 18 fps-sel, vagy a Dragon Age Inquisitionnel 12 fps-sel DX11 alatt, miközben ezekben a játékokban az AMD API-jával rendre 42 és 37 fps-sel játszok ugyanolyan beállítással. Ez olyan oltári bizonyíték a működésére, hogy konkrétan kiüti a falat.
És a valóság az, hogy a tömegek által használt PC-k közelebb vannak az én gépemhez, mint a tesztekben használt 4,5 GHz-re tuningolt processzorral dolgozó konfigokhoz.A Civilization 6-ban egy picit más hatása van. Ott is nő a sebesség, de ami érezhetően változik az a körváltás, amikor már a világ nagy részét felfedezted. DX alatt sokszor 2-4 percig számolja az AI a lépését. Az AMD API-jával 10-20 másodperc maximum. Ez egy óriási előny számomra, mert nem zökkent ki a játékból.
-
HSM
félisten
A DX10.1 volt az utolsó komoly upgrade DX szinten. A DX11 meg úgy beragadt, mint a huzat. Miért fejlesztettek volna, ha az Nv a DX11-et se hozza a VGA piaci igen komoly részesedésével? Ha a Mantle nem jön, sanszosan a DX12 se lenne még sehol....
Pont ez a "gond" az Nv-vel... Arra mennek csak, ami feltűnő. És remekül csinálják. Ugyanakkor ez nem visz előre. Hiába jobbak a ma játékában, ezzel csak erősen fékezik az újszerű dolgok létrehozását...
Gondold végig csak azt, milyen cég, hogy még az új GPU-ikat se dokumentálják... Vicc. -
Abu85
HÁZIGAZDA
Kérdés mit nyernek vele? Mondjuk a legnagyobb PC-s kiadók lojalitását? Valószínűleg úgy vannak vele, hogy hol kell aláírni. Nagyon egyszerű a koncepció. A régi nagy NVIDIA fanatikus programozók, mint John Carmack vagy Tim Sweeney már nem a PC-s gamingre fókuszálnak, tehát van egy olyan réteg, amelynek az AMD mondhatja, hogy nézd, mi megadjuk, amire vágysz, és ezért cserébe csak a lelkedet kérjük. És mivel az NV a GameWorks után közutálatnak örvend e fejlesztők körében, nem is nehéz a meggyőzés. A mai top tízes fejlesztői csoport "I Am Mantle" pólókat visel a PC-s előadásokon. Van rá esély, hogy ezt az API-t támogassa az NV? Nem. Érdekli ezeket a fejlesztőket? Láthatóan kurvára nem. Sőt, John Kloetzli állandóan odaszúrja az NV-nek, hogy csináljanak végre egy low-level API-t.
-
Abu85
HÁZIGAZDA
Igen. Tök mindegy, hogy milyen API-val neveznek be a low-level versenybe. Az előnyök és a hátrányok ugyanazok. Az viszont nem mindegy, hogy melyik API mögött milyen a jelenlegi támogatás, mert az egyik mögött két, míg a másik mögött hét motor van. És a probléma az, hogy a DX12 felhasználóbázisa az új OS miatt kisebb lesz egy ideig. És a fókuszt nem a kisebb bázis szokta kapni. Ezeken agyalni kell, mert abban a két évben is történnek eladások, amíg ez probléma.
-
Abu85
HÁZIGAZDA
Igazából nincs különbség a koncepciók között. Ugyanazt kell csinálniuk Mantle és DX12 alatt is, tehát effektíve mindegy, hogy lesz driver vagy sem, mert nem az API adja a hátrányt, ha lesz, hanem az alkalmazás, ami ugyanúgy lehet hátrányos DX12 alatt.
Azt kell mérlegelni, hogy mennyit ér a Windows 7-es bázis. Nem véletlen, hogy a két low-level API esetén a Mantle-nek van nagyobb támogatása a DX12-vel szemben. Nézd meg a motorokat például:
DX12: Unreal Engine 4, Nitrous
Mantle: Frostbite, CryEngine, Nitrous, Asura, Gamebryo, LORE, Panta Rhei
A helyzet jelenleg az, hogy a fejlesztők úgy számolják, hogy a Win7/8/8.1-GCN részesedés még 2016-ban is nagyobb lesz, mint a Win10-DX12 hardver részesedés. Ez nem mindegy, így két évig biztosan a Mantle a fókusz. -
daneeeeee
aktív tag
Közben utána néztem a Cuda valóban licencelhető, tehát pénzbe kerül ellentétben a Mantel-el ami ingyenes. Ez az AMD részéről egy komoly gesztus amivel kvázi nyit a konkurencia felé. A két cég hozzáállása tehát merőben különbözik ennyiben sántít szerintem a PhyX-es példád.
"van precedens, sajnos. nézd meg az R9 285 tesztekben, hogy megy a Thief Mantle alatt. ha egy kis mértékben módosított architektúra begyűjt 10-15% hátrányt, akkor egy teljesen más architektúránál mi lehet a helyzet?"
Tudtommal ez nem a VGA hibája hanem a low level api-k használatának egyik velejárója. Ebben az esetben a játékot kell optimalizálni, hogy támogassa az adott VGA-t Mantle alatt (vagy később ezt javítócsomagokkal pótolni). forrás
DX 12 esetén is fent fog állni ez a probléma, szóval előbb-utóbb az AMD mellett majd az NVidia-nak is szembe kell néznie vele (ahogy Mantle mellett is kellene ha támogatnák). Tehát ez nyilván nem lehet akadálya egy Mantle támogatásnak az NVidia részéről.Szinte biztos hogy üzleti okokból nem állnak a Mantle mellé megvárják inkább a DX 12-t. Pedig jó pár kellemetlenségtől (pl: Wach Dogs, AC Unity) megkímélhettek volna minket. Akár az említett játékok mantle portjai is elkészülhetek volna ha anno beálltak volna az api mögé. Mennyivel másképp alakulhatott volna minden. Na mindegy ez már történelem.
-
daneeeeee
aktív tag
Tudtommal a Cuda nem egy nyílt GPGPU technológia, ez csak az Nvidia-é. De ha nem így lenne és Cuda-layer elérhető lenne Radeonokon sem hiszem, hogy megoldható lenne egy PhysX. Az AMD a Mantle-el nyitott a konkurencia felé is (bár ez nem ért túl sokat) NV-nél ilyen szándékot eddig még nem fedeztem fel mondjuk a PhysX-el kapcsolatban. Szóval nem hiszem hogy megadnának minden támogatást.
"ha az nVidia írna egy Mantle drivert (ami ebben az esetben igazából egy driver és egy interface kombinációja), akkor elfutnának a jelen Mantle portok a GeForce-okon, de esetleg a DX-sebesség felével. ennek mennyi értelme lenne?"
Ezt igazából nem tudhatjuk hogyan futna, nincs rá precedens.Mindenesetre az NVidia a DX12-t viszont támogatni fogja ami a Mantle-höz nagyon hasonló api. Szóval én nem vennék rá mérget hogy komolyabb difi kialakulna a két gyártó között DX12 alatt.
Sőt a Maxwell-t többek között DX 12-es Fable Legends-el is reklámozták. -
daneeeeee
aktív tag
A fickó azt mondta hogy a Mantle 1.0 raw változatát bárki használhatja, sdk is pubkikus hozzá.
Ezen felül kiemelte hogy még sokáig nem is akarnak változtatni ne, hogy az legyen, hogy a saját szájuk íze szerint alakítják az Api-t.
A Mantle játékok is kint vannak, a GCN azért volt alapul véve mert ez volt dokumentálva. Természetesen az Nvidia-t ettől még semmi sem akadályozza, hogy megírja a saját Mantle driver-ét az adott játékhoz.
Ehhez még csak az sem kell hogy dokumentálva legyen a hardver, a drivert az Nvidia írja, ők pedig tudják milyen a saját hardverük.A PhysX pedig rossz példa mert ez egy Nvidia feature ami csak Geforce-on aktiválható. A Mantle pedig ezek szerint egy nyitott dolog, az interjú alany szerint semmi akadálya nincs annak hogy Geforce alatt is működjön.
-
HSM
félisten
Több gyanús szempont is van. Egyfelől a csip mérete, ami pont akkora, mint a Tahiti, tehát elfér rajta a 384bit. Másfelől, gyanús, hogy ennyire semmi hír a 285X-ről. 256bittel nem lenne túl veszélyes a 280X bennragadt készletekre, 384biten, 48roppal viszont elég gyilkos cucc lenne, inkább loholna a 290 nyakán, mint a 280X-nek. Ez megmagyarázná, miért nem hallottunk eddig róla kb. semmit. Harmadrészt, a kiszivárgott Tonga-diák gyanúsan sok helyet hagytak a 256bites busz mellett.
Negyedrészt, ha már az AMD elhagyta a crossbart a memóriák és a rop-ok közül, és megduplázta a setupot is, akkor a ROP-okra is ráfért volna kis upgrade. Túl sok minden utal a 384 bitre. Tökéletes középkategóriás cucc lenne egy 512bites, Tonga-okosított 64ROP-os Hawaii utód mellett. A sima 285 a 256bittel meg ár/érték bajnok lehetne kicsit kevésbé elszállt árazással. -
Dtomka
veterán
-
HSM
félisten
Sanszos pedig a 48 ROP, mert valamelyik tesztben írták, hogy a Tonga azért is energiatakarékosabb, mert eltűnt a crossbar a 32ROP és a 256bites busz közül. Ugye a Tahitiben csak úgy lehetett 384bitre kötni 32 ROP-ot.
Sanszos, hogy 384bit/48ROP lesz, ami egy nagyon szimpatikus felső-középkategóriás Tahiti utód képét sejteti.... -
Abu85
HÁZIGAZDA
A Crysis 3 már nem használ teszellált óceánt. Nincs minőségbeli előnye az utófeldolgozások miatt.
A Tessmark egy olyan technikát használ, amelyet a játékok kerülnek. Főleg azért, mert minden hardver szar vele, hiszen a számítások nagy része felesleges. Ráadásul nem is jó minőségű technika. De a fejlesztések miatt ebben is jó lett a Tonga, csak ennek valszeg továbbra sem lesz lényegi előnye egy játékban.
Esetleg az isoline effekteknél lehet sokkal gyorsabb a Tonga, de az isoline teszellálás feladata tized ms szintjén túl kicsi terhelés, hogy ez a gyorsaság a gyakorlati fps-nél sokat jelentsen. A Tahitit verheti, de a Hawaii-t nem. -
HSM
félisten
-
-
Abu85
HÁZIGAZDA
Ja. Meg igazából az MLAA-ba is legalább négyféle algoritmus tartozik. Van az Intel-féle, ami a CPU-n fut, van a Jimenez-féle, van az AMD-féle compute shaderes, és innen az AMD még csinált egy MLAA 2.0-t, ami viszont már SMAA.
Szóval meg van ez keverve rendesen.Ezért kell az analitikai megoldások felé menni. 6-7 specifikus AA-val dolgozva szinte minden probléma lefedhető.
De egy ennyire komoly megrendelésnél sem tűnik reálisnak az 50 dolláros ár PCB-vel, memóriával, és azzal az óriás FPGA csippel. 
Jópár játékhoz 2GB nem elég, amikor maga a GPU míg vígan ficánkolna.![;]](http://cdn.rios.hu/dl/s/v1.gif)
Egy Pitcairn frissítés is nagyon kéne a portfólióba a Tonga alá. 
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- Amlogic S905, S912 processzoros készülékek
- Kettő együtt: Radeon RX 9070 és 9070 XT tesztje
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Szünetmentes tápegységek (UPS)
- Milyen belső merevlemezt vegyek?
- lacixtal: Laci XTAL - Emlékproffil
- Fejhallgató erősítő és DAC topik
- Milyen videókártyát?
- Nők, nőügyek (18+)
- Honor Magic V5 - méret a kamera mögött
- További aktív témák...
- GYÖNYÖRŰ iPhone 12 mini 64GB Green -1 ÉV GARANCIA - Kártyafüggetlen, MS3054, 96% Akkumulátor
- Amazfit Active okosóra / Számla / Garancia /
- Eladó iPhone 12 mini 64GB bevizsgált, hibátlan készülék
- iPhone 13 mini 128GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3089, 100% Akkumulátor
- BESZÁMÍTÁS! LG 24MB35PM 60Hz FHD IPS 5ms monitor garanciával hibátlan működéssel
Állásajánlatok
Cég: FOTC
Város: Budapest