De mibe? Egy értelmes játék sincs jelenleg amivel hosszútávon játszanál szerintem. Far Cry 3-at gondolom egyszer végigviszed és visszarakod a polcra. BF4 messze van. A COD/CS meg amúgy se zabál sokat.

A prezin nem mínuszban, hanem pluszban van a sebesség a 13.2 előzetesével a 13.1 WHQL-hez mérve. Az új menedzsmentszoftvert nem két hét alatt dobták össze, hanem már írják úgy fél éve. Ez hozza a 13.3 WHQL-re az utolsó boostot, még a HD 8000 előtt. Néhol keményen boostól +20-30%-ot is. De erről majd ha megjelenik a driver.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Tegnapról mára lett áttéve az új driver, ma sem fog jönni,tudsz róla valamit? (nem a mi számításunk szerint persze)

[ Szerkesztve ]

Vannak dolgok...

Elvileg ők az amcsi időhöz mérnek. Ott pedig még most ebédelnek. Egyébként a driver kész, csak az MS még nem küldte vissza az aláírást.
Most három driver van, ami le van csomagolva, bár nincs mindegyik kiadásra ítélve. Az egyik a 13.1, ami a WHQL lesz. Arra csak aláírás kell. A másik egy 13.2. Ez ugyanaz mint a 13.1, csak a DX9 alkalmazásokhoz meg van növelve a pufferméret. Ezzel tesztelt a TechReport. A harmadik egy alpha kód, ami a 13.2 kiegészítve az új memóriamenedzsmenttel, és a DX10+ alkalmazásokhoz is állítva van a pufferkezelés. Ez lesz kiadva hivatalosan béta szinten, az elkövetkező hetek valamelyik napján. Ez lesz a Boostos driver is, és egyben lényegében minden módosítás benne lesz, amit a GCN-re terveztek. Ezután csak új funkciók jönnek, és specifikus fejlesztések.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Tehát akkor a HD7X élettartamának a végére összehozzák, hogy a tudása összhangban legyen a driverrel?
Sorry ha nem villanyoz fel... HD8000 is ilyen lesz majd? Csak hogy mire számítsunk...

Komplett hangrendszerem eladó - https://hardverapro.hu/apro/mackie_studio_monitorok_mr5mk3_mr10s_mk3_sub_asus/hsz_1-50.html

Szerinted? Az X1600 Mobility-ből 2-3 év alatt hozták ki a maximumot. Kösz, de meguntam.

Elsősorban az architektúra kihasználására koncentrálnak. Mivel a nulláról építették fel az egészet, így olyan szoftvert is kell írni, ami megfelel ennek. A GCN viszont a legkevésbé sem hasonlít a többi GPU-architektúrához, inkább hasonlít a processzorokhoz, ennek megfelelően teljesen más szoftveres ellátást igényel.
A hardver tudása az egy másik lapra tartozik, itt az új architektúra sebességben való kihasználásról van szó. Ilyen mértékű váltást évek óta nem lépet meg senki, de nyilván idővel mindenki átesik majd ezen. Az AMD mostanra időzítette.
A tudás szempontjából a hardver annyira sok dolgot támogat, hogy biztos nem lesz minden beépítve az érkező 13.2-es béta driverbe. A driveres funkció előtt az API-ba kell beépíteni a támogatást. Aztán arra a kiterjesztésre jöhet egy frissítés a driverben. Az OpenGL és a DirectX API-hoz is számos kiterjesztést adott le az AMD nemrég, szóval ezeket még előbb el kell fogadnia az API fejlesztését végző cégnek, vagy csoportnak. Addig nem érdemes a támogatást elkezdeni, amíg ez nem történik meg, mert vissza is dobhatják a kiterjesztést, hogy valamit módosítani kell rajta. Amennyit tudok, hogy lesznek bindless kiterjesztések az OpenGL és a DX API-hoz. Ez lehet, hogy úgy lesz megoldva, hogy az NV hardverét is beveszik a támogatásba, mert a fejlesztőknek könnyebb, ha szabványosan képesek ezt kihasználni. A hardver igazából mindkét oldalon alkalmas erre, annyi a limitáció, hogy a GCN nem "csak" ~egymillió textúrát tud bindelni, hanem végtelen mennyiségűt, de kizártnak tartom, hogy ebből gond legyen. Az ~egymillió éppen elég nagy szám. A másik kiterjesztés ami biztos jön az a sparse texture támogatás a DirectX-hez. Ezeknél lehetnek az elfogadással problémák. Az MS valószínűleg úgy szeretné megoldani, hogy később ez a szabvány része legyen, amikor már nem csak a GCN támogatja. Ergo nem árt előre tisztázni, hogy ki milyen megoldásban gondolkodik, és ha lehetséges valami átfogó támogatás, akkor már most úgy érdemes megírni a kiterjesztést, hogy azonnal átemelhető legyen egy későbbi DX verzióba. Ugyanezt eljátszotta az OpenGL esetében is a Khronos, és arra el is fogadtak egy kiterjesztést. Ezek azért fontosak, mert azok a játékok, amik erre építeni fognak (mint például a Doom 4), a később érkező hardvereken is képesek legyenek úgy működni, ahogy a GCN-en fognak. Gondolom a DirectX-re a kiterjesztés az új Carmageddon miatt fontos (a fejlesztők azt mondták, hogy megatextúrát használnak). Ebből láthatod, hogy a tudás fejlesztése az nem olyan egyszerű. Itt törekednek a csoportok arra, hogy később a szabványos implementációnál minél egyszerűbb legyen a funkció átemelése a most kidolgozott kiterjesztésekből.
A HD 8000 alapvetően ez az architektúra lesz. Pár új funkciót kap, de azokra sem lesz rögtön támogatás, a fentebb leírtak miatt. Most, hogy behozták a DirectX-be ezt a kiterjesztéses mókát érdemes újítani az architektúrákon, mert nincs kőbe vésve a specifikáció. Persze ennek a kontra oldala, hogy ha csak egy gyártó támogatja a szükséges kiterjesztést, akkor a többi hardveren az azt használó eljárás nem fog lefutni.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Nézd én értem ezt a sok technoblablát, de azért tedd a szívedre a kezed és mond hogy nincs igazam abban, hogy akkor fizetek valamiért, ha hasznom van belőle.
Akkor veszem meg, ha a tudásából előnyöm származik, és ki tudom használni, méghozzá megbízhatóan.

A kérdés tehát továbbra is fennáll: Ilyen lesz a HD8X ? Mert egy videokártya esetében 100%-osan irreleváns, hogy 2-3 év múlva mit fog tudni majd adott esetben. Én azért veszem meg, hogy azonnal, abban a pillanatban létező játékomban javulást, előnyt biztosítson teljesítményben, vagy minőségben. 1, max 2 év után úgyis lecserélem a következőre, akkor már 0%-os befolyása lesz rám annak, hogy milyen drivert adnak még ki az 1-2 éves kártyámhoz, mert ott az új, ami még jobb.

Komplett hangrendszerem eladó - https://hardverapro.hu/apro/mackie_studio_monitorok_mr5mk3_mr10s_mk3_sub_asus/hsz_1-50.html

játékokban fog hozni MÉG plusz sebességet, pedig a 12.11 béta is elég durván boostolt

ez nem az a boost amire te gondolsz, de inkább 7970 topikba folyt.

Ott nem jutottam sokra, az a kevés infó meg már ismert. Ott főként az a vezérelv, hogy tuningolni köll és kész, aki meg nem az nem is normális. Köszönöm a felhomályosítást, de más érdekelne. Abu tudhat infókat, talán válaszol.

