szoftver render FTW

"Az újkeletű pletykák alapján a 2011 vége felé megjelenő, Ivy Bridge kódnevű processzor grafikus magja már támogatni fogja a DirectX 11-es grafikus API-t is."

Amikor már DX12 vagy valami egészen más lesz a "menő"? De legalább a régi cuccok futni fognak rajta, ha nem lesz olyan inkompatibilis, mint a jelenlegi gma chipek driverei a megjelenésük után sokáig...

jancsiga

elég furán hangzik egy mondatban a "2011 vége felé" és a "már"

szerintem egyébként az Intel szépen csöndben várja az új generációs grafika eljövetelét. addig nem száll ringbe, mert hamar elkönyvelnék gyenge harmadiknak. de ha eljön a szoft render kora, akkor jó esélye van az élre törni...

[ Szerkesztve ]

A vér nem válik VAZZE!™

"egyre kevesebb stúdió engedhetné meg magának a saját motor fejlesztését. "

szerintem ez nem akkora, probléma, mert így talán sokkal kevesebb lesz a (technológiailag) szar játék, mert lesz mondjuk 5 király engine, amit mindenki licenszelne, és nyilván azt használnák, ami a legjobb (mint pl. anno a quake3 engine), és ahhoz, hogy a legjobb legyen folyamatosan fejleszteni kéne.

"As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1."

"A szoftveres futószalag visszatérése egyébként azt is jelentené, hogy egyre kevesebb stúdió engedhetné meg magának a saját motor fejlesztését, ami a nagyobb idő- és erőforrásigénnyel magyarázható."

Miért? Nehezebb CPU-ra programot írni mint GPU-ra?

Én örültem volna ha megjelenik a Larrabee. Végre írhattam volna egy rendes engine-t.

[ Szerkesztve ]

Eddig megírták az engine egy részét helyetted: Direct3D. Ráadásul az kötöttebb is mint egy teljesen szoftver render, amit azt jelenti, hogy a konkurencia kevésbé tud előnyt szerezni ha sokat fejleszt, egyedi megközelítéseket próbál. Ez az amikor árt a szabadság...

Épp az a baj, hogy kötött...

Csak kíváncsi leszek, mitől fog eljönni az az új generációs grafika, ha pont az Intel nem kezdi el nyomni konkrét termékkel. Ez így végtelen ciklus... nem szállok be a piacra vassal, mert nincs szoftver ami kiaknázná, szoftvert meg nem csinálunk rá, mert nincs elterjedt vas hozzá.

Szoftver Renderbe meg kell írni, azt amit eddig az API már tartalmazott. Nehezebbnek nem nehezebb, de időigényes és a befektetés is nagyobb. Nem mindenkinek tetszik ez. Sajna a mai piacokat erősen a pénz mozgatja.

[ Szerkesztve ]

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

De épp azért lehet rá olcsóbb fejleszteni, mert kötött. (Ugye erről volt szó, hogy miért félnek tőle a szoftveresek.)

Azért ez komoly pofáraesés.
A Nvidia most nagyot dobhat a Fermivel, az AMD meg a Fusionnel.

de mindegy, van különbség az átlag fészbuk user meg a terrorista között... az utóbbival lehet tárgyalni... (C) bambano

Nem, egyszerűbben fogalmazva az X86 önmagában sem a legjobb rendszer, grafikus dolgokat programozni rá sem a legjobb.

de mindegy, van különbség az átlag fészbuk user meg a terrorista között... az utóbbival lehet tárgyalni... (C) bambano

Egyébként miért lenne jobb a szoftveres renderelés? Anno épp hogy csúnyább volt a 3D-s API-khoz képest

[ Szerkesztve ]

De anno nem teraflops-class lapkák voltak.

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

Nem olcsó, nem olcsó... de nem mindenkinek ez a lényeg.

Szerencsére vannak olyanok is akik hajlandóak belevágni valami újba. Még akkor is ha kockázatosabb. Ugyanis reménykednek abban, hogy valami olyasmit alkotnak amit el tudnak adni.

A lényeg az, hogy egy sokmagvas CPU legyen a videokártyán. Az utasításkészlet kevésbé lényeges. Valószínűleg azért x86 utasításkészlet mellett döntöttek mert abba már az Intel is kellően beleásta magát, na meg rengeteg programozó is ismeri.

Én emlékszem arra is, hogy iszonyatos kompatibilitási problémák voltak sok esetben a most hőn áhított szoftveres rendernél. Ráadásul ha jól rémlik éppen azért lett egységesítve (illetve hát kétségesítve, hiszen OpenGL és D3D), hogy ne kelljen már a programozóknak minden egyes qrva gyártó qrva kártyájára külön megírni a játékokat.

Na nehogy már a szabvánnyal szembemenni annyira jó dolog. Ha mégis, akkor vásárolj angol elektronikai cuccot és használd itthon. Vagy még jobb példa az amerikai, ahol nem csak a dugó más hanem a feszültség is...

AMD Athlon64 II X4 620 @ 3.25GHz ; MSI K9A2 CF ; Sapphire HD4850 Vapor-X 512MB GDDR3 ; KingMax DDRII-800 4x1GB ; Seagate 320GB ; CoolerMaster RealPower RS-520W ; Gigabyte X5 ; Logitech Z-2300

senki nem mondta, hogy nem lesznek szabványok. kezdésképpen az x86 már egy egész jó "szabvány".

A vér nem válik VAZZE!™

a Larrabee utasításarchitektúrája és programozási modellje lenne a legmegfelelőbb a fix funkciós szintektől lekorlátozott DirectX-féle futószalagok leváltására.

Nekem ebből a mondatból az válik nyilvánvalóvá, hogy a microsoft keze van a dologban, nehogy véletlen le kelljen váltani a dx-et.

ElGuRuLt a GyoGySzErEm...VaGy CsAk FoRDíTvA VeTtEm Be?

Milyen hw-ek között volt inkompatibilitás? A GPU-k fixfunkciósak voltak, a prociknál meg max. az lehetett gond, hogy az Intel nem támogatta a 3DNow!-t, az AMD meg mindig némi késéssel az aktuális MMX-et és SSE-t. Vagy úgy érted, túl nagy különbségek voltak a procik között sebességben?

akosf: Lehetnek valakinek jó ötletei, de egy komplett motort nem biztos, hogy össze tud hozni a "sufniban", hiszen így még nagyobb munka. Így a kis cégek még nehezebben tudnak labdába rúgni a nagyok mellett, amik matematikusok és programozók hadát alkalmazhatják. Szóval, elég felemás ez a dolog.

orbano: Szabványnak szabvány, de hogy mennyire jó... Bonyolultabb dekódolást igényel: CISC->RISC, nem fix szélességű utasítás-szavak, stb. Bár pl. a Larrabee-n nem átlag x86-os kód futott volna többségben, hanem AVX.

mmdms: Titkos alkú a MS és Nvidia között? (Az AMD-t azért hagyom ki, mert ők ha akarnak, tudnak csinálni egy Larrabee-re hasonlító valamit. Az Nvidia viszont meg lenne lőve ezzel is, hiszen nem rendelkeznek sem x86, sem x64, sem SSE, sem AVX licenccel.)

[ Szerkesztve ]

Mondasz valamit

Én egyszer megnéznék egy Unreal Engine 3.0-ás játékot komoly grafikával.

"A szoftveres futószalag visszatérése egyébként azt is jelentené, hogy egyre kevesebb stúdió engedhetné meg magának a saját motor fejlesztését, ami a nagyobb idő- és erőforrásigénnyel magyarázható. Talán éppen ezért nem mindenki ért egyet Sweeney elképzeléseivel. Bár technikailag nem kifogásolható az elgondolás, anyagi szempontok miatt jelentősen megnő a fejlesztés kockázata."

Ebből meg az, hogy kevesli a licencdíjakból befolyó bevételt. Alapvetően mindegy, hogy kinek/minek a licencdíját fizetem meg a játék árában. Az Epic célja a jelek szerint az is, hogy a kisebb engine-fejlesztőket ellehetetlenítsék.

Si vis pacem, para bellum.

azért volt szebb mert célhardware.

Ha wgy durva "3DStudio szint" megy realtimeban 2020ban akkor melyik lesz a szebb?

Szerintem.... The things we make ... make us.  -~- ..And on the 7th day, GOD went windsurfing... Evina foglalkozás egészségügy www.evinakft.hu

Kevesebb lesz a saját engine? Már most is alig akad saját fejlesztés a stúdióknál, mindenki UE3-at használ.

"És robbanó tartály mögött vihorászni tűzharc közepén szerintem még a Nők lapja horoszkópja szerint sem jelent jót." /by MAZUR [GS'10J]

Úgy értem inkább, hogy még amikor megjelentek az első 3D-s játékok, akkor egyik helyen ilyen effekt hiányzott, mert nem tudta véghezvinni az eszköz (annak ellenére is, hogy támogatta az aktuális DirectX verziót). Legjobb példa erre talán az S3 sikerkártyája, ami megélt vagy 4 generációt és ráncfelvarrást (virge). De a Riva 128-ból is hiányzott pár fontos fícsör, mint pl. a fekete vonalak eltüntetése a poligonok illesztési határán. Vagy pl. ugyanezzel a kártyával az AVP 1 Predatorral álcázott módban úgy nézett ki, hogy fehér rizsdarabkák voltak a képernyőn. Szóval ilyesmikre gondolok én kompatibilitási gondoknál.

De hasonló volt a helyzet hangkártyáknál is. Nem kell túl messzire visszamenni, amikor még be kellett állítgatni a hangkártyát a játékoknál. Volt ott Sound blaster kompatibilis, SB 16, AWE 32 stb... és ez még csak a Creativenak a játszótere... Aztán jött a többi gyártó.

AMD Athlon64 II X4 620 @ 3.25GHz ; MSI K9A2 CF ; Sapphire HD4850 Vapor-X 512MB GDDR3 ; KingMax DDRII-800 4x1GB ; Seagate 320GB ; CoolerMaster RealPower RS-520W ; Gigabyte X5 ; Logitech Z-2300

De az nem szoftveres rendering volt... Hanem nem-szabványos fixfunkciós hw-ek.
Vagy nem értem, mire gondolsz.

[ Szerkesztve ]

Tehát xbox360-ra nem jön GoW3 bár a HALO-ról is lehúztak még egy bőrt

Én egyszer megnéznék egy Unreal Engine 3.0-ás játékot komoly grafikával.

Szerintem nem ez a célja. A cikkben csak Sweeney-ről van szó, nem az Epic-ről. Tim Sweeney hozzáállása pedig érthető, hiszen őt biztosan korlátozza a DirectX.

Abu: Nem lehet a DirectX-ből azokat a részeket átemelni, amik úgyis kellenének, és nem kell rajtuk változtatni?

A GoW 3 fejlesztése nem az Unreal Engine 4-től függ. Sweeney és csapata már befejezte a munkát az UE3-on, ettől függetlenül annyi játékot lehet rá csinálni, amennyit szeretne a stúdió. Mivel a jelenlegi konzolgeneráció életciklusa úgy 2013-2014 környékén ér véget, esélyes a GoW 3 xBox 360-ra.

T.Peter: Felépíthető a DX11-es futószalag szoftver renderrel. Bár ennek sok értelme nincs. Ha valaki ilyet szeretne használja az API-t.

[ Szerkesztve ]

A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

+1

http://prohardver.hu/tema/olaszorszagban_lakom_dolgozom_odavagyom_beszelgeto/friss.html#msg11

Valahogy épp ez fogalmazódott meg bennem.... ez az üzletről szól, kiszorítani a lehető legtöbb konkurenst, és megnehezíteni, hogy más, új szereplő beléphessen a piacra.

\\\\\\\\\\\\\\\\ ALLEZ AMÉLIE!!! - www.ameliemauresmo.hu //////////////// Videókazetták digitalizálása Xvid és DVD-Video formátumba olcsón, jó minőségben! Ha érdekel dobj privit!

Szerintem azt kellene, hogy megértsd, hogy akkoriban a 3D még igencsak gyerekcipőben járt. Habár már voltak kezdeti szabványok, mégis mind a hardveres, mind a szoftveres megoldások gyerekcipőben jártak és még nem igazán tudták használni sem azokat.
Amit dezz írt az sem elhanyagolható tényező, de végül is a gyakorlatban ez ugyanazt jelenti.
Mostanra természetesen van egy jól bejáratott út, amit a DirectX jelent a játékok területén és az OpenGL maradt a professzionális piacnak, habár még egyes játékok is használják. Ami a jövőt illeti ott az OpenCL és a szoftverrendering, ami ismét egy nagy változást jelentene. Valószínűleg ott is lennének kezdeti bakik, de a megfelelően erős hardver már meglenne hozzá gyakorlatilag. Mindez még akkor sem jelent olyan gondokat, mint amiket Te is említettél. Egyébként is! A ma megjelenő játékok 90%-a még a harmadik patch után sem tökéletes, de ez nem a technológia hibája.

[ Szerkesztve ]

Windows - buta tömegtermék, OSX - agyondesignolt sznob, Linux - kocka "lego"-rendszer. Nagy általánosságban, akkor melyik a jobb OS? ;)

Jaja, Nvidia elgondolás. Ne okosan oldjuk meg, hanem erőből.
Sokan belefulladtak már ebbe. Szerinted mi játszik le könnyebben egy mp3 zenét? Egy CPU vagy egy célprocesszor? Közben mekkora lesz a fogyasztáskülönbség?
Ilyen elgondolással vágjunk fát fűrész helyett 20db késsel.

[ Szerkesztve ]

de mindegy, van különbség az átlag fészbuk user meg a terrorista között... az utóbbival lehet tárgyalni... (C) bambano

Nem így gondoltam. Ezt írtad: "Szoftver Renderbe meg kell írni, azt amit eddig az API már tartalmazott. " Nem az egészet emelnék ki, hogy dx futószalagot csináljanak, hanem azokat a részeket, amiket ugyanúgy kell megírni, mint ahogy már megvan írva dx-ben. Vagy azokat azért nem használnák, mert tudnak jobb megoldást? Hogy fog így elterjedni a szoftveres renderelés, ha például azok, akik nem akarnak mindent önerőből megírni, továbbra dx-et fognak használni? Annyival jobb motorokat fognak írni egyéni futószalaggal, hogy muszáj lesz áttérnie mindenkinek? Ha már itt tartunk, a voxeles grafika mikor fog elterjedni?

Szerinted mi alkalmasabb egy új effekt megvalósítására, az MP3-at lejátszó célprocesszor vagy egy CPU?

szerk: Ilyen elgondolással csak fűrészt gyártsunk mert mindenki fát akar vágni.

[ Szerkesztve ]

A fo kepesege az OpenGL es DX API-knak pont az volt, hogy a hardverek kulonbsegeit es bugjainak a nagyreszet eltuntettek a fejleszto ellol. A teljesen szoftveres megoldas eseten ugyan ugy le kell majd jatszani, minden kartya minden reviziojahoz, sot talan meg driver verziokhoz is.
Az OpenCL es a DX11 Compute Shader megoldasai talan eltuntetik ezek egy reszet, visszont az sem lesz teljesen szabad.

A legfajobb pont valoszinuleg a kompatibilitasi reteg, azon lehet sokat nyerni teljesitmeny szempontjabol. Erdemes megnezni, hogy egy C forditto milyen bajtkodot forditt egy sima FOR ciklushoz osszevetve egy ugyanolyan, de kezzel ASM-ben megirt FOR ciklushoz kepest. Nagysagrendileg lesz komplexebb a C-s valtozat, sot a komplexitas nagyreszere az esetek jelentos reszeben folosleges teljesitmeny korlat. Grafika esten ez a kulonbseg meg durvabb.

Szoval a teljesen szabad megoldas eseten garantalt lenne, hogy mindeki olyan kartyat vegyen amit a fejlesztok hasznaltak, ugyanazzal a driverrel, aztan cserelgesse a felhasznalo.
Bar valoszinuleg a kedeves EPIC-es emberke megnyilvanulasa a konzol piacra valo koncentraciot vetiti elore, ott 10 evig nem valtozik a hw es a sw sem nagyon, igy ki lehet hagyni a tobbi kartya bugjanak az elfedeset.

OpenCL es DX11CS eseten legalabb van nemi esely a kompatibilitasara meg ha nem is lesz tul gyors. Aztan persze ellenorizni, hogy milyen fix egysegek vannak meg es tudni, hogy mikor gyorsabb azt hasznalni vagy szoftveresen szimulalni.

SCJP 6

Igaz, az tényleg nem szoftverrendering volt. Ott kicsit bekeveredtem

ElEvEn11:
Általában nem a grafikai megjelenítést érinti óriási változás, hanem a süket AI-t, meg egyéb bugokat.

[ Szerkesztve ]

AMD Athlon64 II X4 620 @ 3.25GHz ; MSI K9A2 CF ; Sapphire HD4850 Vapor-X 512MB GDDR3 ; KingMax DDRII-800 4x1GB ; Seagate 320GB ; CoolerMaster RealPower RS-520W ; Gigabyte X5 ; Logitech Z-2300

Ez így jó is lenne, csak sajnos a licensz sem olyan olcsó, hogy sokan megvegyék, és ezért a kisebb nevek kiesnének a játékiparból, mert esélyük sem lenne megvenni/fejleszteni egy motort.

EVE Online - No Mutants Allowed! - H0rr0r Vacui Alliance

Egy célprocesszor az effekt számára.

Nem, ilyen elgondolással minden munkához azt használjunk, amit arra gyártottak.
Esetleg létre lehetne hozni PC szinten a SOC megoldást, mindent a processzor old meg, és mindent szoftveresen kell megoldanod.
Bár a SOC sem tökéletes példa, mert a legtöbb ilyen rendszerben csak az ARM processzorral dolgozol, a többi egységet meghajtod driverrel, és nem emulálsz.

[ Szerkesztve ]

de mindegy, van különbség az átlag fészbuk user meg a terrorista között... az utóbbival lehet tárgyalni... (C) bambano

Egy célprocesszor kifejlesztése egy nagyságrenddel drágább és jóval több időbe kerül mint egy CPU-ra leprogramozni. Ráadásul, minden egyes új elgondoláshoz új célprocesszor kellene...

úram atyám, tu tudjátok egyáltalán már, hogy mi a francről beszéltek? SOC? Emulálás? WTF?
Abu, már elmenekültél?

A vér nem válik VAZZE!™

Olvasd el, miről van szó, mielőtt hőbörögsz. Gyanítom, ez kimaradt.

A mondanivalóm lényege az volt, hogy jobb egy arra a területre kifejlesztett célhardver, mint a szoftveres megoldások (emulálás, renderelés, stb.).

Úram?

[ Szerkesztve ]

de mindegy, van különbség az átlag fészbuk user meg a terrorista között... az utóbbival lehet tárgyalni... (C) bambano

én teljességgel értettem miről beszéltél, de sem az állításoddal, sem az érveléssel nem értek egyet. célhardver az van most, a DX11-gyel körülbelül elérte a korlátait. A jövő real-time algoritmusai már nem működnek célhardvereken, azoknak igenis rendes processzor kell, méghozzá jó sok. És ehhez nem kellenek jósok...

A vér nem válik VAZZE!™

Jahh, így van ez pl. a Cell procival is, összetettebb algoritmusoknál kb. 5x GPU-s flops-nak felel meg a teljesítménye.

Viszont, nem biztos, hogy a Larrabee architektúrája lesz a befutó... Kenterbe ver egy sima procit, de egy GPU ellen kevés... Épp ezért törölték az aktuális verziót is. De ha nem változtatnak az architektúrán, minden csíkszélességi lépcsőfoknál ugyanez lesz a helyzet... Lassan rájönnek, hogy mégis csak a Cell architektúrája (vagy valami ahhoz nagyon hasonló) a legjobb út... Az ugyanis 2-3x hatékonyabb. Hogy nehezebb programozni (értsd: nem annyi, hogy egy recompile)? Hát, valamit valamiért.

Az Intel hülyesége ez az elgondolás. Mindent X86-on kell megoldani.
Kár, hogy ez a legtöbb esetben hatalmas pocsékolás. Nem ok nélkül kerülnek a szuperszámítógépekbe grafikus maguk tömkelegei. Ugyanis bizonyos számításokat (lebegőpontos) röhögve elvégez egy GPU, amihez kellene egy vödör X86 processzor. Felépítéséből adódóan csak sokkal nagyobb pénz és energiabefektetéssel tud hasonló képességeket felmutatni.
A Larrabee is ott bukott meg, hogy már most elvérezne egy egymagos GPU mellett a maga 32!!! magjával.
Sokkal életképesebb az Nvidia Fermi elgondolása. Valószínűleg ők találják el, mi a jövő. Vagy ott a Cell, ami megint előremutató rendszer, csak még mindig nem prezentálják megfelelően.
Az X86 amúgy igencsak korlátolt rendszer, sok dologban egy ARM is jobb nála. Egyszerűen alkalmasabb bizonyos területekre. Nem tudom anno hol olvastam, hogy egy ARM multimédiás képességei is nagyságrenddel jobbak, mint egy x86-é, és ugyanahhoz a dologhoz kevesebb energiát igényel.

[ Szerkesztve ]

de mindegy, van különbség az átlag fészbuk user meg a terrorista között... az utóbbival lehet tárgyalni... (C) bambano

A Larrabee-nek csak az egyik baja, hogy x86-on alapul. Ez önmagában még nem olyan hatalmas probléma, mivel az x86-os (+ x64 + SIMD-ek) kód átfordításra kerül egyfajta RISC kódra, és a továbbiakban azzal dolgoznak a magok. Bár ehhez szükség van egy összetett dekóder egységre (itt magonként), ami szintén foglalja a helyet.

A másik dolog, ami talán fontosabb, hogy itt minden mag a szokásos CPU-s felépítést követi, ami cseppet sem hatékonyabb azoknál, ha nem teljesen általános integer kódról van szó, hanem elsősorban számításokról. Hiába van 32db belőle, 32 proci sem ér fel egy kisebb GPU-val sem ebben.

Ezen belül az egyik dolog, hogy a szokásos cache memóriával operál, ahol egy bájt hasznos adathoz több bájt kiegészítő információt is el kell tárolni. Ellenpélda: a Cell prociban sima (statikus) RAM memória van az SPU-k mellett (jelenleg 256kB/SPU). Így ugyanakkora területen többszörös tár helyezhető el.

A másik, hogy a Larrabee-ben minden mag a CPU-knál szokásos módon címezheti és férhet hozzá a külső memóriához. Ez jót tesz a kényelemnek és a könnyű programozhatóságnak (sok kód változtatás nélkül futtatható), azonban cseppet sem erőforrás-kímélő, nem kényszeríti rá a programozókra az optimálisabb kódolást, és az előbb említett, szokásos, nem helykímélő cache mechanizmust is igényli.

Harmadik, hogy mivel még a kisebb L1 cache (10-20 kB) is sok helyet igényel, bonyolult és ugyancsak nem helykímélő ugrás-becslő logikára van szükség a L2-höz, vagy épp külső memóriához való hozzáférések számának csökkentése érdekében. A Cell SPU-i esetén erre nincs szükség.

Így lehet 1-1 Celles SPU a hozzátartozó srammal együtt is jóval kisebb, mint 1-1 Larrabee-s mag -> azonos területen jóval több fér el belőlük -> jóval nagyobb hatékonyság.

[ Szerkesztve ]

"Nem lehet a DirectX-ből azokat a részeket átemelni, amik úgyis kellenének, és nem kell rajtuk változtatni?"

dehogynem, a microsoft bárkinek odaadja 15 év munkáját ingyen és bérmentve, csak kérni kell