Aktív témák
-
Thom!
veterán
Szóval az NVIDIA-nak nincs értelmes, kezelhető DX 9-es kártyája.
Úgy melléfogtak az NV3× csaladdál, mint az állat! THE END: Carmeck szava szent. :D
Kár volt belefektetni azt a pár száz millió dollárt. Ez volt a NV legnagyobb hibája, a sok pénz, ami elment a konyhára. Talán az NV 40 feltud mutatni vmit. -
csucs
csendes tag
A játék fejlesztőinek és a játékot játszó embereknek is jó, ha egységesítik a vasak tudását. Így gyorsabban tudják a játékokat fejleszteni (lásd konzolgépekre fejlesztett játékok), a felhasználók így hamarabb juthatnak kedvenceikhez. Ezen kívül természetesen a fentebb említett állítás is igaz, mármint az, hogy a felhasználóknak nem kéne aggódniuk, hogy vajon fut-e náluk a progi.
-
Thom!
veterán
Carmeck szpíkel:
Sajna úgy néz ki, hogy ez a probléma a legtöbb DX9 játéknál elô fog jönni. A Doom-nak van egy beállítása, amely a GF-FX alacsonyabb precízitású renderelését használja, de ha a standard fragment beállításokat használja (mint az ATI), akkor sokkal lassabb. Az alacsony precízitás a Doom esetében nem igazán számít, de a jôvôben megjelenô, kifejezetten DX9-re dizájnolt játékok esetében már nem egy elfogadható megoldás. -
rudi
nagyúr
veszett dolog ez a dx9 hardver!
Egyre inkább az a véleményem hogy jó húzás volt az MStől kitalálni a DXet. Így elvileg a programozóknak nem kellene külön optimalizálni minden gyártóra és az usernek nem kellene aggódnia vajjon meg-e majd a cucc a kártyáján.
Az lenne a jó ha a HWgyartó garantálná a FULL DXkompatibilitást, cserében részt vehetne a kidolgozásában. Szintetikus benchmarkot meg csakis a két HWgyártó programozóiból alakított csapat írhatna esetleg az MS vagy valaki más hitelesíthetne egy gamet amiből x hosszúságú session lenne a benchmark. -
csucs
csendes tag
A dx9 azért van, hogy a fejlesztők tudjanak alkalmazkodni ehhez és ne kelljen minden vasra külön optimalizációt fejleszteniük. Az nVidia épp ezért jár hibás úton, ugyanis a kártyáik nem pontosan dx9 kompatibilisek.
A fejlesztők így kénytelenek többletmunkát végezni -> időveszteség -> idő=pénz , amit a vevőkkel fognak kifizettetni. -
rudi
nagyúr
Beyond3d:
''Sabastian wrote:
When will Beyond3D have an article regarding the Half Life 2 shader issues?
Let the man have some sleep It only happened a few days ago, these things take time to do properly.
Dave has been at 2 graphics thingys (Shader Day (Seattle, US) and Mojo Reloaded (Guildford, UK)) on 2 different continents in the last 3 days. Combine that with the effort to keep the site running smoothly(and of course his normal life), he's probably a bit snowed under at the moment. ''
Remélem holnapra lesz valami -
rudi
nagyúr
3dcenter-es cikkben nekem is az tetszett hogy megmutatta milyen gyorsulások lehetnek optimális esetben.
Veszett golog lenne egy CPU a VPU helyén. Vegyünk egy 2GHz-es XP-t megtámogatva 512MB ''csak'' DDR400as RAMmal. Az árcédulán még mindig kisebb szám figyelne még egy közepes kártya áránál is :) -
rogers
aktív tag
Azt nem tudod megítélni, hogy a GPU vagy nevezzük akárhogy:) és a CPU fejlődés hol tart egymáshoz képest, bár egyszer feltettem magamnak a kérdést, hogy mondjuk mi történne, ha egy csúcs intel v. AMD procit tennénk a GPU helyére... Mennyit bírna hozni ha csak azzal kéne foglalkoznia? :) Persze ez lehetetlen, mivel másra lett kitalálva mégis érdekes gondolatkísérlet...
A memória sávszélességről: igen, igazad van mostanáig a memória sávszélesség volt a legfontosabb limit és ezt elég jól lehetett látni a fejlődésen. Ebben a fórumban is témáztunk pár 100 hozzászólással alább, hogy ennek a korszaknak kezd végeszakadni. Pont ezért is van gondban picit az nVIDIA, mivel mostmár a memória sávszélességen kívül egyre nagyobb jelentősége kezd lenni a nyers számítási teljesítménynek, köszönhetően legfőképp a DX9-es elvárásokban. Az nVIDIA nagyon erős memóriasávszélesség ügyben, de sajnos nyers számítási teljesítményben nem annyira. (ld. a 3dcenter grafikonokat). Ezért is fordít annyi energiát a driveroptimalizálásra, mivel azzal próbálja kompenzálni ezt a feltevések szerint... -
rudi
nagyúr
Perszehogy RAM limitáltak hiszen nincs cache memóriájuk 2-3 szintben. Perszehogy nem tudnak annyit de akár driver szinten is lehet valamiféle spekulatív algoritmust írni hiszen SDK-shaderkód-driver-hardver a teljes kör és nem felsőnyelv-ASM-hadver. Szerintem a Transmeta chipek felé konverálnak a VPUk.
Szerintem is a cpu-technológia teljesen más szinten van mint a VPUk, hiszen egyik oldalon nő a pontosság és többszáz új utasítás jön míg a másik oldalon ''csak'' MMXek SSEk vannak, egész régóta 32biten. -
rudi
nagyúr
''Egyszerűen fele annyi PS kakaó van az FX-ben, példának okáért.''
Kb. ez PILLANATNYILAG az igazság. Remélhetőleg egy újabb driver valamit segít majd. Én látok rá reményt hogy az NV megoldja a gondokat hiszen ott a cg és az aquamark eredmények és Carmack sem látja egyenlőre annyira sötéten a jötőt.
Lényeg hogy PILLANATNYILAG az NVidia bajban van, presztízst és vásárlókat veszít napról napra. -
Tisztában vagyok a függőségekkel; és pl. ez az, ahol a GPU-k közel nem tudnak annyit, mint a jelenlegi CPU-k: a speculatív végrehajtásban. Persze megint ne túlozzuk el a dolgot: amit lentebb írtál példa, az manapság nem visszafogó tényező a videokariknál. Nézd meg a teszteket: gyakorlatilag az összes csúcsGPU ramsávszél-limitált.
A regiszterszám növelésében a CPU-k megint csak a GPU-k előtt állnak, kb. 10 éve már, hogy RISC procikban bevezették a regiszterátnevezést/rejtést.
Szóval még mindig azt gondolom, hogy bár egy GPU-ban 2x annyi tranyó van, mint egy CPUban, mégis jóval előbb jár a CPU-technológia, mint a GPU.
A soros/párhuzamos végrehajtás majd' mindig ellenkező hangsúlyokat vár el a tervezőktől, most küzdenek a polimorf technológiákkal, közepes sikerrel (2010-re ígérnek ilyesmiket). -
rogers
aktív tag
Hát ez az. A vége úgyis az lesz, hogy a nagy fejlődésben odáig általánosodnak a grafikus chipek, hogy teljesen külön kód kell majd hozzájuk. Ahogy vhol írták is az már ma is mindenkinek szinte természetes, hogyha Intel és AMD performanciát mérnek komolyan akkor speciális, az adott processzorokra optimalizált kódokat hasonlítanak össze. Senki sem kiált csalást amikor egyes programoknak létezik Intel és AMD optimalizált változata.
Nos a grafikus chip piac most ezen folyamat elején tart. Sikerült olyan szabványokat létrehozni a rugalmasság jegyében ami már nagyon tág teret enged a harver fejlesztőknek a megvalósításra. A különböző út pedig különböző technikát jelent.
Ahogy a beyond3d cikk írja: nincs olyan, hogy vertex shader hardver. Van egy utasításkészlet meghatározva mindenestül, aztán, hogy a gyártó azt hogy oldja meg az rá van bízva. Több pipelne? SIMD? Más? Ki tudja. Mindenki másra esküszik, mivel minden megoldásnak van előnye és hátránya is. A kérdés csak az, ki tudja ezek jobban beazonosítani, felmérni, kihasználni? Az ATI és az nVIDIA külön utakon jár és ez jó is így... Ha van két megoldás, általában mindig van egy jobb, meg egy kevésbé jó. (szándékosan nem írok rosszat).
A cikk azt is írja, hogy egyáltalán nem triviális az a válasz sem, hogy 2 shader jobb mint egy... :)
At the end of all this I hope that its clear that there is no such thing as a ?vertex shader?, there are all kinds of different implementations possible and all have their own advantages and disadvantages. Its important to realise the essence of a good driver level compiler and developer education in terms of hardware efficiency. I at least we can move away from thinking that 2 shaders are always better than 1 shader... -
rudi
nagyúr
Nálam is hasonló kép kövonalazódik. Meglátásom szerint a kutya a miltipass cuccoknál kell hogy legyen elásva amikor egy kimeneti adat bemeneti lesz. Vagy kell a következő vertex kiszámolásához.
Azért ebből is játszik hogy általában az az algoritmus van könnyebb helyzetben aki több pipelineből gazdálkodil. -
rogers
aktív tag
#654, #652, #650.
Ebben a pipeline-latency dologban szerintem kis kavarodás van még akár saját magamon belül. A latency-t tudjuk mit jelent, mégis sok értelemben használjuk.
A Beyond3Ds cikkből vett definició alapján jó felé megyünk és a cikk folytatásában van a kutya elhantolva, amikoris azt kezdi magyarázni, hogy ez a latency mitől is függ. Ez egyben azt is próbálja bemutatni, hogy a grafikus chipekben is elég sok dolog van ami hat a latency-re (növeli azt) ezáltal hasznos processzor időt küld veszteget el.
Az alappélda amit hoz a cikk egy egyszerű eset, az egymástól függő utasítások problémája:
MUL R2, R0, R1
ADD R3, R2, C1
Látható, hogy a 2. utasítás függ az első eredményétől (R2 a kimenete az elsőnek és ezt inputként veszi a második)
Ha veszünk egy eszerű pipeline felépítést:
Adat be --> Aritmetika 1 --> Aritmetika 2 --> Aritmetika 3 --> Adat kiírás
Normál esetben a folyamat úgy néz ki, hogy a proci veszi az első utasítást, és amint az elindult a pipeline-ban rögtön veszi a következőt. És itt a gond, mivel azt nem tudja végrehajtani egész addig, amíg az elsőnek a végére nem jutott és rendelkezésre áll az eredmény. Így keletkezik a ''buborék'' a rendszerben tehát egy csomó műveleti idő veszendőbe megy... ...hacsak :)
Megoldás persze van, de ennek ára is van. A cikk mutat több módszert is az egyik például az, hogy ilyen esetben úgy kell szervezni a számítást, hogy egyszerre több vertex adatával foglalkozunk, tehát mondjuk az első utasítást végrehajtjuk 4 különböző vertexre, így elkerülve a függőséget. A nehézség ilyenkor az a dologban, hogy így a pipeline-t fel kell készíteni 4 párhuzamos adatsor tárolására, ami minden regiszter megnégyszerezését igényli ami pedig bonyolítja és drágitja a chipet, mivel több tranzisztor megy rá...
Szóval nem egyszerű a kérdés, de az biztos, hogy a modern grafikus chipek egyre inkább kezdenek olyan problémákat felvetni amilyeneket a ''sima'' CPU-k, mivel egyre nyitottabbak és egyre programozhatóbbak.
A dinamikus és feltételes elágazások és ciklusok használata részben már most is megengedett az utasításkészletekben, a jövőben pedig méginkább szélesednek a lehetőségek, ezzel is bonyolítva az életet és elvárva a kódoptimalizálást annak érdekében, hogy a chip nyers teljesítményét minél jobban ki lehessen használni. -
rudi
nagyúr
Kicsit árnyaltabb ez a mire is fejlesztünk mit. DX9et bíró VPU már eszelősen hasonlít a egy CPUra, a maga ciklusaival, lebegőpontos adataival. A DX specifikációkban véleményem szerint csak ''ajánlások'' vannak vagyis inkább alapfeltételek (pl. legyen lebegőpontosan pontos, legyen x-hosszú ciklus, legyen y alaputasításból programozható) aztán az implementáció már a hardveresek dolga.
A veszettül nehéz dolog az optimalizáció vagyis a kód hozzákalapálása a vashoz. Ezt alapvetőne 2 helyen lehet: programkódban (csak egy programra/motorra) vagy driverben. És a kellemetlen ha egyik gyártónál alig kell optimalizálni míg a másiknál keserves munka (persze nincs lehetetlen ahogy a C64nél is láttuk).
Tervezés:
Már írtam hogy 2út van
1. drága chip sok független pipelineval amihez könnyű drivert csinálni - ati
2. olcsóbb chip kevesebb esetleg egymástól függő pipelinek és KOMOLY programozás driver szinten. - NV
A második út sokkal olcsóbb lehet ha megvan a programozói potenciál (volt 3dxf-esek)
Most felmerülhet mégis miért drágább az NV chip ha elvileg olcsóbb. Szerintem a 0,13miatt. -
-
rudi
nagyúr
A GPU nem is hasonlít a CPU hoz de a VPUmár annál inkább. Asszem visual processing unit a rövidítés és a DX9es chipekre használják, pontosan azért mert itt már vannak ciklusok (for) és elágazások (if-then, while). Az egész grafikai számolás mátrixtranszformáció szóval máris ott tartunk hogy CPU, innentől kezdeve kritikus a branch prediction és a lantency.
Latency itt egy kicsit más mint a ramoknál mert itt inkább a pipelinek process idejéről van szó:
''You might wonder what the difference is between 1 complex block and 3 simple pipelined blocks. The first case executes the operation in 1 clock, the second case can also execute one operation per clock, but the time between starting and ending the operation is actually 3 clocks (each pipeline block takes a clock) – so there is a delay of 3 clocks between starting the work and getting the result, this is called “latency” there is thus a latency of “3” for the second case while the latency of the first case is “1”. '' - beyond3d - -
rudi
nagyúr
''Szoval jol értettem,hogy nem minösül csalásnak, ha a driverben átpakolják a 6-6 kérlemet 4-4-4 kérelemre? Ezzel csökken a minösége?''
Akkor nem csalás ha nem megy a képminőség rovására. Ha nem történik ''adateldobás'' akkor nem romlik a minőség. ''Adateldobás'' lehet pontosság csökkentése (ol. 32bitről 16ra) vagy gyengébb rutin használata itt-ott (pl. gyorsabb de pontatlanabb hatványozó, alacsonyabb fokú furie transzformálás).
A jó ütemezés és kódszervezés nagyon áldásos lehet, és nem megy a minőség rovására. Legyen megnit a 6-6 vs 4-4-4 probléma pl 4 pipelineval.
4-4-4 simán 4-4-4 szóval 3kör és közben semmi más.
6-6 lefutása rossz esetben 4-2-4-2 szóval 4kör. (persze ha megint jó a kód és van fölös 2-2 utasítás akkor az mehet azokban a körökben amikor van 2 szabad, így igaz hogy még mindig 4 kör az eredeti 6-6unk de közben egy 2-2t is kiszámoltunk szóval nincs akkora veszteség, remélhetőleg ilyen irányban tud lépni az NV.
3dcenter-es cikkben lehet olvasni hogy a FXek felveszik a versenyt az ATI megoldásokkal ha számukra optimális az utasítások eloszlása szóval egy jó detonator segíthet, kérdés hogy mennyit... -
xuldar
addikt
Igen, én is olvastam, hogy már nem is GPU-nak, hanem VPU-nak hívják az új grafikus processzorokat, mert egyre jobban programozhatók, elvileg a Dx-et is ebbe az irányba próbálja tolni a M$. Minél jobban programozható, annál összetettebb utasításokat tud végrehajtani. Bár elvileg ettől nagyon bonyolult lesz.
A pipeline-okról meg úgy tudom, hogy nem jó, ha túl hosszúak, mert ha egy utasítás végeredménye nem a becsült adat lesz, akkor üríteni kell a pipeline-t, és ez nagyon nagy időveszteség. Ezért is a számukat növelik, nem a hosszukat.
Hogy mit fejlesztenek mi alá, az csak és kizárólag pénzkérdés manapság.
És az NVidia jóval kisebb cég, mint a M$. Sőt, nem is tudok még csak hasonló méretű céget sem (kivéve IBM, de az alig foglalkozik a PC-vel). Ebből következik, hogy a PC-k világában mindent a Windows alá fejlesztenek, és nem a w-t fejlesztik a vasak alá... -
rudi
nagyúr
Először javítom magamat:
Igazatok van a Q3 tényleg openGL de a DoomIII már DX. Kicsit pontatlanul fogalmaztam mert nem konkértan a dx/oGL-t akartam piszkálni hanem a t&l-t ami sima quake3ban nincs de q3arenában már igen mert az ottani oGL verzió már tudja. Nem állítom hogy oGL=DX, de elvileg ez a két platform csak az egész folyamat csúcsa és a kompiler felett van szóval a chip szempontjából majdnem indegy hogy Dx vagy oGL, ahol számít az a kompiler és a driver.
Az egész motorhasonlítgatást inkább azért írtam hogy látszon, alig pár motor van amit a nagy halom program csinál és általában nem az a lényeg milyen lesz az ''anyajáték'' (ahol a motor debütál) hanem az hogy milyen a motor, mit bírnak vele a kártyák.
Motorok licenszelése:
Igaz hogy az EIDOS csak kiadó, de ők fektetik be a pénzt és nekik joguk van motort választani. Általában a kiadók birtokolják a licenszjogokat és ők kérik fel a programozócsoportokat a melóra (pl. NFS sorozatot sokan csinálták és így van ezzel az EA meg a többiek is). -
Úgy néz ki jó dolgokat mondasz (én csak laikus vagyok videokari ügyben, csak filozofáltam róla egy sort :) )
Valójában összekevertem a pipeline szélességét a hosszával : tehát valóban kevésbé lényeges a hossz, inkább a darabszám számít.
A latency szerintem kevésbé számít, mert a ramok általában úgy működnek, hogy a tRAS és a TCAS meg 0.5 ciklus után (=latencyk) órajelenként érkezik az adat, hogyha a processzor tudja fogadni. Ha a pipelineok egyenként programozhatóak is, lehet folyamatos adatfolyamot pumpálni beléjük.
Aztán lehet, hogy nincs igazam, vitatkozz.:) -
rogers
aktív tag
Meglehet, hogy én értettem nagyon félre vmit azokban a cikkekben amiket olvasgattam (alább ajánlották őket), de amit írsz szöges ellentétben áll az értelmezésemmel.
1. Ha jól értem a cikkeket akkor a GPU-ban a pipeline hosszak alavetően rövidebbek mint a CPUkban, mivel a GPU próbál nagyon rugalmas és programozható maradni, ezáltal nagyon nehéz a műveleteket apró és egyszerű lépések sorozatára bontani.
2. Másik dolog amit én megértettem (lehet, hogy rosszul), hogy a pipeline hossz, pontosabban a egy adot pipeline művelet egyszerűsége avagy bonyolultsága összefügg az órajellel. Ha tehát bonyolult a művelet, az órajel is alacsonyabb lesz, mivel tovább tart megcsinálni a dolgot. A GPU-k órajele messze elmarad a CPUkétól, aminek biztos van 1000 más oka is, de az bizonyos, hogy a műveletek egyszerüsítése sokkal könnyebb a CPUknál mint a GPU-knál.
3. Egy idézet a 3dcenter-es cikkből a jövőre vonatkoztatva:
...it is important to know which targets nVidia intends to hit with NV40. Despite the rather limited availability of information regarding this topic, it is highly probable that they want to reach PS3.0 compliance. CineFX is essentially lacking the ability to conditionally influence the execution flow of a program.
The patent mentions the possibility of single quads leaving the pipeline at any time and being replaced by others. In this context it is also mentioned that for different quads, different programs or different parts of the same program can be active simultaneously. What seems to be missing is a facility to change the program counter from within the pipeline.
This would enable dynamic branching, which is the basis for the PS3.0 main features: loops, conditionals and procedure calls. Because under these circumstances, it cannot be guaranteed that that all pixels of a quad take the same path through program code, nVidia will probably drop the SIMD approach and use an independent pipeline for each pixel.
Tehát a SIMD koncepció lehet, hogy lényeges, de nemcsak előnyei hanem hátrányai is vannak ezért egyáltalán nem biztos, hogy ez az üdvözítő út a sikerhez.
4. Szintén lehet, hogy félreértettem, de a GPU-ban a latency igenis nagyon fontos! Főképp azért, mivel itt iszonyú sok számítás történik és ha ''buborékos'' lesz a pipeline akkor nagyon sok teljesítmény megy veszendőbe. Ezért is küzdenek a gyártók ez ellen például úgy, hogy a pipeline-ba egyszerre 3-4 vertexet adagolnak hogy a függőségek és egyéb latency-t okozó tényezőket minimalizálják... -
Szerintem meg nem hasonlít a grafikai feldolgozóegység a központi feldolgozóegységhez. A grafikai feldolgozóegységnél alapvetően az egy utasítás-több adat típusú műveletek lényegesek, míg az utasításszintű párhuzamosság szinte egyáltalán nem (központi feldolgozóegységnél az utóbbi is igen fontos). Emiatt a grafikai feldolgozóegység csővezetékeinek hosszát a központi feldolgozóegység csővezetékei hosszának többszörösére lehet növelni, hiszen nem kell foglalkozni az döntéskimenetel-becsléssel sem (túlságosan), meg a csővezeték okozta késleltetések sem kritikusak (ugyanúgy, ahogy a videokártya véletlen hozzáférésű memóriáinál a sávszélesség a fontos, a késleltetések kevésbé).
jobb? :D -
Hm.
Szerintem meg nem hasonlít a GPU a CPUhoz. A GPUnál alapvetően SIMD műveletek lényegesek, míg az ILP szinte egyáltalán nem (CPU-nál az utóbbi is igen fontos). Emiatt a GPU pipelinek hosszát a CPU pipelineok hosszának többszörösére lehet növelni, hiszen nem kell foglalkozni branch predictionnal sem (túlságosan), meg a pipeline okozta késleltetések sem kritikusak (ugyanúgy, ahogy a videokari ramjánál a sávszélesség a fontos, a latencyk kevésbé). -
Újabb intenzív pucolás... nem eccerű :F
-
rogers
aktív tag
Na ez azért ebben az esetben szerintem csak részben igaz. Amit mostanában összeolvastam ezekről a DX8 és DX9-es szabványokról abból az látszik, hogy a grafikus hardver kezd egyre inkább egy célhardverből fejlesztői környezetté fejlődni. Az egész történet most nekem arról szól, hogy igyexik mindenki olyan specifikációkat és szabványokat kitalálni amelyek kellően rugalmasak és lehetőleg nem kelljen vadi új hardvert kitalálni, ha előáll vki egy újfajta 3D megjelenítési technikával.
A grafikus processzor nagyon húz mostanság már egy igazi procihoz, aminek van egy speciális utasításkészlete a 3D grafikák számításához, magyarul kihasználják azt az információt, hogy itt biztosan csak és kizárólag ilyen számítások futnak, de ennyi. A többi mind a programozáson múlik, hogy például miként használka ki azt a 256 utasításhelyet ami a DX9-es a vertex shader szabványban szerepel.
Előjönnek a pro és kontra érvek a párhuzamos feldolgozással kapcsolatban ahol az Intel és az AMD is járt ezelőtt, a pipeline optimalizáció és egyéb kérdések...
A DX9 és hasonló szabványok már nagyon nyitottak, technikailag hardverben nagyon sokféleképpen lehet megvalósítani őket attól függően, hogy mik a vezérelvek a fejlesztőknél. Sajna az nVIDIA elképzelései úgy tűnik gyengébbek jelenleg az ATIénál, de ez nem jelenti azt, hogy nem fordulhat a helyzet. Ezért erőlködnek a driver ügyben nagyon, mert ott sokat lehet faragni.
A probléma most sztem inkább az, hogy nem lehet csak úgy egyszerűen azt mondani, hogy most akkor tervezek egy vadi új chipet nulláról. A túl soká tart és valszeg nagyon sokba kerül. Mostanában mind a két gyártó azzal van elfoglalva, hogy az alapkonstrukcióját módosítgatja, optimalizálgatja. Totálisan újratervezett dolgokra egyhamar nem lehet számítani. -
xuldar
addikt
Megsúgom, míg régen a hardverekre fejlesztették a szoftvereket, ma már megfordult a dolog, és a szoftverek alá fejlesztik a vasat. Tehát már a tervezés korai szakaszában tudták, nagyjából mik lesznek a Dx9 specifikációi. Gondolj bele, az Ati is tudta, neki sikerült fél évvel hamarabb kihoznia a 9700-et, ami full Dx9 kompatibilis. Az NVidia eredeti tervei szerint is nagyjából a 9700-tel egyidőben jött volna ki az FX5800 is. Sőt, állítom, már félig lefektették Bili bácsijék a Dx10 alapjait is, és ezeket a kártyagyártó cégek is tudják, máshogy nem lenne értelme.
-
e-biza
őstag
Igen érdekes dolgot találtam itt:
[L]http://www.3dfx.com/[/L]
Get NVIDIA Product Information
Did you know NVIDIA GPUs are the graphics of choice for Half Life users? In a recent Valve Software survey, data captured from 35,488 Half Life user machines showed 67% of graphics were NVIDIA. Visit www.nvidia.com for information about the ultimate graphics for gaming.
---
Tudtad,hogy az NVIDIA GPU-t választják a Half Life userek? A legújabb (mikor lehetett) Valve Software kérdöiv szerint 35488 Half Life játékos gépében NVIDIA kártya volt...
---
Érdekes hogyan fordul a világ. -
xuldar
addikt
válasz
steveetm
#614
üzenetére
Valóban érdekes okfejtés volt, de ha elolvasod még egyszer, ő kerek perec állítja, hogy a Q3 Dx8-as, a D3 Dx9-es.
Szerintem nem lehet ''ilyen könnyen'' megmagyarázni, mivel a Geforce-ok és a Radeon-ok teljesen más felépítésűek. Azon kívül ismert volt az OpenGL és a Dx-ek minden specifikációja már nagyon régóta. Simán megépíthették volna úgy, hogy jól menjen.
Egyszerűen nincs a Geforce-okban annyi kakaó, mint a Radeonokban. Attól függetlenül, hogy a marketingesek mindent kitalálnak, hogy miért nem hozza a várt teljesítményt.
(Mielőtt valaki flémmel vádolna, közlöm, hogy Ti4200-am van, és nagyon meg vagyok vele elégedve.) -
e-biza
őstag
huh szép info dus.
amit hozzáfüznék. az eidos csak kiado igy ha ök be is intenek az nvnek,attol még a fejlesztök nem biztosan, vegyük eztet:
[L]http://www.stalker-game.com/index_eng.html[/L]
Az Unreal Tournament 2004 -röl azt deritettem ki,hogy még mindig DX 8.1 lesz,tehát jelenleg az AquaMark,TRAoD, HL2 DX9.0 ás engine (lassan szept vége ezért a HL2 -t magunk között érezhetjük). A doom 3 még sokára jön ki.
Emlitette,hogy az nvidia the way its meant to be played csak egy fizetett reklám. Vajon a fizetésbe nem tartozik bele az is,hogy optimalizálják az nv kártyákra az adott engine-t? Még a Stalker sem lesz dx 9.0 engine ha minden igaz. Szoval jol értettem,hogy nem minösül csalásnak, ha a driverben átpakolják a 6-6 kérlemet 4-4-4 kérelemre? Ezzel csökken a minösége? Mi mindent olvastál még a beyond3dn? Mármint ami ideillo. Sajnos nem rendelkezem programozási tudással igy hamar kifekszem mikor az utasitásokrol van szo. -
Ennél azért sokkal technikaibb a ''megoldás''. Egyszerűen fele annyi PS kakaó van az FX-ben, példának okáért.
Az eszmefuttatásod jó, de nagyon elméleti, míg most abszolút konkrétan van a kutya elásva. Olvasom én is a Beyond3D-t ezerrel, csak persze időm nulla, így nem bírok most mindent elsöprő hozzászólásokat firkálni :P. -
rudi
nagyúr
EIDOS annyiban intett be hogy a Tomb Raider Angel of Darkness-ben is ott van a teljesítményesés és képminőségromlás. Sokak szerint (szerintem) is sz az NV its meant to be bleyed csak egy fizetett reklám.
Elviekben nekem világos volt a beyond3Ds cikk mert tanulok ilyeneket az egyetemen de persze csak alapszinten. A lényeg az hogy 2 féle képpen lehet gyors egy CHIP.
1. marhasok konkrét utasítás van behuzalozva szilíciumból, így drágul a chip
2. írnak egy eszelősen jól tippelő, jól ütemező kompilert a vashoz.
persze az igazság megint félúton van.
Szerintem az ATI a 8/1el járt jelentősen jobban mint az NV a 4/2vel, ugyanis így van 8 különálló egységük amit egyszerűbb ütemezni mint a 4et tehát a vasuk durva teljesítményben jobb és nem kell csodákat tudnia a compilernek, így rugalmas marad és simán alkalmazkodik a DX9SDK-hoz.
A cikk amit bevágtál abban a legfontosabb a PlayStation2ről elejtett félmondat!:
''We as a developer simply do not have enough control through dx9 which is not a problem, because the days were we coded to the metal are gone ... at least if you are not on a ps2 ;)''
Szóval a kóder csinál DX9el dolgokat és adja a kompilernek, de ezzel nincs vége! Jön az optimalizálás ami már érinti az alacsonyabb szintű grafikus nyelvet (amit a kompiler generált) vagyis itt-ott a koderek módosíták a programot amit a kompiler csinált pont azért hogy a driver jobban eméssze és gyorsabban menjen.
sarkított példa: valami miatt a kompiler küld 6 feldolgozást és utána megint 6ot, ezzel a 4 pipelines FX csak lassan boldogul. Belenyúlnak a kódba és átpakolják 4-4-4 feldolgozásba és máris gyorsabb a cucc. Ezt a gyorsítást alkalmazhatják a driver fejlesztői is.
Egy konkrét program fejlesztői jobban rá tudják optimalizálni a hardverre a saját terméküket de ez akkor CSAK arra a termékre lesz jó! Ha a driverben optimalizálnak akkor lehet hogy az adott proggi nem gyorsul annyit, de a többi program is gyorsulhat, persze itt-ott rossz hatással is lehet a driver optimalizálás.
Itt jön a képbe hogy mi van ha az NV a 2. utat választja...
Tegyük fel hogy a DoomIII motorban Carmack csodát csinál (volt már ilyen igaz openGLben) és elvégzi az optimalizációk nagyrészét. Ha ez a doomIII motor szebb jobb lesz mint azok a motorok amik az NV cuccon lassúak akkor az is lehet hogy az NVnek van akkora hatása hogy rábírja a tervezőket hogy ezt a motrot használják pl. úgy hogy jelentősen megtámogatja a motor licenszelésének költségeit. Így a kisebb programozó csapatoknak 3 választásuk van:
1. csinálnak saját motrot amit megint keservesen rá kell gyúrni NV cuccra - valószínűtlen
2. vesznek egy olyan drága (relatíve) motrot ami nem NV-optimalizált és ezzel elvesztik a piac felét - valószerűtlen
3. vesznek egy OLCSÓ (hiszen NV támogatja a vásárlását) NV-optimalizált motort ami megy minden kártyán - ez könnyen lehet
Még egy észrevétel a motorok terén. Egy dx7-8as motor csinálása jelentősen egyszerűbb mint a dx9esé mert abban egy valag +fícsör van amit le kell kezelni. DX7ben elég sokan csináltak sajátot de már ott is sokan használtak quake2/3, unreal, lithtech motrot és ezeken futottak be a legnagyobb játékok talán csak a Hitman alatt van egyéni bár lehet hogy az is (lithtech). DX8as motor a quake3arena, újabb U2/UT2003 motor, talán a lithtechII vagy III (ami a NOLF2 alatt van).
És mi lesz DX9 alatt?!
Eddig van a Valves HL2 motor és az EIDOSos TRAoD motor meg a készülő doomIII és még mások amiről én nem tudok de majd aki tud az ideírtja (pl. Aquanox). Kétlem hogy 4-5nél több komoly DX9 motor születik.
Ha most az összes EIDOS game (Stalker, Hitman3 stb.) rámegy a TRAoD motorra és a HL2 esetleg CS2 meg a Warcraftok futnak majd HL2 motorral akkor gondban lehet az NV de a fajlesztők is mert elvesztik a piac felét. Ha viszont valami (pénz) hatására mindenki NV-optimalizált motort használ majd akkor minden marad a régiben, pénz beszél kutya ugat...
Vicces az, hogy eddig úgy néz ki az egész kompiler mizéria nem érinti az ATI-t mert NV-optimalizált motorban is tartja a lépést.
Most akkor nézzünk az egészer felülről.
NV - NV30 késés/leszereplés, 3dmark ''csalás'', ps2.0 gondok, NV35/intel 865/875 gondok, ps2.0 gondok - DE: megvan a 0,13as technológia!
ATI - brilliáns R300 (amit voltak olyan pofátlanok hogy 9500pro néven a középmenzőnyben is bevessenek :D ) és ezt az is alátámasztja hogy az r350ben alig kellett módosítani, egyre javuló driverek - DE: nincs meg teljesen a 0,13as technológia!
Nem állítom hogy az ATI cuccok hibátlanok, mert TVout de akár driver szinten is maradtak gondok.
Milyen lesz a jövő?!
NV - kicsit ultimátumszagú NV40. Sikerül-e optimalizálni az NV35 driverekt?
ATI - mi lesz a 0,13al? Lesz-e olyan jó az R4xx mint az R3xx?
Vegyünk két ''legrosszabb'' esetet.
1. NV elbukik ATi marad az egyeduralkodó felvásárolja az NVt és az R4xx-ek ára 200.000Ft lesz :O Remélem nem ismétlődik meg a történelem :O
2. NV átviszi az NV-optimalizált motorokat (kicsit aljas lenne) vagy rendbehozza a drivert (ez lenne a helyes) akkor visszaáll a kiegyenlített világrend és becsengenten a következő menetre NV40 vs R4xx -
e-biza
őstag
én prábltam emgérteni a cikket,de <ego on> még a kiválo angol tudásommal <ego off> sem tudtam tökéletesen leforditani, pontosabban leforditani sikerült, de megérteni nem. ;] ha vki aki érti és leforditaná magyarosabbra, azt nagyon megköszönném. Amúgy érdekes a ''story''. Az EIDOS is beintett? nem csak a valve? azért kérdem mert az EIDOS köv játékain csücsül az,hogy nvidia - the way it's meant to be played.
Tiger Woods 2003
S.T.A.L.K.E.R.
Hitman 2
Enter The Matrix
Mámrint ezeket az nvidia a saját oldalain is hirdet, érdekesség,hogy a Half Life 2 is közte van igaz csak az nzone oldalán ami a játékokkal foglalkozik.
[L]http://www.nvidia.com/page/game_catalog.html[/L]
itt már nem szerepel a HL2.
Amúgy tetszik a magyarázat rudi,gratula. -
rudi
nagyúr
Látom átmentél a beyond3d-s cikken :D
Lécci többiek is olvassátok el mert jó lenne pár részletet (10,11,13es oldalak főleg és feccselés latency meg hasonlók) megvitatni.
Nekem egyenlőre az jött le hogy valamit elb@sztak az NVidiánál. Hogy mennyire az legkésőbb a HL2 megjelenéséig kiderül, addig csak azt tudom tanácsolni a vásárolni szándékozóknak hogy vagy ATI vagy várjanak.
Védenem kell egy kicsit a Valve-t is. Vegyük a DEFAULT dx9sdk-t egyenlőre:
Hasonlítom egy főnök(kódoló)-melós(VGA) viszonyhoz.
Valve a főnök és DX9ben kellene a melósnak megmondani mit kell csinálni. Jön egy DX9 nyelvet tökéletesen értő melós (ati) megérti mit kell csinálni. Jön egy másik melós (NV) aki csak ugatja a DX9nyelvet csak a saját cg-jét érti jól, amúgy nem rosszabb (talán még jobb is) mint az ATI melós csak hát a főnök begőzöl hogy mi a f@sz van hogy ez alig érti mit makogok neki?! Erre jön NV melós apja (maga az NVidia cég) és erősködik hogy ha a főnök megtanul cg-ül akkor NV melóssal jobban jár. Erre a főnöknek 2 választása van:
1. NVfater nagysága előtt meghajol és megtanul cg-ül.
2. aszongya NV melós tanuljon meg DX9ül.
Valve esetében (EIDOSnál is) a 2. eset történt meg az aquamarkos csapat az 1.-t választotta.
Most NV faternak van 2 választása
1. büdösgyorsan megtanítja NV melóst DX9ül
2. bízva abban hogy a többi főnök meghajol előtte hagyja az egészet a fenébe.
Ha véletlenül NVfater is a 2. lehetőséget választja akkor valaki sz@rba kerül de nagyon! -
rogers
aktív tag
Na átrágtam magam a http://www.3dcenter.org/artikel/cinefx/index_e.php cikken, valóban meglehetősen érdekes. Nem állítom, hogy elsőre 100%-an megértettem, de úgy tűnik a lényegét fogom. Nem utolsó sorban ez megválaszolta a #154-es hozzászólásomban feszegetett kérdést is.
Ezzel együtt kíváncsi lennék FreeM szerint mik az említett cikk hibái... :)
Ha jól látom akkor az egész végkicsengés még mindig az, hogy szegény nVIDIAnak vhogy sikerült egy olyan chipet konstruálnia amiből picit nehezebb a maximális teljesítményt kicsiholni és valóban: a driveren nagyon sok minden múlik mindenféle csalás nélkül (úgy a DirectX mint a kártya driverben).
Az egész dolog nekem úgy néz ki, hogy sikerült a ''modern kori'' grafikus chipeket közelhozni a normál processzorokhoz, aholis a programhangolás és a kódoptimalizálás döntő jelentőségű.
Mindezek mellett el tudom képzelni csóró Valves fejlesztőket, hogy égnek állt a hajuk a kódoptimalizálásban, mivel az ATI és nVIDIA chip ''gondolkodásmódja'' ég és föld egymáshoz képest. A driver pedig nem varázsló és ''nagyon sz*r'' kódból sosem fog tudni szuper teljesítményt kihozni... -
-Devil-
aktív tag
Sajna mindíg akad 1-2 ilyen lakatlan szigetre való még emberszabásúnak is csak nehezen nevezhető lény.
Egyébként direkt figyeltem a srácot egy ideje, ha valami olyan dologról volt hír, ami nincs neki, vagy pont az ellenkezője van (pl. nvidia<->ati), állandóan csak fikázás volt minden hozzászólása.
Aktív témák
- Konzolokról KULTURÁLT módon
- Először égett le egy újságnál a GeForce RTX 5090
- Azonnali processzoros kérdések órája
- AMD CPU-k jövője - amit tudni vélünk
- Vezeték nélküli fejhallgatók
- Parfüm topik
- Kertészet, mezőgazdaság topik
- One otthoni szolgáltatások (TV, internet, telefon)
- Szünetmentes tápegységek (UPS)
- S.T.A.L.K.E.R. 2: Heart of Chornobyl
- További aktív témák...
- Dell G15 5520 Gamer FHD IPS 120Hz i7-12700H 14mag 16GB 512GB Nvidia RTX 3060 6GB 140W Win11 Garancia
- Telefon felvásárlás!! Samsung Galaxy A50/Samsung Galaxy A51/Samsung Galaxy A52/Samsung Galaxy A53
- BESZÁMÍTÁS! MSI B450M R5 5500 16GB DDR4 512GB SSD GTX 1660 Super 6GB Rampage SHIVA Thermaltake 500W
- Xiaomi Redmi Note 14 5G 256GB Kártyafüggetlen 1 év Garanciával
- Huawei P30 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: FOTC
Város: Budapest