Teljesen általános dologról van szó. Amikor fizetsz a termékért, akkor az aktuális teljesítménye alapján veszed meg. A szoftveres frissítés viszont legalább 3-4 évig jár hozzá, és az bármikor hozhat teljesítménynövekedést. Régen csináltunk erről egy tesztet, hogy szinte mindegyik VGA gyorsul legalább 10-15%-ot a kezdeti driverekhez, a sok hónappal későbbi driverekkel. Ezek lassacskán hozzá lesznek adva, hogy még jobb legyen a termék. Általános dologról beszélünk tehát. A GCN esetében arról lehet szó, hogy a kezdeti sebességhez képest jóval több tartalékot találnak benne, mert az architektúra radikálisan új alapokra van építve. Nyilván amikor a szoftveres csapat nézi, hogy mennyit lehet ebből kihozni, akkor nem azt nézik, hogy tartsuk a megszokott 10-15%-os általános javulást (annyit szinte mindig lehet találni), hanem hozzunk ki belőle mindent, ami van. Ha az +20-30%, akkor annyit. Ezt sosem tudják a cégek előre, mert a hardvert a szoftveres csapat fél évvel a megjelenés előtt kapja meg. A megjelenésre tehát csak egy működő drivert írnak, aminek van egy általánosan jó sebessége. Az új generáció megjelenésével viszont folyamatosan kutatják annak a lehetőségét, hogy találjanak extra sebességet, és ez nem csak a GCN-re, hanem a Keplerre is igaz. A GeForce sem ugyanazon a sebességi szinten van, amin megjelenéskor. Csak ez nem nagyon tűnik fel a tesztekben, mert az AMD is frissíti a drivereket. Ergo egymással versenyeznek ezen, és nagyjából a gyorsulás egységes. Egészen novemberig, amikor jött a 12.11 béta és az elég komoly extrát rápakolt a GCN-re, és még jön egy extra az új menedzsment mellett. Az egyébként inkább a DX11-es programokban lesz érezhető, főleg olyan helyzetekben, amikor a cacheszervezés a compute shaderek teljesítményét döntően befolyásolja. Mivel 2013-ban számos compute igényes játék készül, így ez egy fontos szempont most az AMD-nek. Az NVIDIA is javítani fog egyébként még a következő hónapokban. Még nekik is vannak kihasználatlan tartalékok. Az persze kérdés, hogy mennyi, de arról biztosan tudok, hogy dolgoznak rajta. Baj lenne, ha nem így tennének. Van egy olyan érzésem, hogy ezekkel az új boostokkal mindkét cég az új generációt akarja megtámogatni. Mivel alapvetően architektúrát egyik fél sem cserél, így amit most beépítenek, az automatikusan érezhető lesz az új termékeknél. Ez a verseny pedig kemény lesz, így szükség van minden tartalékra.
Azt meg tudom ígérni, hogy ha van tartalék egy hardverben azt az adott cég ki fogja hozni. Ez sosem volt másképp. A hardvert ilyenkor nem tekintik. Egyrészt valaki nem cserél gyorsán, másrészt az architektúra marad, tehát minden ami érinti az aktuális generációt érinti az újat is.

(#10042) szasanyi: A Powertube Boost szolgáltatás erre van. Ha ezt látod, akkor működik jól. Az egész játékfüggő. Valamelyik játékban szinte mindig alapórajelen megy, mert nincs lehetőség Boostra, míg van olyan játék, ahol mindig kimaxolja az órajelet. A többi játékban fel-le vált. Ezt a szolgáltatást az AMD a Kepler GPU Boost funkciójára adta válaszul. Persze nem ugyanúgy működik, mivel a Kepler jóval nagyobb órajelugrásokat csinál, és jóval sűrűbben, de igazából itt szerintem csak arról volt szó, hogy az NV bevezette, hát vezet be valami apróbb turbót az AMD is. Igazából a Powertube Boost extra órajele annyira pici, hogy nem sok lényegi hatása van a teljesítményre. Plusz extra 50 MHz-et ad, ami 1 GHz körüli órajeleknél nem sok. A Kepler +100-250 MHz-eket is ugrál oda vissza. Ez már relatíve sokat változtat a teljesítményen.
A driver a szoftveres fronton fog változni. Az új menedzsmentszoftver a memóriára lesz hatással. Azokban a helyzetekben javul a sebesség, ahol a compute shader kifejezetten bonyolult és sok adattal dolgozik. Ilyen lehet például az OIT eljárás, amit az AMD nagyon be akar már rakni a játékokba. Lenne is rá igény, csak a sorrendtől független átlátszóság nem az a tipikusan GPU-kímélő effekt, szóval kell hozzá a teljesítmény, és főleg hatékonyság. A fejlesztők éppen ezért nem építették még be, pedig már kész van két éve. Ha be is rakják, akkor is szükség van egy ODT megoldásra, hogy ha esetleg a hardver nem bírná el az OIT-t, akkor legyen azért alternatíva. Ahogy haladunk a DX11 only motorok felé, és ahogy nő a hardverek teljesítménye úgy válik alternatívává az OIT. Ezt ugyanis kikapcsolhatatlan szinten van értelme implementálni. Mivel még mindig rengetegen gondolkodnak deferred render motorban, így az OIT előbb-utóbb ott lesz a játékokban. Túl sok szopást jelent az ODT deferred leképzéssel. Itt ugye arról van szó, ha valaki nem értené, hogy a deferred render az megpróbál szoftveresen egy okosabb feldolgozással operálni a forward render brute force elve helyett. Éppen ezért sok felületet kivág, hogy azokkal ne kelljen törődni. De ugye a geometriai vázban egy ablak átlátszó, viszont amikor kivágja mögötte a geometriát, akkor a rendszer még nem tudja, hogy az később látszódni fog. Ilyenkor pedig újra le kell renderelni az ablak mögötti részt. Erre szükséges egy rendezés, hogy az átlátszóság pontos legyen, hiszen a hardvernem tudnia kell, hogy melyik objektum melyik mögött-előtt van. Ez a rendezés rész már önmagában problémás, mert ha hiba van benne, akkor felületek tűnnek el az ablak mögül. Pont ezért kerülik a játékok dizájnjánál, hogy két-három átlátszó felület legyen egymás mögött. Egyrészt gáz a deferred render működésének, másrészt ha hibás a rendezés, akkor esetleg az ellen is eltűnhet, mert az ablak mögött. Persze, ha ilyen szituáció kell a játékba, akkor fokozott figyelmet szentelnek neki. Viszont amerre ugye megyünk az a sorrendtől független átlátszóság. Ennek az egyik formája, amit az AMD kidolgozott még két-három éve, de van más formája is, igazából nem kötelező ezt compute shaderrel csinálni. Az egész lényege, hogy a ne kelljen figyelembe venni az objektumok sorrendjét, hanem azok automatikusan helyesen legyenek megjelenítve az átlátszó felületek esetében. Ez tipikusan fontos szempont a deferred render motoroknál, és erre már van is egy megoldás, ami a DiRT Showdownban használt forward+ rendszerre alapoz. Na most ezzel az a probléma, hogy a DiRT Showdownban látjuk azt, hogy ezt igazából a GCN-en kívül nem szeretik a hardverek, de semmi gond, mert a lighting fázis könnyen kikapcsolható, és ezzel még sok munka sincs. Szimplán kiveszed a futószalagból. Viszont a deferred renderhez készített OIT tack-on megoldás, már nem kapcsolható ki ennyire egyszerűen. Konkrétan más futószalagot kell tervezni mellé, ha kell alternatíva. Ha pedig eleve szükséges alternatíva (mert ugye azért nem mindenki rendelkezik GCN-nel), akkor pedig értelmét veszti az OIT tack-on megoldás, mert egyszer át kell szenvedned az alternatív ODT opció beépítését. A képi eredmény igazából ugyanolyanra kihozható, csak az OIT tack-on kivitelezése nagyságrendekkel egyszerűbb. A lustább fejlesztők valszeg imádni fogják szvsz, de az igényesebb réteg inkább olyan megoldást keres, ami nem csak egy architektúrán hatékony. Esetleg azt tudom elképzelni, hogy ha valaki tényleg nagyon komplex, üvegekkel brutálisan teletarkított akciójelenetet tervez, na nekik az OIT szükséges.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

várom már azt a boostos drivert ami megkapja az új management szoftot

keplernél is lesz sztem ilyen durva boostos driver, mert az is totál uj architekt

[ Szerkesztve ]

Én meg a választ várom, de úgy tűnik Abu pikkel rám... de legalábbis nem válaszol...

arra nem gondoltál hogy esetleg elfoglalt ? és hogy rajtad kivül még 100an irnak neki privátot?

én eddig akárhányszor kérdeztem tőle valamit, mindig készségesen válaszolt, nagyon segítőkész, várj türelmesen és fog neked irni nyugi

Egyáltalán privátba miért zaklatjátok? A fórum erre való, hogy ott kérdezzünk.