- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- iPhone topik
- OnePlus 7T Pro - árban is a csúcson
- Fotók, videók mobillal
- Magisk
- Poco X6 Pro - ötös alá
- Honor Magic6 Pro - kör közepén számok
- Spanyolországban kezd a Vivo V40 5G és V40 Lite 5G
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Mobilhasználat külföldön
Hirdetés
-
Switch-re is befut a Darkest Dungeon 2
gp A PlayStation kiadások mellett a Nintendo konzoljára is elérhető lesz jövő hónapban az új kiadás.
-
Rejtett díjak, nehéz lemondás: az USA pereli az Adobe-ot
it Nem csak rejtett díjakkal károsítja meg a fogyasztókat az Adobe, de az előfizetések lemondását is megnehezíti – ezért beperelte az USA kormánya.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
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
-
Abu85
HÁZIGAZDA
Az egy jobb API-val lehetséges. Az OS-hez kapcsolódik a futtatott program, az API és a driver. Utóbbi kettő több OS stacken fut. Ezt mind durván kötelező a host processzoron végrehajtani. Rakhatsz ezer ARM magot is a GPU-ba, de arra nem tudsz átvinni OS-hez kapcsolódó folyamatott, mert nem host. De még, ha a program tartalmaz is user módú kiegészítést erre, ami megkerüli az egész modellt, akkor is sokkal lassabb lesz az adatok folyamatos másolgatása, mint a host processzor terhelése.
Az APU-k IGP-je sem drivert fog futtani, és nem is OS folyamatokat, vagy drivert, vagy API-t. Olyan feladatokat lehet rá átrakni, amelyek nagymértékben párhuzamosíthatók. Ezt teljesen a fejlesztő fogja kontrollálni felhasználói módból futtatva az egészet.
[ 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
Crytek
#12425
üzenetére
Ez a GameWorks SDK. Ez az NV válasza a konzolokra. Az a lényege, hogy van egy rakás saját fejlesztésű effekt, amit pár kattintással bele tudsz másolni a játékba.
Ezt már lassan egy éve elkezdték fejleszteni, mert nekik is ugyanúgy sírnak a fejlesztők, hogy nem tudnak mit tenni a DirectX korlátjaival és segítséget akarnak. Az NV viszont a DirectX lecserélése helyett ezt hozta létre. Ha van egy konzolos next-gen GI, SSAO, God Rays, vagy akármilyen effekt, ami a DirectX miatt nem portolható PC-re, akkor a GameWorks SDK tartalmazni fog rá egy alternatív effektet, ami elvben ugyanazt a célt szolgálja, csak működik PC-n is, noha más minőségben.
Ez is egy realista megközelítés, mert a konzolon valszeg sokan fognak SV-PRT-CT-t alkalmazni, mert tényleg új szintre tudja emelni a grafikát, de a DirectX-ben ez PC-n lehetetlen, mert nincs meg az API-ban a funkció erre. Sweeney akart SV-O-CT-t használni az Unreal Engine 4-hez, ami lehetséges DirectX alatt, de helyenként annyira magas az API késleltetése, hogy majdnem egy másodperces akadások is lehetségesek, amiket nem lehet szűrni egy játékban. Egy 3-4 perces jelenetsorra ráoptimalizálhatsz, de a valós futtatású játék nem ilyen. Ezzel Sweeney is inkább lelőtte a projektet, mert csak konzolon működött volna.Példával élve itt ez a játék: [link] - ez SV-PRT-CT-t használ a GI-ra, illetve részben ehhez kötődő fluid dinamikát a tűzre, stb. Ennek az összhatását a videó végén úgy 22:40-től jól meg is lehet nézni. Na most ezt portolni megfelelő API nélkül képtelenség PC-re. Éppen ezért a GameWorks SDK alternatívákat kínál. Ebben van GI Works az illuminációra és Flame works a tűzre. Messze nem ugyanaz a minőség persze, de ez lehetséges DirectX alatt.
Ha valaha is készül PC-s port ezekből a játékokból, akkor ahelyett, hogy új effekteket írnának a fejlesztők, használhatják a GameWorks SDK alternatíváit. Esetleg, ha bárki a PS4-es effekteket leportolja a Mantle-re, akkor a DirectX kódhoz szintén használhatja az NV megoldásait a gondokra.
[ 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
Crytek
#12427
üzenetére
Az biztos, hogy a szoftver nagy előny jelenleg a konzolon, de szerencsére már dolgoznak rajta a cégek, hogy ez a programozhatóság és funkcionalitás elérhető legyen PC-n is. Tehát nincs veszve minden, de az borítékolható, hogy lesz egy kisebb időszak, amikor a konzolok technikai minősége felülmúlja a PC-ét. Ha szerencsénk van, akkor 1-2 év alatt átáll a PC is az új programozási modellekre. Lényegében az API oldaláról már ott a Mantle, tehát egy probléma félig leküzdve. A másik problémára pedig ott lesz az OpenCL 2.0/C++AMP és ezek HSA-val turbósított verziói.
[ 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
válasz
Crytek
#12436
üzenetére
Ahogy folyamatosan utalt rá JHH az előadáson, a legfőbb cél az Android fellendítése, hogy erre is érkezzenek az AAA-s alkotások. Az Unreal Engine 4-et direkt Androidhoz tervezték.
A mobil az mellékes, meg hogy most hogyan állnak. Android lesz okostévékre, új konzolokra, lesznek AIO-k. Az NV szemében az Android az új Windows.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#12565
Abu85
HÁZIGAZDA
KillerKollar
#12563
Abu85
HÁZIGAZDA
válasz
KillerKollar
#12563
üzenetére
500+ mm2-es GPU-kat dizájnolni az NV szava járásával élve "fucking hard". Hát röviden ezért.
De egyébként nem kell igazán félni. Úgyis a kihasználtsággal vannak problémáink nem pedig a számítási teljesítménnyel. Ahogy jönnek a konzolra az asnyc compute játékok úgy jönnek majd át ezek a képességek PC-re is. Hogy DX12-vel vagy Mantle-lel az mindegy, összességében így is elérik, hogy az átlagos 40-50%-os kihasználtság 70-80%-ra növekedjen.
Az árak növelés egy gazdasági problémának az eredménye. Nincs igazán köze a fejlesztéshez és a gyártástechnológiához. A gond az, hogy nem vesznek annyian VGA-t, mint pár éve.
[ 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
Mans20
#12589
üzenetére
Nincs kezdetleges meg igazi Maxwell. Az architektúra már adott és az nem változik, mert ahhoz legalább másfél évig tartó tervezés szükséges. A Maxwell az olyan lesz, amilyen a GM107-ben, csak máshogy lesz skálázva.
(#12584) Crytek: A DX12 semmit sem jelent majd. Ha előtte, ha utána váltasz ugyanazt kapod a szoftveres frissítéssel.
[ 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
Mans20
#12591
üzenetére
Ettől az architektúra nem változik még gyökeresen. Maximum fejlődik valamennyit, de ezek jellemzőén nem nagy változások.
Ha fontos a teljesítmény és a fogyasztás akkor nyilván maradnak 28 nm-en. A 20 nm előnye csakis a kisebb lapkamérét.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mivel a 780 készletek nem kapnak utánpótlást, és ezeket akciózzák most, így azt hiszem, hogy bármiféle NDA megsértése nélkül lehet tudni, hogy hova jön valami, akármi.
Egyébként a 780-at akciósan érdemes venni, mert 48 ROP és a 384 bit hiányozni fog az új valaminél/akárminél, ami jön 370 fontos szint köré.
Persze ezek csak kósza gondolatok. Ne tulajdonítsatok neki jelentőséget.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Elöljáróban most sem, sőt még mindig nem tudom miről van szó, sose hallottam ilyenekről, de jön a DX12 és az egy eléggé újszerű API lesz. A hagyományos elven működő parancsprocesszorok eléggé rossz hatékonyságot mutatnak fel benne, hogyha aszinkron munkavégzésre kerül a sor. Márpedig sok játékban arra fog kerülni. A legfőbb fejlesztések ezeket érinthetik. Mindenki bőszen másolja most az AMD GCN-nél alkalmazott megoldását, vagy a konzolok megoldását, ami ugyanaz ... kinek, hogy tetszik. Ez alapvető hatékonyságot hoz az új API-kban, de ma még nincs igazán előnye. De persze ezek csak finom gondolatok. Képzeljétek el ezeket a fejlesztéseket úgy, hogy ha nem mennek erre, akkor az adott hardverben hamarabb lesz GPU-limit.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#12660
üzenetére
Attól függ melyik API-n nézzük. A PS4 libGNM-en már működik az aszinkron compute az Infamous: Second Son című játékban. A PC-n először ilyet Mantle-ön láthatunk majd. A Frostbite 3, az Asura és a LORE támogatni fogja. A DX12 esetében is ezek a motorok használhatják először, hiszen az aszinkron compute esetében a párhuzamosítás összehangolása a nehéz, nem pedig az API implementáció. DX12-re simán másolható a Mantle/libGNM kód.
Mivel a Frostbite 3 eléggé fontos motor (az összes EA játékot ez hajtja), így teljesen reális, hogy a hardvergyártók lemásolják a PS4 parancsprocesszorának képességeit. Ez már csak azért is lesz így, mert a Frostbite Team korábban bejelentette, hogy a PS4 a vezérplatformjuk. Aki nem másolja le ezt hardverben az sokkal hamarabb kap GPU-limitet.[ 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
Locutus
#12663
üzenetére
Próbáltam utálni rá, hogy az NV elkezdte másolni az AMD megoldását. Ez alapvető ahhoz, hogy 2016-ban hatékonyságot érjenek el. Persze ennek a DX12-ig nem lesz jelentősége az NV számára, hiszen a Mantle kódokból nem profitálnak, de a DX12 egy teljesen újszerű API, és hagyományosan tervezett parancsprocesszorokkal nem lehet komoly hatékonyságot elérni, ha aszinkron compute jön. Egyszerűen azért, mert nem tudsz annyi parancsot kiadni a hardvernek, hogy azokat hatékonyan párhuzamosítsa. A legtöbb NV hardver még 1 compute és 1 grafikai parancsot dolgoz fel egy órajel alatt. A PS4 - amit másolni fog mindenki - 65 compute és 1 grafikai parancsot dolgoz fel ugyanennyi órajel alatt. Az AMD frissebb hardverei sem véletlenül kapnak 2 ACE helyett 8 ACE-t.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#12664
üzenetére
A DX12 váltsuk két részre.
A hatékonyság főleg szoftveres jellegű. A kód mindegyik olyan hardveren futni fog, amelyikhez van driver, és innentől kezdve lehet olyan hardveres implementációt alkalmazni, ami javítja a futtatás hatékonyságát. Például az MMU megléte, hiszen azt akkor nem kell emulálni. Vagy az aszinkron compute, aminél fontos, hogy egynél több compute parancs legyen feldolgozható órajelenként és legyenek elég kicsik a multiprocesszorok is a párhuzamosításhoz. Ezek sebességet hoznak.
Az extrák főleg grafikai effektek aktiválhatóságában lesznek tetten érhetők. Ha áthozod a konzol kódot módosítás nélkül kb. 10 sor kiegészítéssel, akkor az futni fog PC-n. A nem kompatibilis effektek bizonyos hardvereken nem kapcsolnak be, de a kód működni fog.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#12667
üzenetére
Legaljában nem. Csak a nagyon régi MMU nélküli GPU-knak lesz hátránya, mint az Intel Gen7.5 és az NV Fermi.
A legaljára egyébként nem sokan gyúrnak majd. A DX12 esetében nagy szerencse lesz, hogy nem kell végigfutni az API-val a felkészülési időszakot, mert azt Mantle-ön szinte mindenki megcsinálja. A DX12 már egy olyan fejlesztői alapba érkezik, ahol a Mantle alatt megtanulták, hogyan kell low-level API-t programozni. Ezzel jó egy-két éves tapasztatgyűjtési időszakot úszunk meg, mert az most van. Igaz, hogy nem DX12-n, de ez mindegy, az API elvi működése a fontos, ebben pedig a Mantle gyakorlatilag nem különbözik. Tehát a DX12-es váltás igen extrém sebességű lesz, és igen gyorsan hozzányúlunk az extrákhoz 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
Crytek
#12669
üzenetére
Attól függ miről váltasz. Szerintem akinek már van 780/290-e annak nem érdemes váltani. Gyengébb hardverről mozdulva a sebesség szempontjából már érdemes modern dizájnt venni a jó DX12-es sebességhez. Ha pedig teljes DX12 funkcionalitást akarsz, akkor nem. Ehhez az NV-től amúgy sem kapsz majd hardvert. Ők nem kifejezetten rajonganak azért az ötletért, hogy a konzolok új generációs effektjei átkerüljenek PC-re. Ha át is kerülnek, akkor is olyan hardvert akarnak kínálni, amin nem futnak majd le, hogy a tesztekben ezek legyenek abszolút kikapcsolva. E vonal mentén a PC esetében azt mondják majd a fejlesztőknek, hogy használjanak GameWorksöt. Aztán más kérdés, hogy a fejlesztő visszamondja, hogy csak a GameWorks kompatibilitásért nem fogja átírni a renderert. De ez politikai harc lesz.
[ 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
Crytek
#12672
üzenetére
Aki arra számít, hogy itt nagy verseny lesz csalódni fog. Az NV-nek van egy nézete a jövőről és az AMD-nek van egy gyökeresen ellentétes véleménye ugyanerről. És itt jönnek képbe a fejlesztők, akiknek ugyanúgy megvan a véleménye a helyzetről. Mivel a két cég véleménye teljesen eltérő, így a fejlesztők egyszerűen oldalt választanak. A GameWorks egyébként nem baj, a dokumentációk hiánya viszont az. Az NV ezzel akarja kikényszeríteni a GameWorks használatát, mert önállóan úgysem tudnak majd a fejlesztők GeForce-ra optimalizálni. Meg is van erről a véleményük: [link]
Viszont ez piacpolitika. Az NV számára azoknak a fejlesztőknek a támogatása amúgy sem kell, akik nem érteken velük egyet. Lásd a linkelt nevek.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
-Solt-
#12674
üzenetére
Szerintem ennek nincs igazán köze ahhoz, hogy az AMD előnyben részesíti az AAA/konzolportokat, míg az NV inkább az MMO/MOBA-kat pénzeli. Ez inkább egy üzleti megfontolás. Az NVIDIA már évek óta sokkal többet költ az MMO/multi/MOBA vonalra, aminek az oka az, hogy ezek a játékok nem feltétlenül érhetők el konzolon és népszerűek is. Az persze lehet, hogy maga a jelenség felerősödik és még szélsőségesebb lesz a gyártók játékválasztéka, de ezt a döntést korábban hozták meg és biztos, hogy üzleti alapon.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#12740
Abu85
HÁZIGAZDA
KillerKollar
#12739
Abu85
HÁZIGAZDA
válasz
KillerKollar
#12739
üzenetére
A piac szűkülésére nem úgy reagálnak a cégek, hogy azonnal árat növelnek, viszont az új árazást mindig ehhez szabják.
Jelen állás szerint a verseny megszűnik. Az AMD és az NVIDIA egy teljesen ellentmondó irányt követ. Egyre többen mondják a twitteren is, hogy ez rossz lesz a PC-nek. A fejlesztők számára rossz, hogy az NVIDIA hardvereire képtelenség optimalizálni. A legújabb blog Matías N. Goldbergé. [link] - az első fele jól rávilágít, hogy mi a probléma. Ha akar, se tud az NVIDIA VGA-kra optimalizálni. Maga az NVIDIA nem engedi meg. Pontosabban nem mondják el, hogyan kellene megtenni.
Ez oda vezet, hogy vagy a GameWorksöt választja a fejlesztő, vagy a GCN-t támogatja, hiszen az AMD megmondja, hogyan kell rá optimalizálni.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
Crytek
#12795
üzenetére
GTA V-nek nem lesz túl nagy gépigénye. Négymagos proci, 6 GB RAM és egy középszintű VGA kell hozzá. Az AMD szokásos counter IDF rendezvényén Radeon R9 285-tel futott a press demó verzió. Szóval teljesen vállalható, elég sokat optimalizálják még a következő négy hónapban (legalábbis, ha ebben a videóban korrekt a január vége, de gondolom az, hiszen hivatalos csatornán van fent), mert azért bugzik.
A többinek kell majd gép.
[ 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
válasz
Crytek
#12814
üzenetére
Az OpenCL a compute szabvány, tehát csak erre készül bármilyen konzumer szintű kezdeményezés manapság. És igen az sem véletlen, hogy hirtelen mindenkinek olyan nagyon fontos lett.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#12821
üzenetére
És most nézzük a tényeket, hiszen az OpenCL egy Apple által életre hívott kezdeményezés és a Khronos Group égisze alatt fejlődik. Az AMD szimplán egy Khronos Group tag, ahogy sokan mások, hiszen ez egy konzorcium.
Nagyjából 200 OpenCL alkalmazás létezik. De nem ez a gond, hanem az, hogy sok szoftvercég eldöntötte, hogy nem tartják fent tovább a CUDA és az OpenCL pathot egyszerre, mert dupla pénzt költenek a semmiért. Nyilván az OpenCL-t választják ilyenkor, mert az a szabvány és az NV is támogatja, illetve, ha elég nagy vagy, akkor az NV segít is. Persze ha látják, hogy nem tudnak meggyőzni arról, hogy az OpenCL csak árt. Vannak is jó előadásszövegek OpenCL-lel kapcsolatban: [link][ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
#12897
Abu85
HÁZIGAZDA
KillerKollar
#12895
Abu85
HÁZIGAZDA
válasz
KillerKollar
#12895
üzenetére
A DX12 nem fekszik jobban a Radeonnak, csupán az lesz a különbség, hogy lehet rá optimalizálni, mert ismerik. Ezek az új API-k low-level kódok. Számít, hogy ismerd az architektúrát, mert mostantól, ami a driverben volt, az a programban lesz. Ha azt a működést nem írod meg hatékonyan, akkor olyan lesz a futtatás, mint amikor a driver nincs ráoptimalizálva az alkalmazásra. És nem lehet ám új driverrel javítani rajta, mert a kód ott van a programban.
Ez az oka annak, hogy az AMD nagyon reklámozza a Mantle-t, az Intel a DX12-t, az NV pedig igazából semmi low-levelt, és emellett is a GameWorks felé terelik a fejlesztőket, mert azt ők írták, és biztosan optimalizálva van GeForce-ra. Egy átlag fejlesztő ezt nem tudja megtenni, mert az NVIDIA nem mondja meg hogyan kell.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ahhoz képest, hogy nem erőlteti a Mantle-t, csak 80 stúdiót győztek meg arról, hogy használják.
De ez egyébként nem a Mantle-ről szól. Az egész alapja a low-level elérés. Mostantól nincs csodadriver meg hasonlók. A Mantle, a DX12 és az új OpenGL is olyan API lesz, ami egyedül a shader fordítás felett babáskodik. A többi dolog, mint a frame számítás késleltetése, az állapotváltások kezelése, az állapotszűrés, a parancspufferek kezelése, ezek listázása, illetve a parancsok felvétele és a memória kezelése mind az alkalmazás részévé válik. Bizonyos szempontból maga az alkalmazás lesz egy univerzális, felhasználói módban futó grafikus driver, és ezt a program fejlesztőjének kell megírni. Lehetőség szerint annyi architektúrára optimalizálva amennyire csak lehet.
[ 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
Crytek
#13023
üzenetére
Vannak már előzetes DX12 eredmények a Nitrous motorral. Egyelőre sokkal jobban számít az, hogy a program fejlesztője mennyi időt töltött xy architektúrákkal. Persze pre-alpha minden, ami DX12. Az látszik, hogy Radeonnal nagyjából megközelítik a Mantle eredményeit, vagy ha úgy tetszik nincsenek messze tőle ahhoz képest, hogy pre-alpha a kód. Az Intel IGP-k is elég jól mennek. Az NVIDIA megoldásai küzdenek, főleg a Maxwell. Érdekes, hogy a Fermi elég jó, míg a Kepler középtájon tanyázik. Valószínűleg a Fermi működését ismerik a legjobban, míg a Keplerről már van némi tapasztalat. A Maxwell azzal küzdhet, hogy szinten semmilyen formában nem működnek rajta az optimalizációk. Szóval ezt az architektúrát majd vissza kell fejteni, és az eredmények tudatában kell újraoptimalizálni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13025
üzenetére
A gyártóknak mutatták meg. De mivel pre-alpha a kód, így sok értelme nincs lehozni. Nem tudom, hogy leak site megkapta-e az eredményeket.
Minden új generációs motort GCN-re írnak. Ennek csupán az az oka, hogy dokumentálva van a hardver, tehát nincs elrejtve a fejlesztő elől, hogy miképp lehet belőle a legtöbbet kihozni. A multiplatformosok pedig a konzol miatt írják a GCN-re.A Nitrous támogatása ipari szintű. [link] - Az AMD-től csupán kaptak egy működő API-t a koncepcióhoz. Ebből portolják a DX12 kódot. Csak ez nem olyan egyszerű, hogy átírod és kész. Külön kell optimalizálni a GCN opciókra, az Intel architektúrákra, az NV Fermi, Kepler, Maxwell generációkra. Ráadásul ezek sem csak egy IP-ben merülnek ki, tehát a teljes támogatáshoz kell némi idő. Kétségtelen tény, hogy az első Nitrous játék még több hónapra van, tehát annyira nem meglepő, hogy még csak az AMD-re és az Intelre figyeltek. Az NVIDIA-t jellemzően az utolsó pillanatra hagyják. A Cryteknek például bejött, hogy a Ryse-t kiadták úgy ahogy volt, és rögtön elmondta az NVIDIA, hogy miképp kellene optimalizálni a hardvereikre. Hoztak is rá egy sebességnövelő patch-et a GeForce-okra. Nem nehéz az NVIDIA-val bánni, csak sarokba kell őket szorítani. A DICE is megcsinálta velük a Battlefield 4-nél, négy hónappal a megjelenés után sikerült is optimalizálni és aktiválni a mutex zárolásokat GeForce-okra is.
[ 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
Jack@l
#13027
üzenetére
Inkább a kameramozgástól függ a kirajzolás mennyisége. Gyors mozgásnál tízszer is le lesz másolva egy hajó. De ezért működik úgy a Nitrous, hogy nem árnyalnak poligonokat. Ha egy hajót egyszer elkészítettek, akkor azzal a GPU már nem foglalkozik. Nem számolja ki újra, így a kirajzolás a draw call mennyiségét növeli csak, vagyis a processzortól függ, hogy mennyire gyors a filmes hatású motion blur. A GPU-k számára ez az effekt semmilyen extra terhet nem jelent, mert ugyanannyit számolnak filmes hatású motion blurral, mint nélküle.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13090
Abu85
HÁZIGAZDA
KillerKollar
#13087
Abu85
HÁZIGAZDA
válasz
KillerKollar
#13087
üzenetére
Az API részéről a fekszik a kártyának dolog egy tévedés. Egyik API sem fekszik senkinek, mert az csak egy specifikáció. Ezután jön az implementáció kérdésköre, ami már érdekes. Főleg a low-level API-knál, mert a fejlesztő implementálja mindegyik hardverre és azon belül mindegyik architektúra verzióra. Ott már előjöhet, hogy az egyik architektúrára jobban implementálják, és ez előny lehet. Tehát ha az új low-level API-kban az egyik architektúra előnyt élvez, akkor az azért lesz, mert a programban szállított "implementáció/grafikus driver" jobban fekszik annak az architektúrának. De ez nem az API miatt van, hanem amiatt, hogy azt az architektúrát célozták az optimalizálással.
[ 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
#13120
üzenetére
Senki sem vár a 20 nm-re. Nem kritikus fontosságú a GPU-knál. A pletykáknak ne üljetek fel. A TSMC elérhető node-jaiból a GPU-knak a legjobb a 28 nm-es HPM. Ennél csak a GloFo 28 nm-es SHP-je jobb, de nem feltétlenül ér annyit az áttervezés, hogy megejtsék, bár ez tényleg attól függ, hogy mit várnak a következő node-októl. A 20 nm-es opciók egyértelműen rosszabbak, csak akkor éri meg erre váltani, ha kell egy 2.5D TSV kompatibilis process, más előnye nincs.
[ 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
Jack@l
#13127
üzenetére
Egyrészt olyan, hogy Bermuda nem létezik. Fiji ami létezik, és tényleg fejlesztés alatt áll. A wccftech egy teljesen fals információkat közlő pletykasite. A Fudzilla nyomdokait járja, csak rosszabbul.
Másrészt egy új hardverrel az a legnagyobb probléma, hogy megnöveli a TFLOPS-ot kb. 20-30%-kal., meg még pár helyen még előrelép, de egyik olyan új eljárás sem futtatható rajta, amit a fejlesztők a PS4-en kutattak és fejlesztettek ki annak reményében, hogy portolhatják máshova. Teljesen mindegy, hogy a hardver képes-e rá, ha a szoftveres réteg nem engedi meg elérni a szükséges adatokat és erőforrásokat. Ma messze ez a legnagyobb problémája a PC-nek nem a TFLOPS-ok hiánya.
Van egy érdekes fejlesztés a PS4-en, amit mindenki elkezdett. A baricentrikus fragment koordináták kinyerésével számos eddig alkalmazott effekt lenne felgyorsítható. Ott vannak a rendszer által generált adatok a regiszterekben és a gyorsítótárakban, de nem érhetsz hozzájuk, mert el vannak zárva. A PS4-en azért lehetséges az elérésük, mert a GNM API megengedi. A fejlesztők számára is elég gáz, hogy tudják, hogy az adatot amire szükségük tárolja a hardver, csak nem férhető hozzá. Ezen a mostani hardverek modernizálása nem segít, pont ugyanabban a pöcegödörben tartja majd a PC-t, ahol van, csak ad egy extra szappant a fejlesztőknek, hogy mosakodjanak.[ 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
Jack@l
#13144
üzenetére
A PC gaming legnagyobb gondja pusztán a grafikai rendszerek működése szempontjából, hogy igazából még mindig egy rendkívül egyszerű modellt használ, itt van egy alapvetően leképzett kép, amit számos post-process és offscreen trükkel feljavítanak. Ezeknek a trükköknek az az előnye, hogy nem kell hozzájuk extra rajzolási parancs, de a hátrányuk az, hogy mindig hamis eredményt adnak, mert screen space megoldások, vagyis az információtartalom csak a kamera nézőpontjából biztosított. Ezen nem tudunk továbblépni, mert az elterjedt PC-s API-knak nincs meg a batch teljesítménye ahhoz, hogy olyan effekteket használjanak a fejlesztők, amelyeket a filmes CGI-nál bevetnek. Pedig igazából ezekre a számítási teljesítmény már sokszorosan megvan a GPU-kban, csak nem ér semmit, ha nincs meg a szükséges throughput teljesítmény az API-ban. Amíg ez nem változik meg, addig továbbra is a trükkökre vagyunk kényszerítve. A konzoloknál, illetve a PS4 GNM API-nál a batch teljesítmény nagyjából a hússzorosa a PC-s szintnek. Ezért tud az ICE Team a PS4-en három lépcsős cascaded voxel cone ray tracing globális illuminációt csinálni 30 fps-sel, miközben a PC-n egy GTX 980-nal 20 fps-ed van csak egylépcsős megoldással. A TFLOPS semmit sem ér, ha a szoftveres réteg nem engedi elérni a számítási teljesítményt.
[ 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
Jack@l
#13153
üzenetére
Nagyon sokan használják a konzolon a tesszellációt. Csak nem úgy mint PC-n. A GNM API tesszellációs pipeline-ja lehetővé teszi a jó minőségű adaptív tesszellálást. A hardveres tesszellátorok is jóval fejlettebbek, mint a DX11 bevezetésénél, csak ennek a PC-n nincs jelentősége, mert a Microsoft a DX API-ban nem engedi meg a nem szabványosított tesszellációs módok használatát, azaz hiába vannak ott a jobb opciók az összes mai PC-s hardverben. A konzolon ilyen gond nincs, ott fix a hardver, amit tud, azt elérhetővé lehet tenni. A PC egyébként ebből akkora hátrányt nem fog elszenvedni, mert szinte mindegyik tesszelláció megoldható compute shaderrel, szóval ha nagyon nincs más megoldás, akkor a PC-n a fejlesztők írnak egy szoftveres tesszellációt. Maga a koncepció biztosan működik, mert a CIV BE is szoftveres tesszellációs rendszerre váltott a hardveresről, utóbbi túl limitált a szabványos PC-s API-k alatt, így számos mikroháromszög keletkezik, amit nem lehet elkerü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
Jack@l
#13157
üzenetére
Az a baj, hogy az NV egylépcsős megoldása nem elég, ahhoz még mindig kell előre számolt adat. Ráadásul az sem fut olyan gyorsan, mint a PS4-en a háromlépcsős megoldás. A DX11-et egyszerűen nem erre találták ki, és ez akadályozza a PC-n a voxel cone ray tracinget akármilyen adatstruktúrával. Természetesen jó, hogy hozott hozzá a GM204 egy viewport index rendszert, de ezt a funkciót a GCN már 2011 decembere óta tudja, csak nem számít, mert az API miatt akkor sincs aszinkron compute és túl drága az állapotváltás, ami ehhez a GI megoldáshoz kell. Amíg ezt a két problémát a szoftveres oldalon nem oldjuk meg, addig nem lehet mit kezdeni a VGA-kban a TFLOPS-okkal. Pontosan ezért látod az egészet csak technikai leírásban, vagy egy mindössze egy komplex objektumból álló, mindenféle komplex mozgást nélkülöző, egylépcsős GI-t alkalmazó demóban. Másra PC-n nincs lehetőség, mert az API nem engedi meg. És amíg az API nem engedi meg, addig komplex játékban sem fogod látni.
Az UE4-be berakott újszerű soft shadow technika nem akkora durranás. Az alapjait a Harada fejlesztette ki az AMD-nél, és az UE4 átvette egy tényleges effektnek, de ugyanaz a célja, mint más soft shadow megoldásnak, csak bizonyos szempontból jobban működik, nem feltétlenül kell hozzá temporal post-process, hogy az árnyékok egyenletesen legyenek. Kétségtelenül hasznos fejlesztés, de csak az árnyékokra vonatkozik a sugárkövetés, és igazából nem tekinthető forradalminak sem.
[ 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
Jack@l
#13164
üzenetére
Maga a voxel cone tracing GI-ra való alkalmazásának kutatása jó egy évtizedes múltra tekint vissza, szóval ez nem újdonság. A gond az, hogy az eredeti koncepció SVO adatstruktúrára épült, amit nem lehetett igazán jól megoldani a GPU-kon. Innen jött elő az az ötlet, hogy a 3D-s textúra jobb alternatíva a GPU-knal, így az SVO adatstruktúra lecserélhető például kaszkád 3D-s textúrázásra. Ennek az volt a gondja, hogy a voxelizációs fázis, így is sok időt igényelt, mivel legalább fél tucat nézőpont kellett a jelenetről, hogy azt voxelizálni lehessen. Az ki volt zárva, hogy a GPU-k fél tucatszor számoljanak geometriát, ezért a geometry shader került előtérbe, ami viszont még így is lassú volt, de technikailag kivitelezhetővé vált a rendszer. Végül 2012-ben sikerült összerakni egy olyan hardveres alapot a Tahiti GPU-val, aminek volt PRT-je a kaszkád 3D-s textúrázáshoz, illetve viewport index támogatása, hogy ugyanarról a jelenetről több nézőpontot is lementhessen a voxelizáláshoz. Ez volt az első olyan koncepció, ami reálisan karnyújtásnyira hozta a valós idejű alkalmazását. Viszont a szoftver még ezt is akadályozta, ugyanis rendkívül sok állapotváltásra volt szükség a működéséhez, amihez még ma sincs elég processzoridő. Jelenleg ott tartunk, hogy a kaszkád 3D-s textúrázás jó adatstruktúra, főleg ha van viewport index, de az állapotváltások behatárolják a teljesítményt, mert nincsenek elég gyors processzorok. Innen két irány van, vagy hirtelen előrántunk olyan CPU-kat, amelyek a mostaniak egyszálú teljesítményének a háromszorosát tudják, vagy előhúzunk olyan API-kat, ahol az állapotváltás kezelése a processzoridő szempontjából nem jelent lényeges terhet. Plusz, ha már itt tartunk, akkor számolhatnánk többlépcsős GI-t. Utóbbit azért nem tesszük meg, mert nincs aszinkron compute a mostani API-kban, így mindegyik lépcső egymás után fut le a GPU-n. A PS4-en a három lépcső egyszerre fut le. Kvázi ez egy párhuzamosítási forma, amire még lehetőség lenne.
Az Unreal Engine 4 jelenlegi globális illuminációs rendszere az Enlighten. Opciós lehetőség az Unreal Engine 3 nagyon hasonló Lightmass koncepciója, de ennél az Enlighten jobb, és gyorsabb is, ezért nem sokan élnek ezzel az opcióval. Mindkét GI opció a belépőszintet képviseli, ennél már ma vannak jobban a játékokban. Például a CryEngine LPV-je jobb. A GI szempontjából egyébként a Glacier 2 motor LPV rendszere eddig a legjobb.
[ 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
Crytek
#13165
üzenetére
Az UE4 elég jól optimalizált motor összességében. Még ahhoz képest is, hogy bevalottan egy mobil first koncepcióval született a rendszer, tehát a célpiac egyértelműen az Android/iOS/WP. A konzol és a PC másodlagos, de ez inkább üzleti megfontolás, mert az Epic nagyobb hasznot remél, ha a Unity motor licenckoncepcióját járják. PC-n már úgyis nagyon keves top stúdió vesz kész technikát, inkább fejlesztenek egy sajátot.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13174
üzenetére
Több tényező. Először is a tabletek luxusszintjét elviszi az Apple. Ide androiddal nehéz betörni. Másodszor nyilván nem olcsó, bár a 25 dollár annyira nem drámai ár. A Qualcomm sem adja olcsóbban a saját top megoldását. Viszont a Qualcommnak vannak csomagajánlatai, és azzal már olcsóbbak bárkinél. Harmadrészt pedig az NVIDIA számára nagyon káros, hogy az OpenGL le van maradva. A Tegra X1 képességeinek a 60-70%-a kihasználhatatlan OpenGL ES 3.1+AEP-ből. Szimplán az API nem teszi elérhetővé a funkció hozzáférhetőségét. Hiába fejlődik a hardver, ha a szoftveres réteg buta mint a tök. A gyártók is azzal kalkulálnak, hogy a következő évben is az OpenGL ES 2.0 fog dominálni, tehát nem kell okosabb hardver, így inkább az olcsót választjá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
Jack@l
#13175
üzenetére
A mediabox simán lehetséges, mert ott jóval kisebb a verseny és arra a területre a Qualcomm és a Mediatek nem koncentrál. A tablet szempontjából viszont látszik, hogy azok a menők, akik csomagot kínálnak. Lásd Qualcomm és Mediatek. Ezekkel csak úgy lehet versenyezni, ha eldöntöd, hogy elkönyvelsz egy rakás veszteséget évente, mint az Intel. De az NV-nek ez nem logikus.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13178
üzenetére
Igazából tehetnének érte. Már rég kellett volna csinálniuk egy saját grafikus API-t. Nem muszáj ultrabrutál low-level, bár ha már lúd, akkor legyen kövér, de egy Apple Metalhoz hasonló API nekik úgy kellene, mint egy falat kenyér. Sokkal jobb pozícióban lennének, ha azokat a fejlesztéseket, amelyeket bemutatnak a programozók konkrét szoftverben ki is használhatnák. Így viszont megint bemutattak egy UE4 demót, mint a Tegra K1-nél, és ennyi. A programfejlesztők költségeit jelentősen redukálni kellene egy új API-val, különben nem fognak hozzányúlni ezekhez az új hardverekhez. És ez másra is igaz az androidos vonalon.
[ 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
Crytek
#13180
üzenetére
Nyilvánvaló, hogy tudnak a problémákról, azt is tudják, hogyan kell egy API-t írni. Viszont szerintem nem sokan gondolták ebben az iparágban, hogy lesz két cég, amelyek nem várnak Microsoft, Khronos, meg akárkire, hanem a saját kezükbe veszik a sorsukat. Ha visszautazhatna számos cég 5 évet az időben, akkor ma nekik is saját API-juk lenne. Viszont akkor úgy gondolták, hogy túl kockázatos a projekt és senki sem fogja meglépni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13184
üzenetére
A saját tabletet azért csinálták, mert az egy módosított Android és benne van az OpenGL 4.4, tehát nem OpenGL ES. Ez azért haladás számukra, csak más gyártót ez az irány nem érdekli, mert OpenGL 4.4-es alkalmazás nem kerülhet fel a Google Play-re. Egyébként ott van az NV_command_list kiterjesztés is. Igaz, hogy nem kompatibilis az OpenGL core specifikációval, illetve nem mobilba tervezték, hanem a professional piacnak, de használható, csak sokkal nehezebb lesz meggyőzni a fejlesztőket, mert egy Metal API-t olcsó támogatni, de egy OpenGL kiterjesztést, ami még a core specifikációkkal sem kompatibilis nem sokan vállalnának be, hacsak nincs nyomós indok rá.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Túl hardvercentrikusan közelítitek meg a kérdést. Idén is sokkal több változás lesz szoftveres oldalon, mint a hardverben. Persze jönnek új lapkák, de az igazi innováció nem itt lesz.
Csak mondok egy példát. Ma a játékokban a GPU-kat a HLSL-en programozzák. Ez a szabvány nyelv a shaderekre, de nem elég jó már.
Nyilván egy ideig még erre leszünk szorítva, ami részben alap a szabványosságnak, de már rengeteg kutatás megy arra, hogy a HLSL mellett legyen más alternatíva.Ha megnézitek az API-kat, akkor ma három lehetőség van: HLSL (DX), GLSL (OGL) és AMDIL (Mantle). A HLSL oké, az egy jó alap, míg a GLSL nem a legjobb, de csak azért, mert nincs referenciafordító az OGL-ben. Az AMDIL nyilván azért gáz, mert eléggé alacsony szintű, így erre csak nagyon kritikus esetben érdemes direkt kódot írni. Van azonban egy nagyon érdekes kutatás, hogy ne kössük a lehetőségeket feltétlenül egy shader nyelvhez. Ha valaki mondjuk C++-ban akar shadert írni, akkor írjon. És innen egy frontend fordíthat egy hardver közeli IL-re, amiből mehet a kód a hardverre. Ebben az irányban óriási lehetőségek rejlenek, mert az eddigieknél jóval komplexebb programok is futtathatók lesznek a GPU-n, illetve a HLSL korlátjai is mehetnek a levesbe.
Maga a modell prototípus szinten nagyon működik. A Nitrousban számos shader így van lekódolva, és a GDC-n mutatnak majd egy demót, ami megalázóan jó. A probléma viszont, hogy a magas szintű kód (ami jelen esetben Bolt C++) és a hardverközeli IL-ek között nincs egységesítés. A programba kell egy fordító frontend, ami fordít AMDIL-re, PTX-re, és az Intel, meg a többi gyártó vISA-jára. Ez működik csak jó fordítót nagyon nehéz írni, és időigényes is. Sokkal kedvezőbb lenne, ha minden gyártó ugyanazt a vISA-t használná, és akkor arra lehetne készíteni egy agyonoptimalizált frontendet, vagy akár használni a Clanget, és az LLVM-en keresztül elérhető például a HSAIL.
Az nagyon látszik, hogy kezdjük kinőni a HLSL-t, és egyre többen kacsintgatnak a C++ felé.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13293
Abu85
HÁZIGAZDA
TESCO-Zsömle
#13292
Abu85
HÁZIGAZDA
válasz
TESCO-Zsömle
#13292
üzenetére
Sőt, 4-5 év is. Pontosan ez az oka annak, amiért az AMD nem akarja követni a szabványosítási procedúrákat, mivel nagyon sokáig tartanak. Helyette elérhetővé teszik a saját megoldásaikat, amit aztán majd a szabványok idővel lemásolnak. A lényeg, hogy a fejlesztők aktuális problémáit gyorsan meg lehessen oldani, és a megoldás irányt mutasson a Microsoft és a Khronos számára. Ebből a teljes iparág profitál. Lásd jön a DX12 és az új OpenGL is, nagyjából arra a mintára, ami az AMD API-jában megjelent.
Távolról se higgyük azt, hogy az új API-k minden gondot megoldanak. Adnak egy jó alapot, amire lehet építkezni, és jönnek a következő újítások, amelyekre szintén jön szabvány, ami egy új alap lesz, amire ismét lehet építkezni, és így tovább.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem összehasonlítható a dolog a mai szinttel. A HBM működéséből eredően a széles memóriabuszra gyúr. Egy HBM memóriát 1024 biten lehet bekötni, és mivel 4 GB lesz rajta, ezért 4 HBM memória kell, ami 4096 biten van bekötve. Ha 8 HBM memóriát kezel egy lapka, akkor 8192 bites a memóriabusz, és így tovább.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Továbbra sem tudom miről van szó, de egy kacsintást megért. ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az NVIDIA é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.
