Hirdetés
Új hozzászólás Aktív témák
-
oO7
őstag
8-16-32 vagy akár 64 mag még mindig meg sem közelíti a GPU-kban található több ezer végrehajtóegységet, és nagyon fontos tényező, hogy ezek CPU esetében független magok, azaz egy esetlegesen párhuzamosítandó feladathoz rengeteg erőforrást kellene elpazarolni a szinkronizálásra...
-
Pikari
addikt
szerintem tehetünk a cpuba egy textúracímző utasítást, meg a mostani 8 maghoz még 8-at, és akkor az cpu marad, viszont remekül lehet vele renderelni, sokkal remekebbül lehet általános célú számításokra használni, mint bármilyen gput, tehát végsősoron előbbre lennénk.
amúgy mindjárt küldök egy privit, mondok benne egy érdekességet
-
oO7
őstag
azért 15 év alatt fejlődött "egy keveset" a technológia, és ha azt mondjuk, hogy a CPU-k 100x gyorsabbak/erősebbek lettek, akkor a GPU-k 1000x vagy 10000x...
a mai processzorok azok ilyen ~50-100GFLOP nagyságrendű teljesítménnyel rendelkeznek, a GPU-k meg már TFLOP tartományban mozognak... és a GPU-k "kihasználható teljesítményén" még plusszban nagyon sokat fog javítani a kiforrott heterogén architektúra, és egy esetleges közös ISA...P1-es játékok linkelgetése nem bizonyíték a kijelentésedre... DirectX-et is lehet szoftveresen emulálni, csak épp nem éri meg...
vagy ha eltekintünk a GPU vagy IGP elnevezéstől, és azt mondom, hogy sok sok végrehajtó egységből álló SIMD blokk? úgy már közelebb állunk a megegyezéshez?
[ Szerkesztve ]
-
Pikari
addikt
a valóság teljességgel ellentmond a könnyelmű kijelentésednek
http://en.wikipedia.org/wiki/Croc:_Legend_of_the_Gobbos
megjelenés: 1997
233 mhz pentium1 szoftveres rendereléssel, vagy 166 mhz-s pentium1 voodoo1-el
Outcast
http://www.metzomagic.com/images/2006/Outcast2b.jpg
megjelenés: 1999
366 mhz pentium2, szoftveres rendereléssel, a játékban használt effekteket 1999ben hardveresen ki sem lehetett volna renderelni
az, hogy TE nem tudnád soha az életben kirenderelni ezeket a játékokat egy modern gépen, az egy dolog, de a saját képességeidből a világ működésére vonatkozó komolyabb relevanciákat ne vonj le.
azóta kb 20x gyorsabb egyetlen mag, és van belőle általában 4. gondold újra. -
oO7
őstag
mindkettőre szükség van... tisztán CPU-ból soha a büdös életben ki nem renderelsz még egy 15 évvel ezelőtti grafikát sem... mellesleg ha szépen elkezdik használni a GPU-t általánosabb feladatokra is (tömörítés, videókódolás, vagy csak egyszerűen alkalmazásokon belül listaműveletek végrehajtása, vagy úgy kb bármi ami párhuzamosítható), akkor nagyon is meg fog látszódni a haszna... mellesleg lényegében azon a szinten állunk jelenleg, hogy CPU-ból nem kell több mag, nem kell több erő... nincs és nem is lesz ami kihasználja... kizárásos alapon marad a GPU amiből viszont embertelen mennyiségű teljesítményt lehet kisajtolni és azt fel is lehet használni "hagyományos" grafikus műveletekre, de a korábban felsorolt példákra is, vagy épp hangfelismerés, alakfelismerés, kézírásfelismerés, stb...
kell az... nem, hogy kiváltani nem tudja az egyik a másikat, de még csak aranyközépút sem létezik a kettő között... illetve hát az aranyközépút az amit az APU-kkal csinálnak... közös memória, közös pointerek, megosztott cache, meg ilyenek...
-
dezz
nagyúr
Ahhoz képest egész sokáig elzenélgettek együtt... Csak úgy eltűnni semmiképpen sem fog, hiszen szükség van a funkcionalitására és energiahatékonyságára bizonyos számítások tekintetében. Hanem, ahogy te is írod, beleolvad majd a CPU-ba, de az a CPU már nem ez a CPU lesz... Szerintem nem is CPU lesz a neve, hanem talán végleg meghonosodik az APU, vagy valami más hasonló. Több kell ehhez, mint egy AVX2.
-
Pikari
addikt
nem akarok túlzottan messzemenő jóslatokba belemenni, de ahogy mondani szokás: két dudás nem fér meg egy csárdában, ez a csárda pedig jelen esetben a számítógép, a két dudás pedig a cpu, és az igp. egyik kell, hogy bekapcsoljon a gép, a másik nem. egyik kell, hogy fusson a programok 99%-a, a másik nem. nem kérdés, hogy melyik dudás fog maradni.
-
oO7
őstag
"ha hatékonyabb gratikai interakciót akarnak, akkor a gput és igp-t, mint olyat, fel kell számolni teljesen, és a gyors grafikához szűkséges számítást elvégző tranyókötegeket közvetlenül, utasítás szintjén a cpuba kell bevezetni"
az "utasítás szintjén" kivételével lényegében a mai APU-kban ez történik... aztán a következő lépés feltételezem, hogy a közös IL kód/ISA lesz, és utána jöhet (HA jönni fog valaha is, erről Abu tudna szerintem érdekeseket mesélni) az, hogy a GPU-t a mai CPU-khoz hasonló módon natívan érhessük el mindenféle köztes absztrakciós rétegek, driverek és virtuális architektúrák nélkül... -
Pikari
addikt
nos, van egy opengl ICD, amely egy sima user módú dll, a hardverrel - és magával a kernel szintű driverrel - az interakció ezen keresztül valósul meg. igazából ha kiadsz egy opengl hívást, pl glenable(gl_texture_2d)
igazából ez úgy történik, hogy ezt a driver a hardver belső működéséből fakadó módokon értelmezi, majd jönnek a további hívások, tehát csinál egy ilyen raklapnyi opkódot, és egy hirtelen mozdulattal egyszercsak (ha már összegyűlt sok, vagy ha épp egy blocking dolog jön), akkor a driver valamelyik része kernelmódba csapja a gépet, és belapátolja ezeket az opkódokat és adatblokkokat a videókártyába (,,gpuba''), a vezérlést meg visszaadja a drivernek, a videókártya meg csak szépen lapátol közben. ez ennél rohadtul nem lesz se gyorsabb, se optimálisabb sehogysem, akármilyen koncepció szerint is alakítják át, mert a gpu a rendszerhez képest egy külső, inkohézív hardver. ha hatékonyabb gratikai interakciót akarnak, akkor a gput és igp-t, mint olyat, fel kell számolni teljesen, és a gyors grafikához szűkséges számítást elvégző tranyókötegeket közvetlenül, utasítás szintjén a cpuba kell bevezetni. -
dezz
nagyúr
Az már minimum kettő, mert van egy low-level GPU driver, és azon ül a D3D és az OGL (meg az OpenCL). Pl. a shadereket HLSL-ről és GLSL-ről a D3D és az OGL compilere fordít egy köztes kódra, amiről aztán a low-level driver az adott GPU-ra. Ez persze a program inicializálása során történik (ha jól tudom), vannak itt egyéb műveletek, amik real-time történnek meg.
-
oO7
őstag
ez teljesen jó, igaz, egyetértek, de ha nem értelmezem rosszul, akkor itt a beszélgetés abból indult, hogy jó dolog az absztrakció, de mostanra már indokolatlanul sok volt az absztrakciós réteg, és ami most történik az az, hogy az eddig megszokott kényelmet valójában alacsonyabb absztrakciós szint mellett, "hardver közelibb" megvalósítással fogja tudni a Microsoft nyújtani a fejlesztőknek...
amúgy én is úgy gondolom, hogy az optimalizálást nem a magasszintű programkódokban (C++ / C#) kell elvégezni egy bizonyos szint után, hanem sokkal inkább a compilerben... -
Pikari
addikt
én a minnél közvetlenebb elérésben már nem hiszek.
úgy vélem, hogy a nagyvállalati fejlesztés jó (pozitív) szokásai és tulajdonságai már átmentek a teljes iparba: általánosan elfogadott absztrakciókon alapuló moduláris kód, a portolhatóság szem előtt tartásával, minél gyorsabban, minél egyszerűbben, minél hatékonyabban. tehát, zömében mindenki szeret az oprendszer alapvető apijaira hagyatkozni, a hardver specialitásainak kimeditálása helyett szeret a saját kódján belül meditálni, ha valahol égető szűkség van rá, inkább a fordítóprogram beépített trükkjeinek segítségével saját pointer, memória, és bittrükköket kialakítani. nem igazán vettem észre, hogy ennél közvetlenebb szintre már bárki is le akarna menni, és inkább a compilerre hagyatkoznak. a processzorokat is már úgy tervezik, hogy a C/C++ compilerből kieső kódot a jellegénél fogva analizálják, és a processzorokat már úgy implementálják, hogy az ilyen jellegű kódokat a lehető legefektívebben tudja az egység futtatni.
én szintén ezen az állásponton vagyok, a generikusabb absztrakciók elkészítése az oprendszer+hardver+drivergyártók feladata, nem az enyém.
-
Bull1
aktív tag
Értem, de igazsághoz hozzátartozik h az UE3-as motor elég hatékony már önmagában, legalábbis amiket én néztem játékokat, egy középkategóriás GPU-n (húzott GTX460) lazán elfutkorászik 60fps környékén és elég látványos, ergó ha nincs telenyomva minden hülyeséggel elég tempósan fut a kicsike, nem kell nagyon optimalizálni mindenfele.
De persze egyelőre egy sor kódot nem írtam benne még, de leírás alapján egész pofás, legalábbis tartalmaz már beépített hasznos dolgokat, pl. AI, eventek, hálózatkezelés miegyébb.[ Szerkesztve ]
-
dezz
nagyúr
Ejj, ezek a mai fiatalok, csak beleülnek a készbe...
Azért ez sem lehet fenékig tejfel, mert úgy tűnik, a történet kidolgozására és effélékre már valahogy nem nagyon jut energia a mai játékok többségénél... Lehet, a hardcore játékosoknak különbösebben igényük sincs rá, nem tudom. De hát nem csak ők vannak a világon!
Mindegy, amikor ennek a nagy eltávolodásnak az első jelei mutatkoztak, én inkább leléptem a hardverek felé.
Megértem persze a szükségességét.De azt is látom, hogy pl. a Londonba szakadt ismerősöm is C-ben és néha asm-ben nyomja (PS3-on)... (De a másik oldalról is ezt hallom.) De nem is csak a sebesség miatt, hanem tágabb lehetőségek. És a tudat, hogy a szép eredmény érdekében kvázi mident kihoztak a vasból, amit lehet, és ez valahogy jó hatással van a kreativitásra, ami nem szereti a felesleges békjókat, annál inkább a határok feszegetését...
-
Bull1
aktív tag
Jah, akkor könnyed 20 év differencia azért van...
Amit most nézegetek nyelvet érdekességképpen, azaz Unreal Engine 3-at programozó UnrealScript... pl. ha én ebben a motorban szeretnék játékot írni pl. a natív C++ kód itt el sem érhető az ingyenes verzióban. Erre mondom h azért ha az ember pl. "gyorsan" szeretne egy modern,3D-s játékot írni, magától a hardvertől már olyan messze van, h lehet a programozó az sem tudja már min fut a kód. -
-
dezz
nagyúr
Amúgy itt azt írják: "SFML is a free multimedia C++ API that provides you low and high level access to graphics, input, audio, etc." Bár nem tudom, ez mit takar. Amúgy handy kis cuccnak tűnik. (És látom, a C-t is támogatja. Engem annál fejlebb még nem sodortak az áramlatok.
Most is épp asm-ezem, uC-n. Bár itt is van C, de jelen esetben nem érzem szükségét. Csak ha pl. lebegőpontos számokkal kell dolgozni.) Ha majd én távolodok el a hw-ektől, jobban megnézem magamnak. Hah, látom, kitalálod a gondolataimat.
Amúgy a '80-as évek közepe óta, ami az első programsort illeti, még gyerekként. (Nem, nem egészen úgy nézek ki, mint az avatarom, 30-asnak néznek. 
)[ Szerkesztve ]
-
-
dezz
nagyúr
Hát pl. a konzolokra nem éppen Javában fejlesztenek.
Jó, azt én sem várom, hogy visszafordul az idő kereke a programozástechnikában és az átlag programozó asm-ezni fog, de a teljes eltávolodás szerintem csökkenni fog.Ennek egy érdekes irányzata a HSA, ahol eleve egységesre és könnyen kezelhetőre alakítják ki a hw-es interfészt/ISA-t.
Egyébként később a Java részévé akarják tenni ennek magasabb szintű szoftver oldali kezelését, a compute típusú feladatok Java alapú leprogramozásának megkönnyítésére, mivel néhány éves távlatban nem várható a CPU-k sebességének jelentős növekedése, úgyhogy egyre inkább igénybe kell venni, ahol lehet, a GPU-kat is, ha többletteljesítményre van szükség. Nem tudom pontosan, hogy fog ez kinézni a kód oldaláról, de azt hiszem, a Java programozóknak is meg kell ismerkedniük majd pl. a vektorokkal. Meg ilyesmi.
Szerk: ja, közben te is beírtál a végére 1-2 dolgot abból, amit én is említettem.
[ Szerkesztve ]
-
Bull1
aktív tag
Hát nem tudom mi számít annak, én C++ -nál alacsonyabb nyelvet nagyon nem is láttam. Ami menő manapság C++/Java/Ruby stb. ezek elég magasszintűek és rugalmasak, OO-megközelítésűek ezért nem értem ki akar még HW-közeli kódot írni csak úgy poénból. Persze a profi stúdiók ráérnek erre és tudás is megvan, de máshol... Az AMD nem véletlen gürizik azért h a GPU-ra könnyen lehessen kódot írni, mert speciális területeket kivéve senki nem fog rá írni semmit jelenleg.
[ Szerkesztve ]
-
dezz
nagyúr
(#90): Hmm, SFML és az Igazi Programozó... Bocs, távol álljon tőlem, hogy meg akarjalak sérteni, de ugye te is érzed, hogy ez érdekes vegyítés...
Mindegy, én ilyen old school vagyok. De az előzőbe utólag beírt középső bekezdés alapján ez újra napirendre fog kerülni...[ Szerkesztve ]
-
Bull1
aktív tag
Jóhát...én nem nagyon írtam hardverszintre lemenő kódot, de ott van pl. az SFML, minden be van készítve, alapból OpenGL gyorsítást használ, kicsi az esély h azon én pl bármit tudnék optimalizálni.
Out-of-the-box megy és kész, ha meg lassú a program az az én hibám, nem fogok lemenni asm-szintre. :p[ Szerkesztve ]
-
dezz
nagyúr
Jaj. Azért azt hittem, hogy ennél valami becsesebbet írsz azért...
Mint pl. aki megtalálja az arany középutat a teljesítmény és a ráfordított idő és energia között, vagy ilyesmi...A jelen topik éppen arról szól, hogy csökkenteni kényszerülnek az absztrakciós rétegek számát, mert pazarlás, ami folyik, ami nem engedhető meg az egyre kevesebbet fogyasztó gépeknél, illetve lassan a szilícium lehetőségeinek is elérünk a határára. (Az egyre kisebb tranyók nem fogyasztanak a méretükkel arányosan kevesebbet, stb.)
(Az előzőből inkább kiszedtem az egyesek számára esetleg már bántó passzust az anyagiakkal kapcsolatban.
)[ Szerkesztve ]
-
-
dezz
nagyúr
Még annyit tennék hozzá, hogy ezzel többszörös sebességnövekedéseket ért el! Szóval, még az sem áll, hogy inkább írta volna meg simán DX/OGL-re és az időközben befutó újabb GPU generáción úgyis 2x gyorsabb lesz (jó esetben), mert még úgy is lassabb lett volna, mint amit ő csinált.
Aztán az egésszel keresett itt annyit, mint egy alacsony mérnöki fizetés. Mondtam is neki, hogy miért nem megy inkább konzol programozónak, mint egy másik ismerősöm, aki előtte nem sokkal ment ki Londonba a Sonyhoz, azóta is ott van és kicsit más körülmények között éldegél. De nem volt hozzá kedve.
-
dezz
nagyúr
Inkább csak akkor csinálnának ilyet, ha ott amúgy sem fordult elő negatív szám. De ha mégis, nem történne semmi, csak egyszerűen az adott program nem használná ki a teljes numerikus tartományt, csak a felét (byte esetén pl. 0--127, 0-255 helyett).
Nem fizettek annyit...
De amúgy a srác a shadereket is úgy írkálta, hogy közben igyekezett pontosan feltérképezni a GPU vonatkozó részének működését, hogy minél optimálisabb kódot tudjon írni. Megjegyzem, így dolgozik egy igazi programozó...Nos, van egy orosz csávó, aki úgy használ egy teljes PC-s konfigurációt, hogy azon egy sornyi olyan program nem futhat, amit nem ő írt... (Hátha backdoorok vannak benne, stb.) Természetesen nem éppen a legújabb hw-ek vannak a gépében.
-
Pikari
addikt
ja, de ha akár egyetlen intet is átírnak mondjuk unsigned intre akár, akkor máris vége a bináris kompatibilitásnak, jobb esetben el se indul, roszabb esetben bsod.
a gondolatmenetet követve meg akkor már mehetünk lejjebb:
-akkor már miért nem ír az ember fia saját drivert a gpuhoz, a gpu memóriacímeit és regisztereit is ki lehet silabizálni, mint ahogy ezt a linuxos driverírók tették
-sőt, akkor már miért nem írnak teljes oprendszert a programhoz, minek használjanak létezőtés így már igencsak távolodunk a realitásoktól
-
dezz
nagyúr
Elméletben átírhatják, a gyakorlatban viszont nem írják át jelentősen, minden verziónál. Más szóval nem megrögzött munkamániások...
De a srác természetesen nem kommersz programokat írt, hanem egy bizonyos hw-re egy bizonyos alkalmazást, mégpedig az akkor beszerezhető legjobb hw-re a lehető leggyorsabb szoftvert kellett elkészíteni, megrendelésre.Ja, és már akkor a GPU-val számoltatott! Szóval, ez egy GPGPU-s alkalmazás volt. Ezen is sokan csak vakargatták a fejüket, hogy ez mi?
Egyébként nem az volt a "véleményezők" gondja, amit írsz, az egy nyilvánvaló dolog, hanem hogy ez lehetetlenség, sci-fi. Mintha azt írtam volna, hogy a vizen járt és kézrátétellel gyógyított.
Mert hogy az OGL/DX és a driver közötti API olyan titkos, hogy nincs emberfia, aki azt kifürkészhetné. -
Pikari
addikt
természetesen lehetséges, maga az opengl driver is ezt csinálja, tehát a client icd pontosan ezt csinálja. de mivel azt verzióról verzióra jelentősen átírhatják, értelmetlen, hisz minden egyes hardver minden egyes driverére külön-külön ki kellene nyomozni a függvényeket és konkrét funkcionalitást.
[ Szerkesztve ]
-
dezz
nagyúr
Egyébként egy ismerősöm 8-10 évvel ezelőtt meg tudta kerülni a Direct3D-t, rájött, hogy lehet közvetlenül kommunikálni a videokártya driverrel. Így pár lassabb funkciót saját kóddal helyettesített (asm, de valószínűleg C-ben is gyorsabb lett volna, mint a DX-es kód). Shadereket is shader assemblyben írt (Nvidián)... (Erről be is számoltam akkor egy másik fórumon, ami a legszakmaibb magyar számtech fórumnak címkézte magát, de ahelyett, hogy bárki aziránt érdeklődött volna, hogy hogyan lehet ezt elérni, mekkora sebességnövekedés volt elérhető, stb., egyszerűen csak azt mondták, hogy ez hülyeség, felesleges és amúgy sem lehetséges. Rájuk hagytam...)
-
dezz
nagyúr
Azt gondoltam, hogy ezután sem shader assemblyben fognak kódolni (ami persze más és más az egyes GPU-családokon).
Csak kezdett egy kicsit túlzottan eltávolodni egymástól a hw és a sw.Én arra leszek kíváncsi, hogyan integrálják majd a HSA-t (amire lassan mindenki átáll)? Ennek egyik fontos eleme, hogy alaposan leegyszerűsíti a sw-es oldal dolgát, illetve a hw-es oldal számára előír egy szabványos felületet.
-
oO7
őstag
Bizonyos szempontból most is megvan az absztrakció, mert a WinRT-nek köszönhetően ugyanazt a kódot felhasználhatod Win8-on (x86 / ARM), WP8-on és feltehetően majd a következő Xbox-on is... csak épp a köztes rétegek számát csökkentették le, illetve nincs már szükség a .NET-es fejlesztőknek wrapper osztálykönyvtárakra, hogy kényelmesen elérhessék a rendszer API-kat... és hogy visszatérjek az eredeti témához, nagy valószínűséggel ez lesz a DirectX-el és az XNA-val is... az XNA lényegében egy .NET-es osztálykönyvtár ami nagyrészben a DirectX API-hívások becsomagolására szolgál... ilyen módon viszont bizonyos szempontból egy redundáns technológia a DirectX mellett... így aztán valószínűleg készítenek egy WinRT API-t a grafikus képességek elérésére és ezt már C++ (natív) és C# (managed) fejlesztők egyaránt felhasználhatják és az MS-nek nem kell külön technológiákat karbantartania a két fejlesztőtábornak...
-
-
oO7
őstag
Igazából nem olyan nagy meglepetés ez... az új Windows Runtime-mal nem titkolt célja az MS-nek a "legacy API"-k (Win32 és talán ide vehető a DirectX is) felszámolása, és "vasközeli API"-k nyújtása a fejlesztőknek (nem csak C++ hanem C# fejlesztőknek is)... a .NET 3/4-ét kikukázták és leimplementálták natívan (WPF, WCF, fájlkezelés, hálózatkezelés, szálkezelés, stb)... valószínűleg az XNA sorsa is hasonló lesz, csak arra már nem jutott idő ebben az 1.0-ás verzióban... kíváncsian várom az állítólagosan új Xbox-szal érkező developer-friendly grafikus API-t (amit jó nagy valószínűséggel a Win8, WinRT és WP8 is meg fognak kapni)...
-
zsigus
őstag
Szerintem ebben még hosszú ideig nem lesz változás, és marad a DX.
A Microsoft-nak nem érdeke, hogy kinyírja a saját konzolját. Arról szólnak a hírek, hogy PC-hez közel álló HW-el jönnek az új konzolok, és ha most megegyeznének a GPU gyártók a közös szabványról, akkor lényegében rögtön felül múlnák (vagy egy szinten lennének) a PC-k grafikus teljesítményben a hamarosan megjelenő konzolokat.Ha a GPU gyártók az MS-re várnak, semmi nem fog történni ilyen téren, nagyon hosszú ideig...
Ha rosszul látom javítsatok ki.
[ Szerkesztve ]
-
DragoX
tag
válasz
Dr. Akula
#64
üzenetére
Pont ez az egyik fő oka, hogy az asztali felhasználásban gyenge a linux, mert nincs rá minőségi játék. Igen, könnyen lehet hogy több normális játék lenne rá, mivel opengl-es játékot sokkal könnyebb portolni mint Directx-eset. (gondolom mac esetén is egyébként)
Komplikato: Drukkolok nekik
[ Szerkesztve ]
-
#68
vinibali
őstag
Komplikato
#62
vinibali
őstag
válasz
Komplikato
#62
üzenetére
én nem nagyon hallottam sajnos felőlük mostanság, a Steam Beta is nagyon régóta kint van és nem látom, hogy történne az irgalmatlan mennyiségű portolás
-
-
#65
Pikari
addikt
Komplikato
#63
Pikari
addikt
válasz
Komplikato
#63
üzenetére
3dfx glide, és s3 metal, igen. a minigl mást jelent.
-
#60
Pikari
addikt
Komplikato
#58
Pikari
addikt
válasz
Komplikato
#58
üzenetére
hálózathoz már ezer éve nem divat a directx, de a directinput is kezd kimenni erősen a divatból.
-
#59
Bull1
aktív tag
Komplikato
#58
Bull1
aktív tag
-
#58
Komplikato
veterán
Bull1
#27
Komplikato
veterán
Az UT 2004-ben még volt OpenGL támogatás, utólag adták ki 3Dfx kártyák miatt. Az UE1-ben meg alapból volt.
OFF:
Kérdés, miért keverik egyesek konzekvensen a Direct3D-t a DirectX-el? Mint ha legtöbb OpenGL-es Windows játéknak nem kéne DirectX és nem azt használná beviteli eszközökhöz, hálózathoz, meg ezer dologhoz? -
-
Tin
veterán
most nem, mivel van 7 év előnye a PC-nek hardverileg. de a konzolokra meg teljesen optimalizált programokat fejlesztenek, hogy ellensúlyozzák a hátrányukat. ha azt mondjuk, hogy a konzoloknak kell 2-3 év ahhoz, hogy megjelenjenek rájuk a tényleg jól optimalizált programok, akkor kb. az életciklusuk felénél vannak előnyben, utána szépen lassan a PC-s videokártyák tovább fejlődnek, és elhúznak _nyers teljesítményben_. a bökkenő akkor van, ha a videokártyák teljesítménynövekedése már nem annyira jelentős évről évre, mint az korábban volt. remélem nem fogalmaztam túl nyakatekerten
-
LW
őstag
a PC lemaradása most megint nagy lesz, ahogy kijönnek az új konzolok, az azokra optimalizált programok még durvábban elhúznak az asztali videokártyák mellett.
Még durvábban elhúznak?
Egyáltalán nem húztak el. A jelenlegi konzolok hardverei elég gyérek, a futás optimálisabb ugyan, de még azzal sem közelítik meg egy mai elérhető árú videókártya teljesítményét.Az új generáció hozhat újat, fog is, de majd ha lesz mérhető eredmény és összehasonlítási alap, majd ráérünk ezekkel a feltételezésekkel.
-
-
Tin
veterán
nem ellened szól, de ez a független konzorcium ez olyan, mint a hddvd meg a bluray, vagy sorolhatnám. nyilván lenne egy amd és egy nvidia alapú közös konzorcium... ez meg idővel oda vezetne, hogy az egyik kevésbé sikeres, és eltűnik, míg a másik egyeduralkodó lesz, és ez pont nem a felhasználóknak jó.
a PC lemaradása most megint nagy lesz, ahogy kijönnek az új konzolok, az azokra optimalizált programok még durvábban elhúznak az asztali videokártyák mellett. viszont a PC mint olyan, erősen átalakulóban van, és nem vagyok biztos benne, hogy 5 év múlva ugyanúgy össze tudok majd rakni egy asztali gépet, mint tavaly. inkább attól félek, hogy akkor már lesz gép irodai munkára (asztali pc), lesz mobilozni (tablet?), meg lesz játékra (konzol). egyszerűen az embereknek erre van igénye.
-
Abu85
HÁZIGAZDA
Ki kell helyezni a fejlesztést egy független konzorciumba és kész. Mindenki kap egy szavazati jogot és ennyi. Ugyanaz az esély mindenkinek. Akinek ez nem tetszik az csinál egy alternatív platformot a többiek pedig sok szerencsét kívánnak neki az elterjesztésben.
Én ezt pontosan tudom, de attól, hogy egy fejlesztő nem tanul bele rögtön egy új hardver kihasználásba még az API overhead megmarad. Minél erősebb egy konzol annál nagyobb lesz a különbség ezen a területen a PC-hez képest. A következő körben ez a probléma már sokszor fog odavezetni, hogy inkább kimarad a PC-s port, mert nem akarják lebutítani a konzolos port minőségét. Ezt minden PC-s cég meg szeretné előzni. Hogy mi lesz 5-6-7 év múlva. Az szerintem most nem téma. Az merül fel, hogy ma gond van és kell rá egy megoldás ráadásul gyorsan.
[ Szerkesztve ]
-
Tin
veterán
talán félreérthetően fogalmaztam...
én nem kételkedem benne, hogy az általad leírt megoldás jelenleg nem lenne jobb, mint a DirectX, inkább arra próbálok célozni, hogy az a megoldás is ugyanoda jutna egy idő után, mint a DirectX most. több gyártó sok terméke, mindegyik piaci előnyt akar, ki határozza meg az újabb verziókat, kinek az implementációja legyen a tuti, stb.
a legjobb megoldás nyilván mindig a natív kód, és emiatt a konzolokra sokkal jobban optimalizált cuccok készülhetnek, de egy új konzolverziónak így hónapok-évek kellenek ahhoz, hogy minden játék optimálisan fusson rajta, mivel egy teljesen új hardver kerül bele. nézd csak meg majd most a sony és az ms konzolgenerációváltásnál...
@Jakuu: nem tudom. egyetemen, tanulás, zh-k, egyéb beadandók és bulizás mellett azért az a nem egész 3 hónap egy eseményvezérelt grafikus ablakkezelőhöz nem annyira sok.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Ezzel nem vitázok, mert tény, de az is tény, hogy eljárt felette az idő. Ki lehet azt a motort is egészíteni extra effektekkel és eljárásokkal, hogy szebb legyen, de ha ma valaki belekezd valamibe, akkor már kizárt, hogy UE3-at vegyen hozzá. Hasonló konstrukció mellett CryEngine 3-at kap, ami egyértelműen jobb. A tehetősebb fejlesztők pedig Frostbite 2-t választanak, ez még a CryEngine 3-nál is jobb. Bár ez valszeg véleményes, de a deferred render rendszernél komoly előnye van a Frostbite 2-nek.
[ Szerkesztve ]
-
FlekkeN
aktív tag
XNA tényleg könnyű használni. Dreamspark(MSDNAA)-ban is ott van. Letöltöttem és két nap alatt egy példán keresztül csináltam Xbox 360-ra egy platform játékot c#-ban. Akinek van egy Xbox 360 konzolja és kis kedve programozni szerintem nyugodtan megpróbálhat egy játékot összedobni.
-
Abu85
HÁZIGAZDA
Attól, hogy elkezdünk egy új utat járni a DirectX és az OpenGL nem vész el. Azt viszont nyilván látják a fejlesztők, hogy ezeken a korlátokon lassan brutálisan túlnőnek a konzolok, így ha a PC-vel akarnak még kezdeni valamit a gyártók, akkor nem árt gondolkodni azon, hogy az API korlátokat kiüssék valahogy. Nyilván a PC előnye mindig is a kompatibilitás volt, és ezen szerintem senki sem akar változtatni.
-
Angel1981
veterán
Okok, írtam is, hogy egyfelől igazad van.
De ne legyenek illúzióink; ha most egycsapásra megszűnne a DX, és az lenne, amit írtál, akkor sem oldódnánk meg a problémák, max. átalakulnának, illetve ami ténylegesen megszűnne, ahelyett jönne másik.
Szóval kb. ugyanott lennénk...Én nem szidom a DX-et; ha eddig megfelelő volt, ezután is annak kell lennie, legfeljebb módosításokra szorul.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Nem. A GPU-fejlesztők csak definiáljanak egy virtuális ISA-t, amit a jövőben közösen használnak. A fizikai ISA úgyis lehetetlen, mert azt még házon belül is lecserélik pár évenként. Ellenben az aktuálisan használt virtuális ISA változatlan, és az mögött van a fizikai ISA. A közös virtuális ISA lényegében leváltja a saját virtuális ISA-t és emögött nyilván a fizikai ISA továbbra is lehet eltérő. A programokat arra a virtuális ISA-ra írnád meg, amit ugye mindenki támogat. Ez kapna egy felületet, amiben definiálni lehetnek egy grafikus futószalagot.
Ezt a felvetést nem én találtam ki, hanem a fejlesztők. Nyilván nem egy stúdió beleütközött már a PC-s grafikus API-k korlátjaiba, ami miatt le kellett butítani a konzolos programot, mert azokra a hardverekre nincs bonyolult és sokáig tartó erőforrás-érvényesítés, mint PC-n. Erre lett felvázolva, hogy miképp lehetne a PC-s grafikus API-nál a korlátokat megkerülni. A legígéretesebb opció a közös virtuális ISA használata.
Ez nem olyan. Megírod C++-ban és kész. A modern GPU-architektúrák, mint a GCN már igen jól támogatják a C++ funkciókat. A többiek is erre fejlesztenek.
(#27) Bull1: Az Unreal Engine 3 túl régi és sokkal jobb motorok vannak már, mint a Frostbite 2 és a CryEngine 3. Az Unreal Engine 4 pedig problémás a legtöbb hardvernek, mert a grafikus futószalag zöme compute shaderben van írva.
[ Szerkesztve ]
-
Tin
veterán
emléxem egyetemen anno volt egy fél éves beadandó feladat, ablakkezelőt írni. egyik évfolyamtársam nekiállt assembly-ben. asszem talán félig jutott fél év alatt, pedig nem volt annyira bonyolult a feladat.
oké, valahol nem árt alacsony szinten programozni, de az pont inkább a rutinok esetén lehet bármilyen szinten értelmes, nem pedig ilyen alacsony szinten. a dos-os időkben poén volt hardveres grafikus egérkurzort tolni a szöveges módra, meg az ilyen ökörségek, de manapság már semmi értelme, annyira hihetetlen számításteljesítménye van egy átlag asztali pc-nek.
ettől függetlenül tényleg gáz, hogy az API-k meg framework-ök miatt egyre igénytelenebbek a kódok, "a vm majd úgyis elintéz mindent" alapon, és az android tényleg egy fostalicska a dalvikkal a hátán, így nem csoda, hogy az iphone gyorsabb, dehát ott meg úgy fejlődik a hardver alatta, hogy csak lesek.
egyébként nem értem mi a gond a játékok sebességével (nem vagyok nagy játékos), hacsak nem az, hogy vérpistike gépén nem fut négykában ezerefpéessel a krájziszhárom
@Abu85: igen, mert a programozó lusta. de ha változások esetén ezt a "virtuális" ISA-t kellene hegeszteni, esetleg mindenki másképp értelmezné, vagy bizonyos funkciókat egyes gyártók nem támogatnának, esetleg rossz doksik kerülnének ki, akkor az egész semmivel nem lenne jobb, mint a mostani vagy bármilyen helyzet. lehet hogy gyorsulnának tőle a programok, de egy következő funkciókör bővítése esetén majd menne a csata, hogy kinek az implementációja legyen a szabvány, meg hogyan. ráadásul a gpu-kat is egyre több dologra kezdik használni, szóval simán van ott még kiaknázatlan terület. a DirectX meg legalább megvan, ismerhető és használható.
[ Szerkesztve ]
-
#29
csigabiga98
csendes tag
csigabiga98
csendes tag
hab
-
Pikari
addikt
a mostani 3d api-s megközelítés imho jobb, mintha közvetlenül kéne ezt a fostengert programozni. megadod a drivernek, hogy mit csináljon, aztán az már az ő dolga, hogy hogyan oldja meg.
ha egységes isa lenne, akkor úgy játna az egész hosszú távon, mint az x86. a belső felépítés 3-4 után elavulna, a kompatibilitás miatt viszont lehetne hardver szinten tovább görgetni a mostani hulladékot.
értelmetlen.
-
-
Tin
veterán
magyarul a GPU gyártók definiálják az interfészt, amit mindenki használ. nem pont erre való a DirectX?...
komolyan ki a pöcsöm akar a 21. század második évtizedében alacsony szinten GPU-t programozni? komolyan gondolja ezt bárki közületek, aki fejlesztő?
ez olyan, minthogy programozzunk assemblyben. meg csesszük ki a dalvikot az android alól, hátha akkor majd a támogatott készülékek száma lesz 3...
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Nem a variáción múlik. Van egy nagyon egyszerű megoldás arra, hogy a grafikus API a hardverhez közelibb legyen. A GPU-fejlesztőknek össze kell ülni és megegyezni egy olyan IL-ről, amit mindenki használni fog és arra lehet dolgozni. Az IL mögött aztán a gyártók dolgoznak a fizikai ISA kompatibilitásán. Ma azért nehézkes a helyzet, mert minden gyártó más IL-t használ. Ilyen körülmények között tényleg nem lehet jobbat alkotni, mint a mostani API-k.
[ Szerkesztve ]
Nekünk linuxosoknak nagyon nem jönne rosszul, ha nem lenne ez a vacak DirectX...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
ph Megszűnne az API fejlesztése, vagy csak egy rosszul megfogalmazott irományról van szó?
- Windows 11
- Luck Dragon: Asszociációs játék. :)
- AliExpress tapasztalatok
- Külpolitika
- Kerékpárosok, bringások ide!
- Samsung Galaxy S24 FE - később
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Milyen billentyűzetet vegyek?
- Apple Watch Sport - ez is csak egy okosóra
- BestBuy topik
- További aktív témák...
- MSI RTX 4090 SUPRIM - 2.5 ÉV Garanciával!
- BESZÁMÍTÁS! ASUS TUF GAMING RTX 4090 24GB GDDR6X videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! nVidia Founders RTX 3090 24GB videokártya garanciával hibátlan működéssel
- BESZÁMÍTÁS! nVidia Quadro P4000 8GB GDDR5 videokártya garanciával hibátlan működéssel
- Videokártyát, videokártyákat keresek, vennék!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest