Új hozzászólás Aktív témák
-
csongi
veterán
Ezt a problémát már pár éve lehet érezni. Mivel a utóbbi időben a PC játékok zöme, még a húzó nevek is konzol portok csupán. 3 Éves rendszerű kártyával bőven kényelmesen lehet játszani 1080p-be. Lehet az emlékeim a régiek, de az utolsó igazán PC-re írt izzasztó játék a Crysis volt.
-
Pikari
veterán
A kérdés összetettebb annál, hogy mennyire limitál az API. A valóságban egy játék nem lesz minőségileg jobb attól, hogy 50 millió helyett 100 millió polygon van a képernyőn. Én azt mondom hogy Inkább legyen a képen 10 millió polygon, ha csak egy 17 éves nintendos final fantasy színvonalát elérné, én teljesen elégedett lennék a játékkal. Persze nem fogja elérni soha, és ezen az se fog segíteni ha 4x annyi munka árán közvetlenül a hardverre programozzák le a hozzátartozó game enginet.
Ettől függetlenül amúgy igaz, amit beszéltek. A directx halott. Havonta kijön néhány AAA game ami DX-et használ, aztán ennyi. Egy ilyen API-ért felesleges 30 driveríró sztárprogramozót tartani napi 100ezres fizetéssel. Az OpenGL teljesen kinyírta, tehát bőven elég lenne azt pelenkázni, úgyis olyan lassúak a state trackerek a mostani driverekben mint anno egy 233mas Cyrixen.
-
bobalazs
nagyúr
Elkezdődött a Damage control!
Ezek szerint nem volt jó húzás fikázni az apit, az amd szerint.
-
Auratech
őstag
Szerintem egyenes az út a soft render előtt. A mobilok teljesítménye felnőtt a nagy gépekhez. Nem véletlen, hogy az MS is portolja a Win8-at ARM-ra. A másik oldalon meg nvidiás (tegra) szerver processzorokat tervezgetnek ARM architektúrával. A nagygépekben is rendesen van TESLA rendszerint. A stream computing, az open CL, a cuda mind az x86-os architektúra kötöttségeit kerüli meg.
A legújabb mobil procik tudják az open CL-t. Kicsiben a cell alapötletét használják, megfejelve az egyre fejlettebben programozható grafikus magokkal. A 4magos tegra 3 példáut 15w teljesítménnyel elvégez annyi számítást, mint három éve a 4Ghz-re húzott prescott p4 meg egy radeon 9600 vga kb 160w-os étvággyal. -
H.O.D.
senior tag
Gondolj bele, mekkora az MS nyomása. Az nVidia elég szépen kinőtte ,agát az első lapkák lmegtervezése óta. Nagyobb cég lett, mint a 3dfx valaha volt és szarra sem ment a physX-ével. Tudom, hogy nem komplett grafikus API, de a lényeg, hogy a DX mellett nem maradhatott és maradhat semmi egyenrangú rivális talpon, ami megvésérolható,
Grafikus API vonalon a helyzet analóg az operációs rendszerekével: MS, vagy kinlódás. Vannak persze alternatívák, de nekem nincs kedvem ahhoz kernelt fordítani, hogy az aknakeresó elinduljon. Így maradt a DirectX, ami úgy fejlődik, ahogy.
-
#143
mzso
veterán
attila9988
#137
mzso
veterán
válasz
attila9988
#137
üzenetére
"Mellesleg, sok szó esett manapság a software render visszatéréséről, akkor pedig azonnal meghalna mindenfajta api felület, mert nem kellene speciéális hardware (grafikus kártya) a grafika rendereléséhez, így csak a software képességei, és a cpu teljesítménye lehetne korlátozó tényező. Itt pedig már csak egyetlen platformról van szó, az intel kompatibilis cpu -ról. Mint annak idején."
Nem véletlenül terjedtek el a GPU-k. Sok mindent kell számolni pixelenként (meg vertexenként, meg egyebek). a cpu mag azt csak egymás után tudná, ami marha sokáig tart. A GPU-ban meg van egy rahedli számó egység ami párhuzamosan tud rajtuk dolgozni. -
#141
ddekany
veterán
attila9988
#137
ddekany
veterán
válasz
attila9988
#137
üzenetére
"Mellesleg, sok szó esett manapság a software render visszatéréséről, akkor pedig azonnal meghalna mindenfajta api felület, mert nem kellene speciéális hardware (grafikus kártya)"
Dehogynem, hiszen nem a CPU-n történjen a szoftver renderelés, hanem javarészben a GPU-n továbbra is.
-
#138
attila9988
őstag
Mozsa
#11
attila9988
őstag
A jövő biztosan a felhő.... abban a pillanatban ahogy elég gyors lesz hozzá a net olyan áron mint egy szimpla 5 mbites adsl, megjelennek az első fecskék....
Aztán lehet hogy el is hullanak hamar.... azt hogy mi a jövő, se te, se én nem tudhatjuk. A gyártók pedig csak próbálkozhatnak, reklámozhatnak, aztán kiderül hogy megeszi -e a nép. Pl hétköznapi, személyes adatokat is érintő munkához nekem, sosem kellene a felhő. Játékokhoz talán, de ott sem vagyok benne biztos.
-
#137
attila9988
őstag
attila9988
őstag
"Jelenleg a hardverkínálat és a konfigurációk mixelésének lehetősége gyakorlatilag határtalan."
És ez így van jól. Ha nem így lenne, és nem lennének szabványos csatoló felületek, illetve specifikációk, akkor egy pc nem annyiba kerülne, amennyit ma kell fizetni érte, mert nem léphetnének be újabb és újabb szereplők a piacra. Fontos megjegyezni, hogy abban az esetben a speciális feladatokra tervezett hardware elemeket is elfelejthetnénk, hiszen nem lehetne azokat bármelyik gépbe beépíteni...
Mellesleg, sok szó esett manapság a software render visszatéréséről, akkor pedig azonnal meghalna mindenfajta api felület, mert nem kellene speciéális hardware (grafikus kártya) a grafika rendereléséhez, így csak a software képességei, és a cpu teljesítménye lehetne korlátozó tényező. Itt pedig már csak egyetlen platformról van szó, az intel kompatibilis cpu -ról. Mint annak idején.
Amibe pedig a felhőket illeti. Még játékoknál sem biztos hogy ez a helyes út, hacsak nem mmo -ról van szó.
Felhő esetén nem lehetne megvásárolni az adott programot, vagyis amennyiben annak megszűnik a támogatása, úgy maga a program is eltűnik, és ez ellen semmit sem lehetne tenni. A masszív netes játékok képezhetik csak a kivételt ez alól, de annak sem örülnék ha csak ilyenek maradnának.
-
H.O.D.
senior tag
-
Alchemist
addikt
-
ddekany
veterán
Az indi játékok egyébként nagyon gyakran több platformosak (Win/Linux/OSX). Vannak már jó ideje programozói könyvtárak (SDL, stb), amik az OS-ek eltérésit igyekeznek eltakarni (+1 absztrakciós réteg... hurrá), ezért megy ez valamennyire. Persze ezeket a könyvárakat is meg kellett írni, és karban kell őket tartani. Meg nem tudom, hogy AAA-s címek, amik jobban feszegetik a technikai határokat, mennyire mennének ezekkel...
-
H.O.D.
senior tag
Hát igen, volt valakinek mersze kijelenteni, hogy a MS töketlenkedése áll a PC-s játékipar kálváriájának hátterében, Voltak alternatívák, pl. a glide, ami már akkor is odavert, amikor a MS fejlesztői még azt sem tudták, mi az a poligon. De mivel a lóvé mozgat mindend, a glide-ot az atyjával együtt szépen kinyírták. Aztám most beüt a dead end para. Késő bánat.
-
motorhead
aktív tag
Ha a debian ennyire alacsony hardver igényű, akkor ezzel még nem mondtál semmit. Az, hogy elindul az adott készüléken egy ilyen oprendszer, még nem jelenti azt, hogy lehet is használni. Pont ha egy kenyérpirítóra is fel lehet telepíteni, akkor a lehető legkevésbé hardver igényes. Vagy nem??
De D1rect azt írta, hogy a mobilja gyorsabb mint a pár évvel ezelőtt használt asztali PC-je. Persze most kiderült, hogy egy 286-os volt a pár évvel ezelőtti gépe. Mondjuk az éppen 25 éves kb. Ettől nem nehezebb gyorsabbnak lenni, de még az általad említett 386-ostól sem.
Tök mindegy, hogy csűrjük csavarjuk a kérdést. Óriási a fejlődés ez tény ebben a szegmensben, de ezek mind speciális célhardverek, amiket direktbe programoznak, semmivel nem kell kompatibilisnek lenniük, visszafelé meg főleg nem mint ahogy az említve is volt. Ez óriási előny. Ezért ennyire gyorsak és rugalmasak.Az lenne gáz ha nem lennének azok ilyen hardverekkel. -
ddekany
veterán
"ami kísértetiesen hasonlít a JIT-re"
Arra pont nem... a JIT-nél ami egyszer már lefordult, azt jobbára már nem kell még egyszer lefordítani, ha nem indítod újra az alkalamzást. JIT-szerű megoldás itt inkább olyan lenne, hogy a DirectX hívások lecserélődnének x86-os utasításokra amik közvetlenül írnak a videó kártya pufferébe. Csak hát nem hiszem, hogy ha ilyen kis granularitással megy a fordítás (DirectX parancsonként), annak lesz sok értelme... Ezért mondtam korábban hogy a magas szintű nyelvet, amit a driver fordítana le... de lehet hülyeség az egész.
-
>-48-<
aktív tag
válasz
motorhead
#107
üzenetére
Teljesen avatatlan vagyok az alap kérdésben, de a felvetésedre mindenképpen meg kell említsem, hogy az android rendszerű HTC Dream készülékre sikerrel "portolták" az ubuntu és a debian disztrókat is. Akár még grafikus felületet is telepíthet hozzá az ember, ha nagyon elvetemült. Pedig a G1-ben egy jó három éves 528as proci számolgat 256MB ROM és 192RAM társaságában. Szóval közel sincs a mai erőművekhez mégis használható rajta egy olyan OS aminek a rendszerigénye azért egy 386-os-on bőven túlmutat (legalábbis az ubi+gnome kombóé, a debian végülis ahogy mondani szokták, még a kenyérpirítón is elfut). Szóval minden hozzáértés és szakmai alap nélkül igenis azt tudom mondani, hogy a telefonok lassan igenis felveszik a versenyt a régebbi asztali pécékkel (ha még nem tették meg).
szerk: ja és a lényeget ki is hagytam, azért tettem idézőjelbe a portolást, mert valójában nem forgattak, nem optimalizáltak semmit, hanem fogtak egy minimumra összedobott img-t és azt telepítették fel
-
-
ddekany
veterán
válasz
Alchemist
#117
üzenetére
Hát majd jön valaki aki konkrétan szokott játékok grafikai részével foglalkozni, és megaszondja... de ha jól értettem itt a vízfejről van szó, ami ott lép fel, ahol a jellemzően C++-ban írt CPU-n futó program eteti a DirectX-en (vagy OpenGL-en) keresztül a GPU-t, ahelyett hogy közvetlenül etetné azt. Mert DirectX-nek ill OpenGL-nek egy fix felületet kell mutatnia a programod felé, holott mögöttük a hardver más és más lehet. Tehát itt van egy extra absztrakciós réteg, amin minden parancsnak át kell vergődnie... Nem tudom, szóljon aki tudja, hogy ez a gond? Mert ennek megoldásához az utólagos fordítás hasonlóan jó eredményt kéne adjon, mint egy bővített ISA, nem de?
-
#118
hcl
titán
Termigáßor
#49
válasz
Termigáßor
#49
üzenetére
Windózból, driverből le lehet kérdezni, hogy milyen HW van.
És a driver maga nem gond, csak az API.
Plágenplév van már, amióta működik is, nem olyan nagy ügy a HW elemek lekérdezése. -
Alchemist
addikt
-
-
mzso
veterán
Szerintem simán működhetne úgy mint a cpu-val. Az egyik csinál egy jó architektúrát. Az gyorsan elterjed a többi meg követi mint a kisangyal.
A játékok most is gyakran megjelennek linuxra, ha opengl-ben készültek. Az egyéb szoftverek meg valószínűleg azért nem jelennek meg más os-re mert szintén OS specifikus library-ket használnak.
-
#114
hcl
titán
Dark Archon
#113
válasz
Dark Archon
#113
üzenetére
Nem arról van szó, hogy 486-on fusson.
Az lenne a lényeg, hogy ne azért kelljen erős hardver, hogy egy szar oprendszer elmenjen rajta.
A Pista a legjob példa; mi az a gép, amin elfut? Aztán befejezték, kijött a 7, és kiderült, hogy bizony az azonos hardveren nem sokkal lassabb az XP-nél... csak rendesen meg kellett írni!
(Hozzáteszem, bohóckodni a winnyóz jó
)Egyébként a mai Linuxox sem mennek gyenge hardveren full funkcionalitás mellett.
Parancssorosan, az más tészta. -
#113
Dark Archon
addikt
motorhead
#93
válasz
motorhead
#93
üzenetére
Ezen szerintem kár problémázni. Nyilvánvaló, hogy a hardverek fejlődésével az OS-t is kár egy bizonyos szint alá vinni. Ugyan mi a fenének kéne, hogy egy 486-oson fusson? Arra ott a Linux, netezni, bohóckodni jó. Egyébként nálam 2 helyen a Vista is remekül fut, csak a média ledarálta, amit aztán kiadtak Win 7 néven egy kis átpofozással és egyből megkajolta mindenki.
-
ddekany
veterán
válasz
motorhead
#107
üzenetére
"De csakis a saját környezetében, ami tökéletesen van optimalizálva és kifejezetten az adott hardverekre van megírva."
Nem tudom mennyire lehet ezt optimalizációnak nevezni... Nekem arról a szóról az jut eszembe, amikor az ember leül szőrözni, hogy adott algoritmus milyen esetben milyen hamar végez (ne adj isten lekezd sakkozni az órajelekkel - na, az már retro). Valószínűleg egyszerűen csak nincs még felfújódva az egész, csak arra fókuszáltak amit tényleg nagyon tudnia kell. Mindig addig nyújtózkodunk, amíg a takaró ér... Na meg egy kicsit tovább, nehogy már valami tényleg gyors legyen.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Lehet hogy nem lényegtelen az sem, hogy egy android kb semmi történelmi terhet nem cipel magával. (Visszafelé kompatibilitás borzalmasan útba tud lenni...) -
"Csak persze ehhez hozzátartozik, hogy a pénzügyi racionalitás általában elég rövidlátó..."
Erről beszéltem. A gyártóknál már csak a fogyasztók hülyébbek (igen magam is) akik kiszolgálják a gyártók és a piac érdekeit.
Okos ember 1 perc alatt belátja, hogy ez az egész mai gazdaság egy baromság. Csak sajnos nem nagyon tudunk rajta változtatni. -
lenox
veterán
Hat igen, en is azt neztem, hogy mondjuk 60 fps korul 2000 draw az 30 frameenkent, az oke, lehet, hogy valamilyen grafikanal keves, de 20000 az mar 300 framenkent, milyen jatek van milyen konzolra, ami ennyi hivasbol rak ossze egy framet, es nem csak pazarolja az eroforrasokat?
-
ddekany
veterán
"És nekem múltkor valaki megmagyarázta (egy amolyan "sikerember", nyalósköcsög), hogy az ész nélküli, optimailzálás nélküli szoftver, meg hardverpörgetés mindenkinek jó, mert abból többet szakítanak a gyártók..."
Programozóként én szívesen szakítanék helyettük, de egyszerűen nem így működik a piac... Nem fognak nekem 2x annyit fizetni a hardver gyártók rovására. Könnyen meglehet tényleg nem jönne ki olcsóbban neked sem. Csak persze ehhez hozzátartozik, hogy a pénzügyi racionalitás általában elég rövidlátó... mert lehet 50 éves távlatban iszonyú veszteségeket fog okozni az a környezeti terhelés amivel hardver állandó cseréje jár, de ezzel most nem számolunk, mert a következő néhány negyedéves eredményen ez nem tükröződik. De ez valahol a fogyasztók viselkedéséből is adódik... megvehetsz egy adott dolgot 5000-ért, de 50 éven belül 25000-et rá kell fizetned, vagy megveheted ugyan azt 7500-ért, de nem kell később ráfizetned... na melyiket fogják venni? Sőt... lehet hogy még ugyan abban az évben ráfizeted az 25000-et, csak adó stb formájában, azaz nem látod, hogy valójában miből származott, és akkor is a 5000-es cuccot fogod megvenni.
-
motorhead
aktív tag
Na itt megállunk egy csöppet. A telefonod gyors a rajta futó oprendszerrel és az arra írt szoftverekkel. Gyorsabb CPU van benne valóban mint a pár évvel ezelőtti gépedben, ha csak a számokat nézzük, bár ez sem így van teljesen mert az én gépem 4 évvel ezelőtt is 3GhZ-en ment a telefonom meg most is csak 600MhZ-en vagy 800?? Tökmindegy.. értem a megközelítést. Pont itt a lényeg.
De valójában meg sem közelíti annak sebességét, ha pusztán a teljesítményét nézzük. Próbálnál csak egy Win7-et futtatni azon a kütyün, vagy egy 3DSMax-ot
Látod már nem is olyan gyors az a telefon. Sose feledjük azt a tényt, hogy a GhZ-ek és a MhZ-ek nem minden.
Egy mondjuk mai androidos készülék egy abszolút célhardvernek tekinthető, pont jó példa arra, mennyire sokat számít, mit mire írnak és hogyan tervezik meg az adott hardvert.
Még furcsább az egészben, ha egy csúcs mondjuk mai 4G-s iPhone-t nézünk meg vagy más Androidos cuccot,milyen elképesztő 3D-s grafikát nyom. Lassan tényleg utoléri a PC-t vagy egy gyengébb konzolt. Sőt már utol is érte. De csakis a saját környezetében, ami tökéletesen van optimalizálva és kifejezetten az adott hardverekre van megírva.Ha esetleg tévedek, akkor javítson aki pontosabban tudja ezeket vagy nagyobb a betekintése a dolgokba.
-
-
válasz
motorhead
#102
üzenetére
Viszont ha azt vesszük, hogy ezeknek az eszközöknek a tervezéséhez PC-ket használtak, akkor mondhatjuk, hogy minden van, ha PC van.
Származásilag sokinden sokmindenennel összefügg, és igazából nem szükséges ilyen kijelentéseket tenni szerintem.
Az Apple átállása a technológia fejlődése miatt történt: a PowerPC processzorok nem voltak versenyképesek sebességbeli fejlődésben és fogyasztásban(!) az Intel CPU-khoz képest. Akkoriban (5-6 éve), amikor látszott a hordozható gépek eladásának felfutása, ez nagyon fontos volt, mivel az IBM nem tudott versenyképes mobil processzort szállítani. Kb ennyi.
-
-
motorhead
aktív tag
"De egy igazán gépigényes algoritmus, mint pl. egy adott minőségű renderelés 3D studióban vagy egy adott rátájú zip-be tömörítés közel 100x-os sebességgel fut a mostani 100x erősebb gépen."
Ez biz így van. De mindemellett a szoftveren is csiszolni kell, hogy pl.a megjelent új utasításokat kihasználja a program-. Pusztán a MhZ-ek emelésével szemben egy új felépítésű CPU sokkal gyorsabb lehet még azonos órajelen is. Lásd, Core2Duo vs i5-7 széria.
-
motorhead
aktív tag
Persze vannak rokonságok, de néhányszor leírtad, hogy ez sem PC. Egyezzünk ki abban, hogy a célhardverek nem kifejezetten a PC-knek köszönhetik a létüket. Szerintem. Tehát ez az állítás csak részben igaz.
Tudom, hogy a MAC áttért x86-ra... De azt nem, hogy pontosan miért is. Gondolatom szerint a könnyebb szoftver portolás miatt.
-
És nekem múltkor valaki megmagyarázta (egy amolyan "sikerember", nyalósköcsög), hogy az ész nélküli, optimailzálás nélküli szoftver, meg hardverpörgetés mindenkinek jó, mert abból többet szakítanak a gyártók...
...pedig nekünk, usereknek abszolút nem jó (ha a gyártók nagyot szakítanak, mi nagyot fizetünk), sőt, környezetvdelmi szempontokból sem jó, ésszerűségi szempontokból sem jó... ...csak ez senkit nem érdekel, rajtunk kívül.Többek között ezért nem játszok. Van egy 4 éves gépem, amire használom, több mint elég. És van pénzem, mert nem veszek évente 3-4 VGA kártyát több tízezerért, mint pár haverom.
-
"Richard Huddy egy rendkívül érdekes kijelentést tett az elmúlt héten a bit-tech számára adott interjúban."
Semmi újdonság nincs ebben. Már az őskorban is tudtuk, hogy ha a program a vason fut, akkor gyorsabb lesz, mintha interpreter, különböző kompatibilitási rétegek, stb.
Valamit valamiért.
Az API és driver funkciókat kellene egybeolvasztani akkor eltűnne meg meglehetősen vastag réteg, azaz a DX nagy része, így sokkal gyorsabbak lehetnének a játékok. -
válasz
motorhead
#95
üzenetére
"Amit most konzolban vagy egyéb "fix" hardverben látsz (mondjuk egy Mac), valószínűleg nem lehetne olyan, ha nem lett volna a PC."
Miért is?? A MAC és egyéb alter. gépek vagy célhardverek (mint a konzol) mindég más vonal volt mint a PC. Szerintem ezek nem a PC-k létezésének köszönhetik a létezésüket.
Az XBOX360 CPU-ja egy IBM PowerPC alapú processzor, a Cell-hez hasonló, mondjuk ez nem PC. Viszont az ATI Xenos GPU az abszolút rendelkezik PC-kapcsolattal, mert az ATI R500 GPU-k rokona, azaz az x1800-x1900 sorozat testvére. (Ebből következően az XBOX360 játékátiratainak jól kéne futni ezeken a VGA-kon, de mint tudjuk, nem így van.)
A PS3 Cell processzorokra épül, ami nem PC, viszont a GPU-t az Nvidia fejlesztette, és ha minden igaz, a G70 GPU rokona. Ez megint csak PC-kapcsolatot jelent.
Tehát adott két DirectX 9 szintű grafikus képességű konzol, amik a fix hardvernek köszönhetően olyan megjelenítést képesek létrehozni, amihez PC platformon sokkal erősebb hardver kell.
Szerk: Ahogy ddekany mondja, a MAC is PC alapú ma már, pontosabban Intel x86 alapú.
-
ddekany
veterán
válasz
motorhead
#95
üzenetére
"Miért is??
A MAC és egyéb alter. gépek vagy célhardverek (mint a konzol) mindég más vonal volt mint a PC."Valahonnan jönnek azok a technikai vívmányok amiket ott felhasználnak... meg ma már a MAC is átállt hardveresen PC-re. Ha következő generációs konzolok GPU-ja is bizonyosan sokat fog meríteni abból, ami az alapvetően PC-re eladott GPU-k fejlődésében lezajlott azóta.
"Így is a végfelhasználó fizeti meg, csak nem drágában veszi meg a szoftvert, hanem hardvert cserél"
Csak épp lehet, hogy még mindig az az olcsóbb neked. Meg, a gyártók megoldják hogy újat vegyél akkor is, ha teljesítmény miatt nem is kéne... Áltag irodai gépeket vagy netezős gépet jelentős százalékban azért cserélsz le, mert bekrepálnak 5 év után (ill. cégeknél nem várják meg, mikor krepálnak be - nincs már rá támogatás, akkor csere).
Azt is vedd észre, hogy azért ez a szoftver lassulás általában "vízfej", és nem mindenre vonatkozik egyformán. Azaz, az átlag alkalmazás egyáltalán nem fut 100x gyorsabban a 100x erősebb gépeden, de nincs is arra égetően szükséget, mert kb elég gyors. De egy igazán gépigényes algoritmus, mint pl. egy adott minőségű renderelés 3D studióban vagy egy adott rátájú zip-be tömörítés közel 100x-os sebességgel fut a mostani 100x erősebb gépen.
"Ezért gondolom azt, hogy valami nem kerek."
Semmi sem kerek soha se... természetesen megy a bénázás ezerrel szoftverfejlesztés területén is. Más felől én látom valamennyire hogyan nő a "vízfej" (szerver oldalon amúgy), és ez megkerülhetlennek tűnő jelenség akkor is ha mindenki állati okos. Leegyszerűsítve az történik, hogy próbálunk egyre többet újra használható komponenseket használni, mert enélkül egyszerűen megdöglünk. Tehát ha verebet kell lőni egy alkalmazásban, akkor régen faragtam erre egy veréblövő csúzlit, ma viszont fogok egy mások által készített kismilló helyen világszerte használt univerzális interkontinentális giroszkópos plazmaágyút azt' kész. Az szegény batár nagy, mert rengetegféle felhasználásban helyt kell állnia (absztrakció, általánosítás). De amit építettek, az is csak egy komponens lesz, aminek mindenki csak felszínét látja már, és feledébe is merül, hogy ez belül univerzális plazmaágyút használ csúzli helyett, és még sok efféle szörnyet. Na, így lesz az alkalmazás amit 64K-ban meg lehetne írni 50 MB, és így kap sérvet alatta egy régi CPU.
-
motorhead
aktív tag
"Ugyan ez a mechanizmus kb mindenre igaz, nem csak videó kártyára: a hőskorszakban mindennel sokkal könnyebb látványosan haladni."
Igen, ebben teljes mértékben egyet értek. Hogy a példámnál maradjak, a Crysis-től nem látom szebbnek a 2. részt.Pedig eltelt majd 4 év. Négy éves hardver ma meg már a süllyesztőben. Csak az elmélet(ed) szerint ez később még gázabb lesz és még kevésbé fogunk jelentős változást látni az idő múltával.
"Amit most konzolban vagy egyéb "fix" hardverben látsz (mondjuk egy Mac), valószínűleg nem lehetne olyan, ha nem lett volna a PC."
Miért is??
A MAC és egyéb alter. gépek vagy célhardverek (mint a konzol) mindég más vonal volt mint a PC. Szerintem ezek nem a PC-k létezésének köszönhetik a létezésüket."Nem kicsit kell többet ülni előtte, és azt a plusz munkaidőt neked, a végfelhasználónak kellene megfizetni. "
Így is a végfelhasználó fizeti meg, csak nem drágában veszi meg a szoftvert, hanem hardvert cserél, hogy normálisan működjön. Így lehet eladni az új hardvereket. A pénz így is úgy is el van költve.Ez mivel jobb? Hát annál, hogy a hardver gyártók is kapnak a tortaszeletből amit pénzek hívnak.
"A programozók agya, mivel csak emberek, nem fejlődik (illetve de, csak az evolúció lassú), a szoftverek viszont egyre bonyolultabbak. A hardver (még) fejlődik, arra lehet nyújtózkodni..."
Mivel én nem értek a programozáshoz, csak az alapján tudok ítélni amit eddig láttam a fejlődéstörténelemben. Ezért gondolom azt, hogy valami nem kerek.
-
ddekany
veterán
Azért abban az a 4G, de a 2G is (elég az...) eleve mellbevágó... sőt régi gépekhez képest a CPU is brutális. Én emlékszem még a Win95-ös gépekre, amik irodai munkára jól mentek 32MB RAM-al és valami 300Mhz-es mai szemmel nézve nevetségesen alacsony utasítás-per-órajeles egymagos CPU-val, néhány száz MB-s HDD-vel és valami S3 Trident-el. Ezek az átlag irodai felhasználó szempontjából nem sokban különbözik egy mai Win-től (persze amíg le nem rohadtak), de legalábbis nem annyira mint a régi és az új vas erejének a hányadosa alapján (ami 50 vagy ilyesmi, és akkor ez csak egy E-350 volt) várna a naiv ember. Sőt, van valahol még egy Pentium 133-as gépem Win95-el és Word 6-al, és ezekkel a szoftverekkel nem is lassú érzetre. (A Win7-éhez hasonló start menüt meg tálcát már akkor is lehetett volna simán csinálni, csak a kicsinyített előnézet nélkül és csak startmenün belüli kereséssel. Hasonló grafikai dizájnt is a szürke-kockák helyett, csak az amúgy teljesen haszontalan áttetszőség effekt meg áttűnési animációk nélkül. Mert hogy az átlag felhasználónak ezek a szembeötlőek, nem a belső felépítés.)
Azaz, igenis meglepőn drága volt az előrelépés a szoftver tudásában.
-
motorhead
aktív tag
Hát ez az. 4GB RAM kell egy oprendszer normális futtatásához és egy 2.7GhZ-es proci? Pont erről beszélek. Értem én,hogy az említett cucc nem vészesen drága, de a számok attól még hatalmasak. Egyébként ennél gyengébb gépen is szépen muzsikál kivételesen a Win7. Ez esetben talán kissé erősen fejeztem ki magam, itt mármint a Win7-nél érezhetően jobb az optimalizálás, mint a korábbi termékeknél. De azért hasra nem esek..
-
ddekany
veterán
Eltekintve az üzleti kavarásoktól... gondolom nincs egyetértés benne, hogy annak milyennek is kéne lennie. Főleg ha jövőállónak is kéne ennek lennie. Fiatal az egész számítástechnika, hát még a GPU-s téma. (A nem OS-hez kötött játék meg ezen bőven túlmutat, hisz ált. azok az alkalmazások sem OS függetlenek, ahol nem kell vektor grafika.) Meg persze más célokra más teljesítményű GPU praktikus esetleg... ebből és adódik valamennyi változatosság (mondjuk konzolhoz képest, ahol ez is fix).
-
mzso
veterán
Miért nem csinálnak egy nagyjából stabil ISA-t a GPU/stream processorokhoz is mint az x86 a CPU-khoz? (vagy valami újat ami mindkét félét magába foglalja) Akkor nem lenne ez a szenvedés. Csak le kéne fordítani a kódot és kész. És nem lennének OS-hez sem kötve a játékok.
-
joysefke
veterán
+1
Ja, vagy lassulást hozna :
C++-ban sokkal egyszerűbben leprogramozható egy komplexebb, de gyorsabb fügvény mint asm-ben. Egy quick sort Javaban is agyonver egy ASM-es buborékrendezést mondjuk 100 elem mellett. És ha a programnak azok a részei algoritmikousan jól vannak kódolva, amelyek sokat futnak, akkor a többi már "szinte" mindegy...J.
-
h.kalman
csendes tag
Kicsit eltérve a témától: a Dx api kicsit vakítás mivel egy nagyon fontos dolgot kihagytok a dologból!!!!! DX = MS windóz és ez valakinek nagyon sokat megér .
Az open gl el a nagy probléma részben a platformfüggetlenség lenne és ez nem érné meg mindenkinek. ( és utolag dx api-n programozni könnyebb az open gl hez képest és a játékok hamarabb elömleszthetik a polcokat amik + 3 hónap munkával csiszolnának akkor már ki lehetne adni és nem lenne a sok kezdeti bug ) De ez az én véleményem ...... -
ddekany
veterán
-
ddekany
veterán
válasz
motorhead
#80
üzenetére
"Látványosan másabbak a mai pl. 3D-s játékok, de nem annyival mint amennyivel a GPU-k erősebbek és komplexebbek szerintem."
Egyszerűsített példával, amíg egy szörny feje kb egy kocka volt, addig látványos volt az is, ha később már 2x annyi háromszögből ált. Amikor már (hasra) 50 háromszög a feje, az már "elég jó", és a 100 háromszög nem szembe ötlően jobb, mégis 2x akkors számítási teljesítmény kellett hozzá, amit ráadásul műszakilag is sokkal nagyobb kihívás megvalósítani, mint régen amikor még nem feszegették annyira a határokat. Ugyan ez a mechanizmus kb mindenre igaz, nem csak videó kártyára: a hőskorszakban mindennel sokkal könnyebb látványosan haladni.
"Sajnos a PC-s technológia alapjaiban gáz"
Annyira azért nem... általában semmi semmi ideális (SCSI vs ATA, CISC VS RISC, stb), de gyakorlatban azért hozza 90% ami tényleg kelleni is szokott. Ha magát a változatosságot tartod gáznak, szvsz az a piaci versenyhez és innovációhoz fontos. Amit most konzolban vagy egyéb "fix" hardverben látsz (mondjuk egy Mac), valószínűleg nem lehetne olyan, ha nem lett volna a PC.
"Optimalizálatlanok a szoftverek nagyon nagy hányada hiszen nem a jól megírt szoftver a cél, hanem a gyorsan eladható."
"Ebből is a nagy igazság derül ki, ha kicsit többet ülnének a programozók a munka előtt"GPU területén mondjuk nem tudom annyira mi van, de úgy általában a szoftver optimalizáció kapcsán ez egy gyakori tévképzet. Nem kicsit kell többet ülni előtte, és azt a plusz munkaidőt neked, a végfelhasználónak kellene megfizetni. Hidd el, sokan szívesen csiszolgatnak 2x annyi ideig egy programot, ha megfizetnék (végső soron a vásárló, azaz te), mindenki utálja a rohanást. De nem fizetik meg, nincs rá igény. Az emberi munka drága, a hardvert meg okádják a gyárak, tehát fajlagosan olcsó. A másik, hogy az optimalizáció csak részben utólagos csiszolgatás kérdése, másik részben szakértelemé, ami már a kezdetektől a nagyobb léptékű tervezést befolyásolja. A jó programozó (szemben a tucat-programozóval) pedig ismét csak drága. Azt is neked kellene kifizetni.
A másik, hogy a jobb hardver nem titkolt célja, hogy fejlettebb de kevésbé gépközeli szoftver fejlesztési módszereket (pl. fejlettebb nyelvek) tegyenek lehetővé. Ez átlagos alkalmazásoknál neked is megéri, mert egységnyi áron többet tudó és kevésbé hibás szoftvert kapsz. És ahogy az alkalmazások komplexitása nő ez csak egyre inkább így lesz. A programozók agya, mivel csak emberek, nem fejlődik (illetve de, csak az evolúció lassú), a szoftverek viszont egyre bonyolultabbak. A hardver (még) fejlődik, arra lehet nyújtózkodni...
-
GOro.hu
csendes tag
válasz
motorhead
#80
üzenetére
Örök érvényű, hogy a programozó ideje a legdrágább... Másfelől az idő gyakran megszépíti a dolgokat, jó pár évvel ezelőtti játékok pre-render cutscene-jében sem lehetett látni olyasmit mint a Samaritan techdemoban az idei GDC-n, igaz nem átlagos otthoni konfiguráción futott. A különböző számítást végző egységek, csak órajel-sebesség alapján történő összehasonlítgatása céltalan, és a mértékegység (Hertz) helyesen: Hz
-
#81
LackoMester
addikt
LackoMester
addikt
Érdekes, jó kis irás, okosabb lettem.
-
motorhead
aktív tag
Sajnos a mai PC-ken nem csak a GPU/Driver hanem más is optimalizálatlan. Lassan olyan erős gépek kellenek egy sima oprendszer normális futtatásához, hogy a vicc kategóriát súrolja. Optimalizálatlanok a szoftverek nagyon nagy hányada hiszen nem a jól megírt szoftver a cél, hanem a gyorsan eladható. Tehát ha arról beszélünk mennyivel többet ki lehetne hozni a mai GPU-kból grafikailag, akkor legelőször arról kellene beszélni eleve mennyit kellene tudni kihozni egy átlag 3-4GhZ-en ketyegő PC-ből. Látványosan másabbak a mai pl. 3D-s játékok, de nem annyival mint amennyivel a GPU-k erősebbek és komplexebbek szerintem. És igen, én is határozottan alátámasztom, a DX10-ből sem lett még kihozva amire képes,lásd cryengine.
Sokszorosa a PC-k teljesítménye a 10-15 évnél régebben gyártottaknak de ennyivel nem lett hajmeresztően jobb az oprendszer sem. Sőt.. de ezt most nem feszegetem. Én még láttam 14MhZ-en kiváló oprendszert. Ma éppen látok egy elég jót 3ghZ-en. De nincs egyenes arányosságban a fejlettség a hardverek fejlettségével. Sajnos a PC-s technológia alapjaiban gáz, ezért csak a hardverek sebességének és komplexitásának fejlődésével lehet újat felmutatni. De aki már látott mást annak nem a cikk elolvasása után villan be, hogy igencsak meg vannak vezetve az emberek ebben a hardveres kérdésben. Az a cél, minél több hardvert el lehessen adni, ami kicsit többet mutat mint az előző és megy majd rajta a legújabb game hibátlanul. Azért ma is látunk ilyen olyan render motort ami gyorsabb lassab a másiknál. Ebből is a nagy igazság derül ki, ha kicsit többet ülnének a programozók a munka előtt akkor sokkal többet is ki lehetne hozni egy mai GPU-ból. Ezen dolgok miatt engem ez a cikk nem lep meg, és abszolut egyet értek vele. Bár a programozáshoz nem értek, a számokat azért egymáshoz tudom viszonyítani. Pár éven belül lesznek ezek szerint több GhZ-es GPU-k és kicsivel jobb grafika... -
ddekany
veterán
Ha jól sejtem a konzolon is pont ez a helyzet: etetni kell a GPU-t, ütemezni kell a parancs löketeket, stb. Tehát itt nincs különbség. Mégis ott jóval kevesebb az overhead, ha jól értettem amit az AMD-s mond. Én annak a résznek a megtakarítására firtattam, ami PC és a konzol közti ezt különbséget adja. Ha ez főleg a hardverre specializálódásból adódó nagyobb léptékű (átfogóbb) optimalizációból adódik, akkor esélytelenül hangzik, de ha afféle "bagatell" dolgokról van szó, hogy teszem azt (csak példa, nem tudom jó-e) DirectX-nél állandóan kreálsz egy tonna adatstruktúrát ami úgyis csak át lesz konvertálva GPU-specifikusra aztán el lesz dobva, akkor ott talán reális javítani a helyzeten. De, nem tudom, csak egy felvetés részemről, hogy tán más API megközelítéssel elviselhető redukálható lenne ez... nekem olyasmi jutott eszembe, amit API helyett már inkább DSL-nek hívna az ember.
"elég bonyolult lenne már maga az implementáció, nemmég úgy megírni, hogy profitáljon is belőle a driver"
Én az implementációt a driver részeként képzeltem el, pont mert a drivet tudja hogy egész pontosan hogy működik a GPU. De persze az egész csak afféle gondolat felvetés...
-
con_di_B
tag
Bocs az előbbi naiv megfogalmazásért, de másoknak hasznos lehetett ezt tisztába tenni. Amit te akarsz, ahhoz hasonló meg volt már régen, a display list-ek (OpenGL). Lehetett olyat csinálni, hogy egy ponton azt mondod, h na most jegyezd meg mit csinálok, aztán egy API hívás sorozat, na köszi, eddig tartott, aztán azt a sorozatot elmentette, átstruktúrálhatta a saját kedve szerint ("lefordíthatta"), aztán azt akárhányszor újra meghívhattad.
Csak annyi a baja a megoldásnak, hogy a paramétereket is mentette, szóval így nagyon kötött. De egyébként igen, egy ehhez hasonló dolog, egyénileg testreszabható paraméterezéssel nem lenne rossz. csak valószínűleg bőven elég bonyolult lenne már maga az implementáció, nemmég úgy megírni, hogy profitáljon is belőle a driver.
-
con_di_B
tag
Nem rossz ötlet amit mondasz, de ami igazán fontos az eleve így működik.
Az igazán fontos alatt értsd azt például, hogy van egy rakat kirajzolandó objektumunk, és mindegyikhez egy program (shaderekből), hogy azt hogyna is kell kirajzolni. Ezeknek a futtatása teljesen a GPU-n történik, GPU specifikus assembly kóddal, béke van.
A probléma az, hogy sokféle program van (meg paraméter, meg textúra, meg stb.), szóval az oké, hogy onnantól kezdve h beállítgatjuk a dolgokat, és rácsapunk a GPU hátsójára, h gyihááá, onnantól kezdve piszokgyors és nem igényle CPU-t, de mivel, mint mondtam, sokféle beállítás van, ezért a gyakorlatban legrosszabb esetben az van, hogy minden egyes apró objektumnál a GPU ugyan tudná még darálni, de elfogyott amunka, és várakozik, hogy a CPU felparaméterezze a következő munkamenetét. Na egy ilyen "gyiháá"-t hívnak draw call-nak.
Ez ellen az egyik védekezési mód, egy álomvilágban, az lenne amit a cikk ír, hogy legyen rövidebb a gyeplő, és akkor nem kell annyit várni, amikor irányt akarunk váltani a szekérrel. A másik megoldás meg az, hogy előbb gondoljuk át, hogy mit is akarunk, képezzünk rendezett csoportokat, aztán oldjuk meg minél kevesebb draw callal ugyanazt a kirajzolási sorozatot. Sokszor nem mernek durvább rendezéseket bevetni renderelés előtt, mert annak is van saját költsége, ami viszont általában megtérül.
-
con_di_B
tag
Amiről a cikk beszél, az minden API-ra igaz lesz, az overhead nem egy megkerülhető fogalom. Az OpenGL-nek valóban kárára vált a visszafelé kompatibilitás, viszont fontos tudni mellé, hogy egy ideje már be van vezetve egy deprecation model, amivel fokozatosan kikopnak az API-ból a régi megoldások, tehát ezáltal szálkásodik maga az API.
Ezen felül, az OpenGL-nek van egy beágyazott rendszerekbe szánt változata, az OpenGL ES, ami eleve egy "vékonyabb" API, és amennyire én tudom, az emlegetett OpenGL-es konzolokon, hordozható eszközökön eleve ez van. Konkrétan ennek az irányába konvergál az asztali OpenGL 4 is, és a WebGL is ehhez képest került meghatározásra. Az, hogy vékonyabb az API, ott jön ki, hogy ha egy API minél kevesebb emulált funkciót kínál, annál sanszosabb, h a fejlesztő ténylegesen hardverközeli programot ír. A másik fontos szempont, hogy kisebb API-ra könnyebb "pehelysúlyú" drivert írni.
Magára a cikkre reagálva: nyilvánvalóan igaz technikailag nézve, de az nagyon erős erős csúsztatás, hogy a draw call-ok számával lehetne emelni a grafikai színvonalat. 2000-hez képest 20 000 draw call nem jelent feltétlenül jobb grafikát, pusztán rosszabb kötegelést (batching). Olyan API-t kell használni, és olyan könyvtárakat, amik nem rejtik el a programozó elől a kirajzoló utasításokat, és akkor kézben lehet tartani a kötegelést. Ez természetesen nem pusztán a renderelő szubrutinon múlik, eleve olyan modellekkel kell szolgálni, lásd modell és pályaoptimalizáció.
A D3D 10 óta ott is elmentek a lightweight irányba, de nagyon lehet látni, h még a DX 10 mód is eléggé ilyen prémium dolog a játékokban, és a D3D 9 az alap ami tuti h gyorsra meg van írva, szóval azon a fronton nagyon bátor dolog volt a kompatiblitás elhagyása, de láthatjuk is, h tetűlassú migráció lett az ára.
Egyébként az OpenGL-ről még annyit, hogy az OpenGL 3 az eredetileg nem az az API lett volna, amit ma annak ismerünk, hanem volt abból egy elég széles körben beharangozott draft, ami még a mostani "újjal" sem igen lett volna kompatibilis. Na az lett volna az az állkapocsleejtős innováció azon a fronton, ami elmaradt.
A többszálú renderelés meg egy mese. Eleve akkor lenne értelme, ha rendertargetenként lenne maximum egy szál, ami azért eléggé korlátos párhuzamosíthatóság, utána pedig jön a command buffer, ahol a driverben összeszorul az egész, és kénytelen is, hogy összeszoruljon, ugyanis
1) PCI-Express sín
2) a GPU EGY dolgot tud (hatékonyan) több példányban csinálni, pont ez a Cayman nagy újítása, hogy abban ez már a múlté, de azért még nincs mindenkinek 6900-asa otthon
Szóval jah, nagyon jó lenne a közvetlen command buffer kezelés, de pl. az OpenGL eleve streamként képzeli el a rendszert, és ott csücsül az API-ban a kezdetek óta az aszinkron glFlush() - magyarán szar batching mellett is össze lehet várni egy rakás draw call-t. Ha meg a parancssorozat kezelgetése a nehézkes, az már tisztán CPU overhead. Az sem mindegy, de driver-driver-driver...
-
hohoo
senior tag
Szóval a mostani JIT szerű grafikus apizgatás helyett. gpu gépi kódra compileolt grafikára gondolsz?
Egyébként az hogy carmack aszonta hogy most a dx11 jó, az nem jelent semmit. Egy fejlesztő aki valamikor összehozott valamit, és elég rég óta semmi nincs... na meg az utóbbi időben eléggé szélkakaskodik....
Én arra emléxem, hogy régebben sok játék jött opengl és directx módban, és bizony opengl módban mindig sokkal (10%+) gyorsabban futottak a cuccok vagy szebbek voltak. Tapasztaltam ezt voodoo2-n, geforce2-n, radeon 9600-on, és hd3870-en is, pedig állítólag az ati opengl driver nem is olyan jó... Az xboxon kívül is minden opengl-t használ. Opengl megy minden plaformon, shader5-el ha van (xp-n is), nem úgy mint a dx11, és a többi...
-
ddekany
veterán
"Most jelenleg túl sok lehetőség van a CPU-GPU mixelésével."
Ez miért gond? Két független dolognak tűnik nekem... Ha a GPU-t közvetlenül érd el, akkor eltekintve a shader nyelvektől (amiket eleve nem érint a CPU típusa), C-t C++-t vagy ilyesmit használsz, nem? A C/C++ meg lefordul x86-a is, ARM-ra is, MIPS-re is...
-
GOro.hu
csendes tag
Már az OpenGL - pontosabban a Khronos Group - is régóta üldözi az elavult 'rögzített funkcionalitású' feldolgozóegységhez kapcsolódó utasításokat, valamint a gyártóspecifikus implementációkat. (így kényszerültek a gyártók, a driver-ben eszközölni okosításokat) Amúgy is már jó-ideje a gyártók által írt shader programok szimulálják a régi feldolgozóegység működését, ezáltal lehetővé téve, hogy még a régi trend szerint készült alkalmazások is működjenek (valamint sokszor nem a játék fejlesztői által írt shader-program fut le, hanem egy mondjuk úgy hogy 'manuálisan, direkt optimalizált' program). A konkrét natív programozás ebben a kontextusban bullshit. Nem tekinthető technológiai előrelépésnek mint az SM amit még nagyrészt üdvözítve fogadott a szakma, A halandó kezdő fejlesztők pedig fogták a fejüket, és tűzre dobták könyveiket.
Valaki már említette Repi GDC-s nyilatkozatát, illetve megtekinthető a prezentáció is, hogy mit kellet latba vetniük a PS3-as Frostbite továbbfejlesztésén, csak hogy játszható legyen majd a BF3. Mindez jelentősen visszaveti a fejlesztés ütemét, a határidőket pedig a kiadók szeretnék betartatni, amit csak a többi platform, és az egész játék minőségének rovására lehet megtenni. (valamit az eddigi játékok supportjának visszavágásával) Az egész pedig onnan indul, hogy hát mára már sovány a PS3-ban található grafikus erőforrás.
-
ddekany
veterán
válasz
julius666
#62
üzenetére
"Amúgy meg a driver az API hívásokat is gépi kódra fordítja, vagy szerinted pure C/C++ kód fut a hardveren?
"Dehogy hiszem... a szándékosan idézőjeles "natív" alatt azt értettem, amit az AMD-s illető mondott, hogy kihagyod az absztrakciós réteget (ami DirectX vagy OpenGL). Azaz, arra gondoltam, hogy közvetlenül a videokártya memória területére irkálna a lefordult program, nem pedig DirectX eljárás hívásokon keresztül és DirectX-specifikus adatszerkezeteken át kommunikálva tenné ezt. Mert gondolom ebből adódik az overhead, amiről itt szó van, de szóljatok ha nem. De ezt a fordítás nem előre végezné el a szoftver készítője, hanem a driver végezné el a kliens gépén. Mert a driver ismeri, hogy mit hogy jó csinálni adott hardveren. És így persze a program készítője soha nem is fér hozzá közvetlenül a hardverhez, továbbra is csak a driver teheti ezt, és az absztrakciós réteg technikailag mégis ki lett iktatva.
-
julius666
addikt
A platformokkal kevesebb lesz a lehetséges konfiguráció. Most jelenleg túl sok lehetőség van a CPU-GPU mixelésével. Ennek egyszerűsödnie kell, ha valóban erre akarunk menni. Mivel natív támogatásról lenne szó, így minden lehetséges hardverhez meg kell írni a rendert. Minél kevesebb ilyen van, annál könnyebb a munka.
A platformosodás nem igazán szűkíti a piacot. A processzorokkal akkora probléma eddig nem nagyon volt, azok viszonylag egységesnek számítottak (x86), az nVidia ARM-es platformja pont hogy jobban bezavar a képbe. Attól hogy egyfajta processzor mellett leszűkül a lehetséges GPU típusok köre, még nem jelenti azt hogy nem kéne a többire is megírni a kódot hogy fusson. Pontosabban ha platfrom-only játékok jelennének meg, azoknál előnyt jelentene, de attól meg az ég óvja a PC-s játékipart, az a totális halálát jelentené.
A Cloud az csak egy másik lehetőség a problémára. Ezen nem javít, csak opció arra indulni, mert az API az korlátozni fog.
Az idézethez:
This needs to be done through both proprietary and standard meansA csóka amúgy nekem úgy tűnik, pont arról beszél hogy egy standard, hardverközelibb, rugalmasabb API-t kéne kifejleszteni.
-
Abu85
HÁZIGAZDA
válasz
julius666
#60
üzenetére
A platformokkal kevesebb lesz a lehetséges konfiguráció. Most jelenleg túl sok lehetőség van a CPU-GPU mixelésével. Ennek egyszerűsödnie kell, ha valóban erre akarunk menni. Mivel natív támogatásról lenne szó, így minden lehetséges hardverhez meg kell írni a rendert. Minél kevesebb ilyen van, annál könnyebb a munka.
A Cloud az csak egy másik lehetőség a problémára. Ezen nem javít, csak opció arra indulni, mert az API az korlátozni fog.Nem Huddy ötlete ez. Ő csak elméleteket vázol fel/hirdet ki a problémákra. Johan Andersson (Frostbite motor) is reagált erre (láthatóan támogatja):
I've been pushing for this for years in discussions with all the IHVs; to get lower and lower level control over the GPU resources, to get rid of the serial & intrinsic driver bottleneck, enable the GPU to setup work for itself as well as tear down both the logic CPU/GPU latency barrier in WDDM and the physical PCI-E latency barrier to enable true heterogeneous low-latency computing. This needs to be done through both proprietary and standard means over many years going forward.I'm glad Huddy goes out and in public talks about it as well, he get's it! And about time that an IHV talks about this.
This is the inevitable, and not too far, future and it will be the true paradigm shift on the PC that will see entire new SW ecosystems being built up with tools, middleware, engines and games themselves differentiating in a way not possible at all now.
- Will benefit consumers with more interesting experiences & cheaper hardware (more performance/buck).
- Will benefit developers by empowering unique creative & technical visions and with higher performance (more of everything).
- Will benefit hardware vendors with being able to focus on good core hardware instead of differentiating through software as well as finally releasing them and us from the shackles of the Microsoft 3 year OS release schedule where new driver/SW/HW functionality "may" get in.
This is something I've been thinking about and discussing with all parties (& some fellow gamedevs) on different levels & aspects of over a long period of time, should really write together a more proper blog post going into details soon. This is just a quick half-rant reply (sorry)
-
julius666
addikt
Teljesen egyetértek, hardverközeli programozásról beszélni egy ilyen széttöredezett platformon vicc. Az ürge inkább menjen lobbizni az MS-hez hogy a köv. DX API biztosítson alacsonyabb szintű elérést, ne ilyen nevetséges marhaságokat nyilatkozzon.
A cikkhez: azt valaki igazán elmagyarázhatná, hogyan javítana azon a platformosodás vagy a cloudosodás, hogy a kód nagy részét meg kéne írni több platformra is, nem értem hogyan került a cikkbe.
Jó látni hogy valaki gondolkodik is mielőtt hozzászól nem csak nyomja a mantrát mert AMD-s mondta, de közben nem ért hozzá.
-
mrhitoshi
veterán
Már maga a messze menő kompatibilitás is fejtörést okoz a legtöbb átlagfelhasználónak, így aki teheti konzolt vesz. Cserébe lehet nem olyan erős a masina, viszont nem kell bajlódnia a telepítgetéssel stb.. + exkluzív játékokhoz is hozzájut, és még lehetne sorolni egy konzol előnyét, ami PC-s körben hátrány, mintsem előny. Szóval szerintem attól, hogy 20x erősebb egy PC a konzolnál, attól még nincs nyert ügye.
-
ddekany
veterán
-
ddekany
veterán
Nem világos, hogy itt egy eredendő gondról van szó, vagy csak olyanról aminek megoldása nagyon nagy befektetés lenne. Mert, nem lehetne kitalálni valami magas szintű GPU programozási nyelvet, amit a videókártya driver a program első indulásakor "natívra" fordít? Akkor aztán olyan hw specifikus trükköket alkalmaz, amit csak akar. Tisztába vagyok vele, hogy magas szintű nyelveket nehéz jól alacsony szintűre fordítani (a kézi optimalizációhoz képest), de másfelől pont hogy magas szintű nyelveknél van erre jobb esély ha a cél platform nagyon sokféle, mert a fordító jobban "érti" hogy mit akartál elérni, és mert nem kötsz ki számára alacsony szintű részleteket, ezzel megkötve a fordító kezét. Egy ilyen magas szintű nyelv is tulajdonképpen egy API... csak más megközelítésű, mint a DirectX vagy OpenGL. Azaz, amit mondok az az, hogy tán az "API" megközelítésének radikális megváltozótátásával ez a vízfej lényegtelen mértékűre csökkenthető.
-
mrhitoshi
veterán
Magyarul a PC-s kompatibilitás öli meg saját maga elől a PC-s játék ipart. Vicces, és egyben eléggé furcsa helyzet. Lehet ezért az üzletpolitikát okolni, de a PC legnagyobb ellensége saját maga. Úgy lett kifejlesztve, hogy kompatibilitás terén maximálisat nyújtson és ez is lesz a veszte a PC-s játék iparnak.
-
#52
Abu85
HÁZIGAZDA
Termigáßor
#49
Abu85
HÁZIGAZDA
válasz
Termigáßor
#49
üzenetére
Ha natívan programozod a hardvert, akkor nincs szükség driverre. Ahogy Johan Andersson mondta a GDC11-en: The best graphics driver is no graphics driver.
Igazából ezt az egész dolgot nem Richard Huddy találta ki. Már régóta téma ez. Richard Huddy csak hangot adott ennek, hogy lássa a reakciókat.
-
DriderG
tag
Lehetne valamivel gyorsabb, de szerintem akkor is közvetettebb a feldolgozás menete, mint konzolon, ott ugyanis nincsenek korlátozva az átviteli sávok, közvetlen kapcsolat van GPU-CPU között, ami az adatmozgatást megkönnyíti, ráadásul nem kell annyi, és olyan méretű driver minden eszközhöz, hanem mindent megpróbáltak a gyorsaság érdekében hardveresen implementálni. (pedig ott is van valamiféle API, amin keresztül elérik a hardvert, nem hiszem, hogy assembly-ben írnák a grafikus motort) Egy PC-n egy nagy étvágyú oprendszer is ott figyel, míg konzolnál max. egy 20 megás FW van, ami a menürendszert tartalmazza és éri el a perifériákat/memóriakártyát/vinyót. Ezért van szerintem az, hogy hiába egy erős gép X1950 XTX-szel, nem fogja úgy futtatni pl. a Star Wars TFU II-t, mint egy X360, sem egy GeForce 3 Ti a Halo 2-t.
Egyébként nem is tudtam, hogy változott a VLIW minta a 6-os sorozatú radeonon. Ezek szerint a szuperskalár feldolgozóegységek csak 3 komplex+1 egyszerű utasítás végrehajtására képesek? Lehet, hogy ezzel is gyorsítani akartak a folyamaton, hogy gyorsabban kódolja le a mintákat a driver.
-
Auratech
őstag
Az jutott az eszembe, hogy nem véletlenül tolja az nvidia az ARM szekerét. Az ARM csökkentett utasítás készletű proci, tehát RISC, mint a régebbi power pc és a tsai. Az egyszerűsített utasításkészlet előny a párhuzamosítható műveleteknél.
A PPC procik azért haltak be, mert azonos teljesítmény mellett akkoriban kazánként fűtöttek, mert egy RISC chipet bonyolítottak és húztak a végletekig(G5-mac-vízhűtés).
Talán az nvidia tudja, hogy a microsoft ARM támogatásában van annyi lehetőség, hogy a hardver megszólítása is változni fog a W8-al, amit tudomásom szerint ARM-ra is megkomponálnak.
Az ARM procik beágyazott grafikáját nézve sebességben, minőségben (pld PowerVR SGX543) 15-20 w fogyasztású alap, dx9-es környezetben futó gpu-t hoz, miközben töredékével beéri. -
#49
Termigáßor
aktív tag
smkb
#46
Termigáßor
aktív tag
Ja gondolom sok marketing kellene, hogy lenyomják a fejlesztők torkán, aztán meg a júzereket megint rávenni hogy konfigurálgassák, a játékokat indulás előtt mint anno. Bár ez nem akkora probléma szerintem. (Megvolt ennek is a hangulata anno. Amikor próbáltuk bekonfigolni hogy elinduljon a Tie Fighter a 4 megás 386-oson gravis ultrasound-al sound blaster emulációval... később a 3dfx glide már nem volt ilyen vészes, bár dos alatt kellett azzal is mókolni, igaz akkor monopol helyzetben volt a gyártó és a dx még sehol sem tartott.)
(#48) Abu85: és ha megpatkolják a catalyst-ot valahogy? Vagy ehhez a drivert is mindenképp ki kell hagyni?
-
#48
Abu85
HÁZIGAZDA
Termigáßor
#44
Abu85
HÁZIGAZDA
válasz
Termigáßor
#44
üzenetére
Van saját low level API-juk. Itt elsősorban az a fő szempont, hogy a command buffert lehessen direkten kezelni. Erre kell megoldást találni.
(#45) smkb: Persze olyankor nincs szükség driverre.
Pont, hogy az API-k miatt kell a driver. API-n keresztül nem tudod elérni a hardvert, mert ahhoz az API-nak támogatnia kell a GPU low-level hozzáférését, amit a driver nem enged. Ez azért van, mert az API nem ismeri a hardvert, míg a driver igen.Itt el kell vonatkoztatni a VGA-piactól. A platform a lényeg. Ha az elgondolásból lesz valami, akkor az platformra lesz és nem a VGA-kra. Ha a VGA-k eladása jó lenne az AMD sem gondolkodna ilyenen. Az a baj, hogy a VGA fejlesztése már nyűg. Sokkal többet lehet keresni egy platformon. Ezért is csinál minden cég platformot.
-
#46
smkb
őstag
Termigáßor
#44
smkb
őstag
válasz
Termigáßor
#44
üzenetére
"És egy saját api az AMD részéről? Mondjuk alapul veszik az Opengl-t kivágják a visszafelé kompatibilitást, teletömik saját utasításokkal. és kész. Gondolom én egyszerű paraszti aggyal..."
Ahhoz kicsit nagyobb piaci részesedés kellene ... NV sem tehette meg, mikor nagyon a toppon volt sem...
-
smkb
őstag
AMD Drivert megkerülve direktbe címzed a VGA portokat és írod olvasod a memóriacímeket? a CTM felület nem az AMD drivert használja, azt is megkerüli? Már a DirectX is pont egy csúnya dolog, az is annó a driverek megkerülésére, hw közelibb egységes programozási felületnek készült. Nem véletlen okozott kezdetben rengeteg rendszerösszeomlást. Ha az oprendszernek nincs felügyelete a hw erőforrások kezelése felett akkor ott minden elszáll a búbánatba csak egy félrecímzéstől... öngyilkos dolog ez 2011-ben ilyen komplex oprendszerekben, és szó szerint nem is megengedhető. Többek közt ennek is köszönhette az MS hogy a Win olyan olyan megbízhatatlan oprendszernek volt titulálva jóideig. Nem fogja támogatni sem engedni az ilyen akciókat az AMD részéről, hogy sajét oprendszere renoméja bánja.
OSX-ben Apple többek közt ezért is nem hozott be directx szintű api-t.
-
#44
Termigáßor
aktív tag
Abu85
#43
Termigáßor
aktív tag
-
Abu85
HÁZIGAZDA
Az MS ott nyert sokat az OpenGL-lel szemben, amikor a DX10-zel bevállalták a reformot. Kilőhették a visszafelé kompatibilitást, és ezzel nagyot léptek előre. Az OpenGL esetében a visszafelé kompatibilitás sokkal kritikusabb. Az MS helyzete egyszerűbb volt, mert szinte csak a játékokat érintette a változás. A Khronos API-ja mögött komoly cégek vannak, akiknek nem mondhatod, hogy bocs, de írd újra az alkalmazást.
-
Jester01
veterán
Ez csak azt jelenti (jelentené), hogy az MS-nek sikerült megint megölnie egy szabványt, ahelyett, hogy az erőforrásait annak javítására fordította volna.
Szerencsére most egyre több különböző rendszer üti fel a fejét (főleg mobil fronton), és így a szabványok ismét erőre kaphatnak. Amúgy a muksó is azt írta, hogy azért az opengl még mindig versenyképes.Linuxon meg úgysincs directx tehát igenis szól mellette valami
Egyébként ha a vga gyártóknak nem kellene kétfajta api-ra is drivert fejleszteni, akkor lehet, hogy hatékonyabbak lennének. Értelemszerűen nem az opengl-t kellett volna hanyagolni.
Továbbá az opengl 4-es sorozat tudtommal sok újítást hozott, éppen abba az irányba, hogy minél hardverközelibb legyen kevesebb API overhead-del.
-
-
#40
Tonyius777
tag
Tonyius777
tag
Kéne egy game üzemmódú OP rendszer PC-hez és akkor megvan oldva
-
smkb
őstag
Te is tudod Abu, hogy a natív hw programozás nem lehetséges. Melyik oprendszer enged ilyet? Mutass nekem egyet az utóbbi 15 évből. Ennyi, ezen vitatkozni sincs mit, meg elméletileg felvetni sincs értelme még az AMD-nek sem. Nem a DOS korszakban élünk. Programozhatnak natívan hw-t, ha csinálnak magukan egy játékplatformot saját OS-el, addig meg max fantáziálhatnak róla...
-
buzus
aktív tag
Ezért mondom én azt és fel sem tudom fogni miért nem játszották be a gyártók hogy kidobnak konzolhoz egeret meg billetyűzetet. (Mennyibe tartana nekik? 0. Egy Trustot megkérnek hogy szarér hugyért gyártson essencial egeret - Amiért ugye + pénzt el lehet kérni, plusz nagyon sokan rákapnának ezért a consolra így az eladásokat is megdobná)Számomra ebben a pillanatban jönne el a kánaán, megkockáztatom minden gamernek. Ettől a ponttól kezdve fölöslegessé válna az egész évente történő gépfejlesztés, gépigyény találgatás, fagyás, nem indul el stb. Gyerekek, nem lenne jó? Viva la Resolution
-
#37
Termigáßor
aktív tag
ftc
#16
Termigáßor
aktív tag
Most is el lehet lenni 3 évig egy kártyával ha az ember jól választ, és nem cseréli közben dupla akkorára a monitorát.. (pont 3 éves lesz a 4870-esem és eddig nem hagyott cserben. Lehet, még egy generációváltást kivárok vele - szerencsére 1GB-os)
Amúgy az AMD-s úriember felvetése nem hülyeség. Nekem is a 90-es évek jutottak eszembe (régi szép idők...). De a natív támogatás tényleg utópia, inkább saját api kellene mint anno a 3Dfx glide-ja! Ha nem pusztul ki a cég mögüle még ma is létezne! Szóval lehet hogy nem lenne 10-szeres a sebességnövekedés csak (optimista becsléssel) 8x, de legyen csak duplája, máris beelőzték a konkurenciát egy generációval! Mert sajnos csak ez számít nekik. Nem az a lényeg hogy vásárlóként mi (hosszú időre) jól járjunk, hanem hogy éppen annyival legyenek jobbak, hogy őket válasszuk. ... és mindig vegyük meg a következő generációt is.
-
Na elolvastam én is. Carmack szerint az utóbbi 10 évben a DirectX viszi előre a PC 3D platformot, az OpenGL csak követi, míg régen ez fordítva volt.
Aztán hogy Carmack még mindig OpenGL-t használ, azt is meg lehet érteni, hiszen biztosan nagyon sok időbe és energiába telne átírni DX alá minden fejlesztői eszközt, de kijelenti, az OpenGL még mindig szépen dolgozik, és nem jutna olyan előnyökhöz az átállással, ami miatt megérné neki a sok hűhó.
Ha eltűnne az API, akkor pont az a "jóság" szűnne meg, ami eddig biztosította a felhasználóknak a kompatibilitás kérdését, a fejlesztőknek meg az egységes felületre történő fejlesztés lehetőségét.
-
Abu85
HÁZIGAZDA
Olvastam én is. Teljesen igaza van. Az OpenGL mellett nem áll semmi már. A DX11 lelépte.
Azért meneteltünk a DX mellett ennyit, mert általánosan jobb, mint az OpenGL. Ez persze nem azt jelenti, hogy örökké kötődjünk a DX-hez. A vázolt problémára a megoldás a natív programozás. A problémát az API limitációja okozza. Ezt úgy lehet megkerülni, hogy elveted az API-t elkerülve ezzel a limitációt.
-
2 évig sőt 3ig is elég volt egy VGA...
Erre azt mondanám, hogy kb addig is spóroltunk rájuk. Mikor megvettük az adott kártyát, már mehetett is a gyűjtés a következőre.
Nem tudom miért gondoljátok, hogy ha kevesebb tipust (ergo több darabot, nagyobb időközönként) adnának ki, akkor nem lenne-e annyival drágább, mint amennyit nem költöttünk el közben?
Miért zavar az bárkit, hogy minden évben jelenik meg új hardver család? Ettől a "régi" géped elavult és nem indul el többet? Nem ugyanúgy futtatja a programokat, mint a megjelenés előtt 2 nappal?
Ha nincs igényed nagyobb teljesítményre, akkor kivársz 2-3 évet és veszel akkor újat, mint régen, mikor csak ilyen időközökben jelentek meg.
Ha meg igényeled a nagyobbat/újat/többet, akkor van lehetőséged sűrűbben venni mint 2-3 év.
Ez a választás szabadsága. Miért baj ez?
-
Geri cimbora (sokszorosan bannolva innen a PH-ról
) szokta hangoztatni az OpenGL előnyét azzal, hogy mindenféle gyártósecifikus kiterjesztést lehet hozzá készíteni és meghívni a programban. Azt nem tudom, hogy az OGL korlátozza-e a rajzolási parancsok számát, mint ahogy a DirectX teszi, ezt kéne egy hozzáértőnek megmondania. Persze az is igaz, hogy OGL-re fejleszteni (sokkal?) macerásabb, mint DX-re.Ha már eleve arról beszélünk, hogy natív hardvertámogatás kellene a programokba, akkor az OpenGL egy lépés lehet efelé. De akkor meg minek meneteltünk ennyi évet a DirectX zászlaja alatt?
Felmerült még az is bennem, hogy a jó öreg HD 3850 kártyám milyen szépen futtatná a mai programokat is, ha nem lenne szoftveresen (az API által) korlátozva. Vagy rosszul gondolkodom?
Abu85 #25: Itt beszél Carmack a Dx11-ről, és ahogy látom, ez eléggé friss anyag.
-
Löncsi
őstag
Hát, ha az AMD mondja, lehet igaza van.
Igazából, hogy mi lenne a megoldás azt nem tudom, van idejük átgondolni, azonban ha következő generációs konzolokkal nem tudja felvenni a versenyt az adott architektúra/API/üzleti-modell vagy akármi, akkor nem tudom ki fog vásárolni AMD-s gépet/kártyát.
-
-
#24
Satan_Claus
őstag
Satan_Claus
őstag
Uristen, azt hittem Kevin Spacey van a kepen
-
Nem véletlenül lett PC-re kitalálva a DirectX API, nem kell azt elhagyni, inkább úgy továbbfejleszteni, hogy ne szabjon gátat a hardverek képességeinek amellett, hogy biztosítja az alkalmazások felé az egységes felületet.
Esetleg érdemes lenne megfontolni az OpenGL használatát, ami talán jobban igazítható a hardverek képességeihez. Láttuk, hogy az egyébként lassú
fosGeForce FX milyen gyors tudott lenni OpenGL alatt a Radeon kártyák ellenében (és ennek köszönhetően voltak a Quadro kártyák eladhatóak voltak a professzionális piacon; a munkahelyemen is futnak még NV3xGL alapú kártyák a tervezők gépeiben).Ha esetleg valaki ért az OpenGL-hez, akkor mondhatna szakavatott véleményt a felvetésemről.
-
Én egy kicsit másként értelmeztem a cikket és szerintem is jó irány lenne a natív támogatás. Anno 94-96 körül nem voltak ekkora erőforrások, mégis könnyedén meg lehetett oldani, hogy a jobb játékokban beállítható volt, hogy milyen renderelőt használjon.
A mostani bizonytalanságot a programok készítésénél, a hardver variációk végtelen száma adja. Így akármennyire is függetlenítené a programozókat az api a hardvertől, nekik kvázi meg kell saccolni, hogy milyen erőforrást akarnak felhasználni, majd azt butítani a lehetőségekhez képest, hogy a kisebb erőforrással felruházott gépek is futtatni tudják. Így viszont a saccolás pontosságán múlik az elérhető maximális minőség is, hiába lenne még erőforrás bőven. Jelenleg csak vaktában elküldik a számítási igényt az apinak, ami ugye futtatja a hardveren, aztán az vagy tud vele kezdeni valamit, vagy nem és szaggat, optimalizálatlan.
Ettől eltérő lehetne a gyakorlat, ha pl közvetlen a számolóegységeket címeznék. Futtatás előtt ellenőrizné a számolóegységek számát, ami 1db-ra vetítve ugye jól kontrollálható erővel rendelkezik, majd ennek megfelelően csak sokszorozná a futtatást a magok számával, ami mind a képernyő egy részét számolja.
Sokkal-sokkal hatásosabb lenne és nem függne gyártótól, tehát nem külön vga kártyákra kellene optimalizálni, bár tény, hogy alapjaiban változna meg a felhasználás és a programozás. Az biztos, hogy csak az átállás lenne nehéz, a programozási része gyerekjáték lenne egy mai programhoz képest.
Szerintem inkább erre gondolhattak. Majd az idő igazol, vagy cáfol.
-
SpeedR
őstag
válasz
Cathfaern
#13
üzenetére
Ez rendben van, de nem sokra megy a gyártó a szép grafikával, hogyha nem tud kellő darabszámú chipet eladni. A nagyfokú optimalizálás végső soron a fejlesztés lelassulásához és az árak emelkedéséhez vezethet. (kevesebb darabszámon kell produkálni hasonló mértékű profitot)
-
#20
Day 'n' Nite
tag
-
#18
Dark Archon
addikt
Cathfaern
#13
-
ftc
nagyúr
Hát igen..mennyivel ésszerűbb lene ha pl 2 évente jelenen meg csak új architektőra nem 3/4 évente... Lehet egy pár gyártó csődbemenne...de eljönne az amikor elekezdődött a 3D-s játékok kora... 2 évig sőt 3ig is elég volt egy VGA...
LEhetne 2 évente egy új architektúra ami telejsítményben is meg fogyasztásban is jobb lenne az elődnél.... s így lehetne azzal foglalkozni, hogy jobban fussanak a gamak
-
Cathfaern
nagyúr
Gondolj bele abba, hogy jelenleg a PC-k grafikája lényegében ugyanolyan, mint egy konzolé. Egy konzolt megkapsz 70ezer Ft-ért, egy PC-ből csak a VGA kerül ennyibe (kis csúsztatással). A VGA gyártóknak pont, hogy az az érdeke, hogy minél szebbek legyenek a játékok, mert hiába az erős hardver, ha nem tud szebbet mutatni, mint egy jóval olcsóbb konzol, az emberek az utóbbit fogják venni. Mert az átlagot nem érdekli az, hogy hány TFLOPS
-
SpeedR
őstag
Furcsán hangzanak ezek a kijelentések egy olyan cég alkalmazottjának a szájából, amelynek elemi érdeke, hogy a játékok hardver igénye folyamatosan növekedjen, hiszen így biztosított a folyamatos gpu eladás, és az árbevétel.
Egyébként az ötlet nem rossz, csak kár hogy kivitelezhetetlen. -
Cathfaern
nagyúr
És itt elő lehet venni újra a cloud témát. Amikor jött a cloudos "játékszolgáltatós" megoldások, mindig az volt az ellenérv, hogy milyen géppark kéne ahhoz. Ha igaz amit itt állítanak, akkor megfelelő optimalizálással 4-5x-ös gyorsulást el lehetne érni adott hardveren, ha direktbe arra mennének rá. Értelemszerűen ha egy ilyen cloud gépparkban a hardverek (közel) azonosak lesznek, innentől kezdve lehetne rájuk optimalizálni... és máris nem kell annyi erőforrás, mint ha sima PC-ket néznénk.
-
#7
Dark Archon
addikt
Hát ez egy utópisztikus baromság, amiről az ürge beszél. Tulajdonképpen leírta a konzolokat. Nem kis visszalépés lenne, ha egy adott játék csak egy adott konfigon futna, mint anno a 90-es években, mikor konkrétan be kellett állítani egy játéknál a hangkártyát, VGA-t, stb.
-
#6
Ł-IceRocK-Ł
veterán
Ł-IceRocK-Ł
veterán
Na pont ez az az ügy, amelyik sosem fog teljesen megfeleni a másik félnek. (gondolok itt hardwergyártó és szoftverfejlesztő, illetve a két nagy Gpu gyártóra). Profit téren nem jó a gpuk gyártásának csökkentése, a szoftverírók általában tesznek még az optimalizácóra is. Szegény user meg azt se tudja hogy mivan. Hogy hogy lesz ez megoldva...
-
#3
Brown ügynök
senior tag
misx
#1
Brown ügynök
senior tag
Pontosan. Annyira gyorsan jönnek ki a hardverek, hogy nem tudnak sok, igény munkát végezni a szoftverek terén. A szoftver mindig valamennyi lemaradásban lesz a hardverhez képest de jó lenne ha hagynának elég időt a hardver gyártók a szoftverekre is. Vagy a szoftverírásra kellene valami forradalmi gyorsítás?
-
smkb
őstag
Ez vicc....
már a 3 hwre x360/ps3/pc sem optimalizálnak, nemhogy még elvinni szinte vga modell szintre... nonszensz... konzolokon is csak az exkluzív címek mennek el nagyon az adott hw irányába optimalizáltan, a multiplatformok nem... és ez utóbbiak vannak többségben... 2011-ben ezt kijelenti nagyon vicces... platformok... amd technológián belül is jópárféle generáció van most is egy a termékpalettán... oszt melyikre optimalizálnak ? A Fusionokben ami elvileg ugye egyik legmodernebb VLIW5 figyel a HD69xx-ekben meg VLIW4... na most akkor melyikre lőnek ? Vicc...mégha mondjuk 70-80%-ban uralná az AMD a vga piacot... de hát ugye pont, hogy nem...Azt meg mindenki aki programozott valaha, tudja ezeréve, hogy nincs annál nagyobb rendszerstabilitási veszélyforrás, mint natívban programozni hw komponenseket memóriacímeken portokon kersztül, driverek, api-k kihagyásával. Egy normális oprendszer ilyet nem is enged meg.
-
misx
senior tag
A mai játékok nem használják ki, amit a PC valójában tud. Egy 3 éves DX10-es kártyára is oltári grafikát lehetne varázsolni, ha arra programoznák (és ezt mondjuk API-n keresztül talán egy mostani csúcskártya vinné el). Így marad az optimalizálgatás...
Meg fogtok kövezni érte, de szerény véleményem szerint, ha jóval kevesebb hardvert nyomnának ki, könnyebben menne a dolog. Pl. kétévente kijönne egy alsó/közép/felsőkat. VGA mindkét gyártótól, oszt cső. Ez így összesen 6 kártya két éven át. Alsókat-low, Közép-Medium és Felső-High grafikához. És megszűnne a nem indul, nem fut, akad, stb, csak beteszed a játékot és a hardware-nek megfelelően futni, remélhetőleg fix fps-sel. Tudom ez a jelenlegi üzletpolitikát sérti, de elméletnek nem rossz.
)![;]](http://cdn.rios.hu/dl/s/v1.gif)
Lehet hogy nem lényegtelen az sem, hogy egy android kb semmi történelmi terhet nem cipel magával. (Visszafelé kompatibilitás borzalmasan útba tud lenni...)
Új hozzászólás Aktív témák
- AKCIÓ! Lenovo ThinkPad X13 Gen 5 üzleti notebook - Ultra 5 135U 16GB DDR5 512GB SSD Intel Win11
- Corsair HS35 ( v1, nagyobb fülpárna méret) Stereo Gaming fejhallgató
- LG 27GR95QL - 27" OLED / Limitált LoL Edition / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync
- Lenovo ThinkPad T14 Gen1 Ryzen5 4650U
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5060 Ti 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest