Hirdetés
Új hozzászólás Aktív témák
-
#65675776
törölt tag
válasz
bitblueduck #4 üzenetére
Jelenleg csak a Llano és majd a Trinity lesz az, amely számára jelent is valamit a magas memória sávszélesség. A többi architektúrának ugyan mindegy.
-
MCBASSTION
aktív tag
mellesleg most néztem h a 2010 júniusi dx sdk-ban is van ilyen (hdrtonemappingcs11), habár ott nincs ennyire markáns sebesség növekedés... bár igazából ua-t csinálják, csak parallel reductionnel számolják az avg lumot.
-
Srodney
senior tag
talán inkább jobb igp kellene...
-
MCBASSTION
aktív tag
ja bocsi
azt hittem h az arra vonatkozik, h tonemapping + bloom. azért tűnt úgy mintha az intel szerint ez új lenne... na mind1
köszi, remélem fenn lesz, ezért utálom ezeket a rendezvényeket, mert oda kéne utazni meg minden, a fizetni az még hagyján, hiszen idő előtt megkapod a cuccot (és valszeg a teljes doksit mellé)...
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz
MCBASSTION #29 üzenetére
Oda is írtam, hogy abban "alapvetően semmi új nincs".
Szerintem fel fogják rakni a példaprogramot. Valszeg, aki fizetett a SIGGRAPH-on a belépőért az már megkapta. Ennyi előny azért nekik jár, ha már pénzt költöttek az eseményen való részvételre, de mindig minden felkerül pár héttel később.[ Szerkesztve ]
-
MCBASSTION
aktív tag
"Az Intel a HDR implementációját tone mapping és bloom segítségével oldotta meg. Ebben alapvetően semmi új nincs. A tone map használata lehetővé teszi, hogy a fénnyel kapcsolatos számítások a kimeneti formátum limitált tartományát meghaladják, illetve opció lehet a túlexponálás. A bloom nehezebb ügy, és jóval több számítást igényel. Az Intel ezt két részre osztotta. Először egy úgynevezett bright fázis fut le, ami kiemeli a fényes részeket a képből, majd a kód négyszer megfelezi az eredmény felbontását. Ezután mindegyik kapott képen lefut egy gaussian szűrő, ami az elhomályosításért felel, majd a kisebb felbontású eredmények hozzá lesznek adva a nagyobb felbontásúakhoz."
ez eddig is így ment"A compute shader a tone map esetében az átlagos logaritmikus fénysűrűséget számolja, mindezt mozaikokra osztott képen a helyi adatmegosztásra támaszkodva. Az Intel lényegében itt nyeri a tempóelőnyt a pixel shaderes algoritmushoz viszonyítva."
na itt a lényeg, erről van vmi papír? ha jól értem akk csak annyi h az avg lum nem egy mimap levelből jön hanem a compute shader kiszámolja per-tile. -
Angel1981
veterán
válasz
fatallerror #25 üzenetére
Aludj egyet, és térj vissza!
-
fatallerror
addikt
basszus olyan fáradt vagyok h nem bírom ezt végigolvasni pedig másodjára próbálom és érdekel, vki leírná 1-2 mondattal a lényeget?
-
Abu85
HÁZIGAZDA
A Linux az más Intelen. Windowsra az Intel csinálja a drivert. Linuxra csak open source támogatásuk van. Ergo az Intel (az NV-vel és az AMD-vel ellentétben) nem kínál Linuxra zárt drivert, ahova meg tudnák venni az S3TC licencet. Open source pedig csak open dolgot támogat, vagyis az S3TC-t használó programok (Unigine benhcmarkok például) el sem indulnak open source driveren.
A Linuxon tehát sok dolgot kell rendbe rakni, mert az open felfogás a használhatóság rovására megy. Márpedig ezen nem hajlandó változtatni a Linux közösség, így az Intel is rá lesz kényszerítve a zárt driverek fejlesztésére. Az open közösség a zárt formátumok leváltásában bízik, amire az S3TC esetében van lehetőség, hiszen az ASTC egész jó alternatív irány, de ez évekbe telik majd.[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz
Alchemist #15 üzenetére
A hardver az Ivy-ben egész jó. A Sandy-ben lévő az valóban csapnivaló, de ez Gen7 architektúra egész kellemes. Látszatra jól skálázható és relatíve erős compute-ban. Ahol gyenge az a setup és a ROP, meg irritáló a stream out megvalósítása, de a Sandy-hez képest az is előrelépés. Ha erre a három területre rágyúrnak (főleg a setup és a ROP a fontos), akkor már csak a szoftveres részt kell megreformálni, hogy az NV ne tarthasson előadásokat, ahol ecsetelik a partnereknek, hogy 10-ből 3 játékban grafikai hibákat találni az Intelen. Na meg nyilván a felhasználónak is érdeke az, hogy jó legyen ez a rész. Főleg fontos az OpenGL driver, hogy végre jól/gyorsan fusson a Minecraft.
[ Szerkesztve ]
-
Angel1981
veterán
"Az elmúlt évben az Intel kijelentette, hogy az IGP-k jól tehermentesíthetők, ha számos grafikai effektet a processzor számolna."
Ezt szerintem max. ők hitték el....
Az egész koncepció az volt, hogy az IGP tehermentesítse a CPU-t. -
Abu85
HÁZIGAZDA
Az alaplap mérete kicsi. Ha egymás mellé pakolod őket, növelni kell az alaplap méretét, ami egyenesen az akkumulátor méretének csökkentéséhez vezet. Ez a vékonyítás átka. Vagy üzemidő, vagy teljesítmény, de a kettő együtt nem megy. A legvékonyabb notikban már nincs is SO-DIMM. Egyszerűen rá van rakva a memória az alaplapra, jellemzően egycsatornás kivitelben. Az Intel erre gondol majd a Haswellnél és az ultrabookokba tervezett legkisebb platformdizájn úgy lesz kialakítva, hogy elve le van tiltva a kettőből egy memóriacsatorna, így a tokozás is kisebb lesz. Ez logikus dolog, mert a nagyon vékony termékeknél úgy sem használják ki a kétcsatornás memóriát a partnerek.
[ Szerkesztve ]
-
ngabor2
nagyúr
válasz
bitblueduck #4 üzenetére
én se értem, hogy a vékonysággal hogyan függ össze a 2 helyett 1 memóriafoglalat. simán lehet őket egymás mellé is pakolni, nem kell egymás fölé. azzal meg ne akarják már megetetni a népet, hogy így spórolnak vele egy rakást... elég nehezen tudom elhinni, hogy 2 slot esetén annyival több vezeték kell, hogy az egész alaplapot újra kell tervezni, vagy 2-3 réteggel vastagabb nyák kell.
-
Rover623
félisten
válasz
bitblueduck #4 üzenetére
fantasztikus ez a fejlődés.
Az...meg az is, hogy a "brand" asztali gépek többsége is egyetlen modullal kerül piacra, és így is kerül ki a felhasználóhoz... -
Abu85
HÁZIGAZDA
Lényegtelen dolog. Ma már mindenki tudja, hogy a HDR mire való. A minősége paraméterezhető. Az Intelnél programozók dolgoznak nem dizájn szakemberek. Nyilván nem teljesen hülyék a dizájnhoz sem, de az biztos, hogy nem azért fizetik őket, hogy jól nézzen ki a sample-ben az effekt. Ebből kifolyólag ezek a sample-ök sosem lesznek olyan minőségűek, mint amilyenek egy játékban. Jelen sample célja, hogy megmutassa hogyan lehet a HDR-t a compute shader bevetésével gyorsítani (van benne példaprogram és forráskód). A játékok programozói ezt átveszik, esetleg gyúrnak rajta, majd a dizájn szakemberek megmondják, hogy milyen paraméterezéssel kellene használni. A kód azonban adott és gyorsít. Ez a lényeg.
Véleményem szerint elég korrekt megoldást dolgozott ki az Intel. Persze lehet azzal jönni, hogy a +13% az nem sok, de ha a minőség nem szenved csorbát, akkor nincs ellene érv. Szerintem az a baj az AMD és az NV partnerprogramjával, hogy nagyon újítanak. Az AMD olyanokat dolgoz ki, mint a forward+ lighting, a compute shaderes VPL-GI, HDAO, CHS, MLAA1/2, FXAA ... az NV manapság elfordult a compute-tól, de vannak diffuse/bokeh DoF effektjeik (még a Fermi időkből). Ezek baromira jó dolgok, de nem gondolkodnak azon, hogy a compute shaderre nem csak ezek az esetenként bonyolultabb effektek gyorsíthatók, hanem régóta alkalmazott dolgokat is reformra lehetne vinni. Az Intel most ezt csinálja, és látszik, hogy nem hülyeség.[ Szerkesztve ]
-
Ed3r_X_
nagyúr
Na az Intelnek is csak volt AMD-s segítséggel megy a normális IGP gyártása?
Na jó ez kicsit gonosz volt, de majdnem
-
maross
nagyúr
-
JoeYi
őstag
+ én értem a HDR funkcióját. Egy játék akkor élethű, ha olyan mint a valóság, pontosabban ahogy a valóságot érzékeljük. HDR-ben pedig max kamerán keresztül láthatjuk a világot
-
maross
nagyúr
Ez a hdr off - hdr on kep olyan, mintha brigthness 50 - brightness 60 lenne a kepen.
Új hozzászólás Aktív témák
ph Mégsem olyan hatékony a processzor a grafika számítására?
- Majdnem banki adathalász csalás áldozata lettem.
- Sony MILC fényképezőgépcsalád
- Autós topik látogatók beszélgetős, offolós topikja
- RAID
- LED világítás a lakásban
- Samsung Galaxy S24 - nos, Exynos
- Elkezdte felszámolni a GPU-s PhysX támogatását az NVIDIA
- PlayStation 3
- Vezetékes FÜLhallgatók
- Poco F6 5G - Turbó Rudi
- További aktív témák...