61
-
Abu85 #61 Működésben sok. -
rumkola #60 Mekkora a különbség a DX9 és a DX10 között?
-
dez #59 Tudom. (Ez már egyébként az első AmigaOS-ben is így volt, 1986-ban. [Más okosságokról itt nem beszélve.] Persze lehet, hogy nagygépes OS-ekben már korábban is, azt nem tudom.)
Viszont egy mai OS-ben, főleg ami az ilyen gazdaságtalanul megírtakat llleti, mint a Windowsok, szerintem jópár taszk nem csak várakozik. Főleg ha ki is kell szolgálni valamilyen aktívan futó programot. A Windows Feladatkezelőjének CPU terhelésmérője abból a szempontból sem korrekt, hogy a "belsős" taszkokat nem is számolja bele a %-ba. Pl. az RMClock (C'n'Q driver helyettesítő, 5x jobb) akkor is több %-ot mutat, maikor a másik 0-át. És amikor a másik 10-et, az 20-at... Ha pl. torrent kliens fut jópár kapcsolattal, akkor még nagyobb a különbség. -
turul16 #58 Varakozo process nem kap ido szeltet, amig be nem kovetkezik amire var. -
turul16 #57 Legtobbjuk nem sok vizet zavar 2% alatti az o ossz. proci igenyuk, es foleg varkoznak, relative keves memoria muveletet vegeznek.
Jo esellyel menetrendszerinti utemzesekkor ugyan az process kapja vissza a CPU-t.
L1(I,D),L2,L3 cache nem urul ki, csak diagnosztikakor szokas nem hasznalni, vagy kiuriteni (kvazi soha), nincs sok koze a lapozashoz.
TLB az amit ervenytelenedik task valtaskor. -
dez #56 Az előzőt úgy írtam, hogy még nem olvastam az #54-esed. Akkor szerinted nincs cache-flush? Oké, viszont 40-50 taszk azért elég sok, ami átlagban fut a mai OS-eken. -
dez #55 Jó, de nem mentik és töltik vissza állandóan az egész L2-t, mint pl. a regisztereket. Még ha nem is lenne cache-ürítés taszkváltáskor, ami asszem van, de nem biztos, nos akkor az a többtíz taszk, ami váltja egymást, éppen elég lenne ahhoz, hogy egy adott taszt előzőleg használt adatai/utasításai már ne nagyon legyenek ott, ezért mindegy szinte, hogy azonos v. másik magon fut tovább a következő esetben. -
turul16 #54 Igen 1 magon is valtogat.
De a kis apro fojamatok nem utik ki a teljes cachet, amint visszakapja a memoriat intenziven hasznalo folyamat a proceszort meg boven talalhat szamara fontos ervenyes adatot az L2 cachben es nem a szomszed proceszorban/mag cacheben lesz az amivel legutobb dolgozott. -
turul16 #53 De kibirna es mas OS nem igy csinalja, es DIREKT nem igy. -
turul16 #52 Masodpercenknt 1000 taszkvaltas 4Mb cache 2x4000 MB/sec (per mag) vs. memory bandwidth.
Hat ez nem elhanyagolhato, bar ugysem kell ujra tolteni az egesz cachet mindig.
-
dez #51 Átlagol... De valahogy tényleg jeleznie kellene, hogy valójában nem 50-50%.
De biztos vagy ebben a melegedési dologban? Nekem úgy rémlik, pl. az AMD korábbi prezentációiban a K10-féle újabb C'n'Q-nak része lett volna az is, hogy adott esetben teljesen lekapcsol 1 v. több magot, ha azokra nincs szükség (kevesebb mag sincs éppen teljesen kihajtva). De aztán ez valahogy elmaradt, azzal együtt, hogy ugyancsak a C'n'Q driver egyátalán csak az órajeleket függetlenül állítgatná a magoknál. Amit amúgy tud is a proci, de kézzel kell állítgatni. Szóval úgy tűnik, nem valamely probléma miatt nem valósították meg ezeket driver szinten (a mérnökök biztos tudták volna előre, ha nem is lehet az általad leírt dolog miatt), hanem egyszerűen "megfeledkeztek" róla. Meg ugye a hárommagosnál is ott van a 4. mag, csak ki van kapcsolva. -
#50
xp vista. Van ott sávszél az l1 l2 nem téma. És tuti hogy minden más oprendszer hasonlóan csinálnia, mert azt nem bírná ki egy több magos proci hogy az egyik mag megfől a másik meg jéghideg.
Csupán a kiírás a faszság, mert szépen kiírja hogy 50-50% amikor 100%-0% és 0% 100% kvagyorsan váltakozva. És ezzel besegítenek a játékfejlesztők kamufolyamába, amit meg is értek, hiszen az ms CSAK és kizárólag a játékoknak köszönheti a helyzetét.
Mellesleg ja amúgy is váltogatja a taskokat, 1magon is minden oprendszer, másképpen hogy futna annyi folyamat?
Négymagosnál meg gondolom szépem 25-25-25-25%-ot ír ki. -
dez #49 Te figyelj, ha nem tudnád, amúgy is állandóan váltogatja a taszkokat. x ms-ig fut az egyik, aztán a következő van soron, és így tovább. Az x ms-nek apró töredéke a cache-ek újratöltése, tehát a multitaskingból eredő időveszteség töredék százalék. Ezért az is mindegy, hogy következő alkalommal melyik magon fut tovább az adott taszk. -
turul16 #48 "Tehát félrevezetés, mert az 50%-50%-ból azt lehet hinni hogy az bizony 2 magot használ, pedig nem."
Melyik szar vindowz verzio csinal ilyet? (L1-)L2 Cache szempontjabol ez kurva rossz. -
#47
Emellett az ms-nek nem érdemes hinni ilyen dolgokban. Ott van pl a játékgyártók fúmostkihasználjuk a 2 meg sokmagot témája is. Szinte minden játékba odaírják a readme-be is hogy hát ez használ 2 magot ami biztos így is van, mert a 0.00001% cpu időt igénylő input eventhandlereket külön szálba rakhatják, csak ugye ennek nem lesz látványos előnye... úgyhogy marad az áll egy játék kb 20 threadből, és abből 1 thread használja az egész program által használt cpu erőforrás 99%-át, másik 19 a maradék 1%-ot megosztva.
És ilyenkor a kíndóz ugye kiírja hogy core 1 használat 50% core 2 50%, ami igaz is, mert vagy a prociba be van égetve ha a két mag között túl nagy lenne a terhelésbeli különbség akkor váltogasson a 2 között, hogy ne forrósodjon fel az egyik míg a másik áll, mert az nemjó. De ettől nem párhuzamosan végzi a feladatot. A valóság tényleg az 50%-50% de teljesítmény szempontjából 100%-0%.
Tehát félrevezetés, mert az 50%-50%-ból azt lehet hinni hogy az bizony 2 magot használ, pedig nem.
A dx10 gyorsulását is eddig csak a dx10.1 új aa-jával tapasztaltam, semmi mással. -
turul16 #46 Je a Geometry Shader az OpenGL 2.0 -val is mehet:
geometry_shader4
Egy extensont betolteni 0 -adik szintu feladat. Aki -nek ez problemat jelent az kerulje a programozast. (par sor kod, amin gondolkozni sem kell) -
#45
dx szar volt, és lassú. Most átírták hogy jobb legyen. Az opengl meg eddig se volt lassú... (tapasztalat több nvidia, ati kártyán és még régről 3dfx kártyán is, sokféle játékkal)
mellesleg ogl3-ban is változtatnak
"OpenGL 3.0 fundamentally changes the API in virtually every way. Any fixed functionality that OpenGL 2.1 also provided a shader interface for has been removed in favor of a shader-only approach. The API has been streamlined, designed to both simplify application development and ease the burden on implementations" -
sirpalee #44 A nagyon nagy mértékű visszafelé kompatibilitás (amit az opengl csinál), hátráltatja a fejlődést. Lásd amit a dx10 csinált, átírták, sokkal jobb lett és nagyok a lehetőségek. Az másik dolog hogy nem használják ki.
Az ogl 3.0 csak arra jó hogy felhozza a 10 szintjére, de nem csinálnak olyan szintű átírást mint a dx9 és dx10 közötti, így nem lesz akkora minőségi ugrás... -
HM #43 "Én nem értek hozzá butakoznolos révén. :-)"
Tipikus eset: hülye vagy hozzá és még büszke is vagy rá.
-
dez #42 (Meg ott van a Mac OS-X is, az fizetős.) -
dez #41 Arról nem is beszélve, hogy legtöbben a Wint is "ingyen használják"... De ha pl. online akarnak játszani, akkor kénytelenek megvenni az eredeti gémet. Ez a Linuxnál sem lenne másként. -
tomcsa4 #40 Értem, köszi a válaszokat! Ha jól tudom Tech 5 még mindig OpenGL-es lesz. Carmack a kitartó. Ámde megnézzük melyik hogy tud fejlődni!
Dzson: leestem a székről :) (ütött a poénka) -
#39
Szuper ez a DX11!
Ha megjelenik, ezzel is végigjátszom újra a 3Dmarkot!
Már háromszor végigvittem, de DX11-el is végigfogom!
Sajnos már értelmét nem látom ennek (sem), csak hogy eladtak több raklap DX10 és 10.1 karit nektek. :)))))))))))) -
#38
Mert nem kell hülye szabványos ugrásokat használni. Használhatnál dx9-ben szereplő effekteket, kiegészítve gs-el ami meg 10-es, ha van használja, ha nincs nemhasználja. Meg persze nyílt, mindenen megy, nem picipuha stb.
vicces egyébként hogy valaki azt mondta azért szar az opengl mert még nincs 3.0 (augusztusban jön), merthogy mindenki azért vergődik hogy hát a dx9 az elég, nemkell 10. Akkor a 2.1-es opengl miért nem elég? Ugyanazt tudja mint a dx9...
Ez olyan mint a szar a linux mert nincs rá driver. De ha a vistához nincs driver akkor nem a vista szar, hanem a gyártó :D -
#37
én nem használtam még egyiket sem de ha másért nem is azért biztosan jobb mert nyílt! Persze kellenek a zárt dolgok is mert pénz körül forog az egész de a nyílt dolgok pár helyen sokkal jobbak lennének ilyen pl a játék fejlesztés is mert sztem ha ismernél minden egyes kis dolgát sokkal inkább tudják kihasználni. Mivel nyílt sokkal többen tudják fejleszteni és egyre többen használnak szgépet egyre többen lesznek tehát azok is akik nem windowst választják és ők is vásárlók...
Valaki írta hogy ha már az oprendszer ingyen van akkor a játékért sem fizetnének, na ez kicsit érdekes, mert nem csak a windows fizetős az alternatívák között is akad, egyébként is nem ezért használok linuxot desktopra is mert ingyen van.... -
Ferrer #36 Az előző nem Microsoft, a másik meg az.. -
tomcsa4 #35 Miért gondolod, hogy jobb az OpenGL, mint a DX? Kérdezem, más is megválaszolhatja! -
Ferrer #34 Olyan vicces a pixeles zöld X, mint embléma.. Jól mutatja, hogy mennyit ér az egész. :) -
#33
Hasonló kezdeményezés. -
HUmanEmber41st #32 Szerintem akkor is sokat nőne egy játékfejlesztő cég presztizse, ha legalább a "kifutott", régebbi játékait engedélyezné átírni Open GLbe.( vagyis kiadná kisebb cégeknek, akik pályázat útján jelentkeznének rá, aztán ugyanúgy pénzért árusítanák.)Gyanítom, h egy "kis" optimalizálás után jobban futna azonos körülmények között, mint annó a DX-es elődje.
Azért sokat jelentene, h Ubi alá nem kellene még Cedegát, Wine-t telepíteni, hanem egyből menne, mint XP alatt. -
Flanigan #31 Szerintem ilyen erovel az XP-re is csinálhatnának DX 11-est . -
Abu85 #30 Szerintem Particle GS Shaderekkel fogunk találkozni a közeljövő játékaiban. Valszeg nő a játékok ALU:Tex aránya, és némileg a vertex shader terhelés is nagyobb lesz. A Deferred Rendering technikák is terjedni fognak, ezzel pedig be kell hozni a DX10.1-es Multisample Access-t az AA támogatásához. -
dez #29 DX10 = Vista+DX10 -
dez #28 "1 magos processzort is lehettett volna még valamilyen technikával gyorsabbá tenni, de minek ha sokkal jobb a többmagos rendszer."
Nem, éppen hogy a gyorsabb proci a jobb, mert teljes átírás nélkül kapásból gyorsabban futnak a dolgok (és a gyorsulás többnyire nem is lineárisan nő a magok számával), és ennek éppen hogy technikai akadánya volt. (Adott csíkszélesség mellett elérték az órajel plafonját, és 1-1 csíkszélesség-váltáskor sem nő olyan drasztikusan.) -
dez #27 1. Na ja, a legtöbb ember gépén Windows van, csak éppen nem DX10. Ezért egyelőre kevés játék is támogatja. Ebből a szempontból (is) jobb lenne az OpenGL, mert akkor érdemes lenne a Geometry Shadereket kihasználó játékokat fejleszteni, és nem csak Vistás gépeken futna.
2. A PS3 3D API-ja az OpenGL-ES.
3. A GPU-nak sokkal kevésbé fekszik a jétéklogika, mint a CPU-nak (ellentétben pl. a 3D grafikával, fizikával).
4. A PS3-ban a Cell nagyon is át tudná venni a Geometry Shaderek végrehajtását. Ezen a területen inkább a Box van gondban. -
tomcsa4 #26 Ja és pont az EA az,aki ad még ki Linuxra játékot és fog is. Szóval a divat EA fikázást be lehet fejezni. Illetve MacOSra is ad ki. -
tomcsa4 #25 Öö nem igazán. DX9-ben lévő korlátot is kitolja a DX 10, hogy milyen részletes legyen a megjelenített kép. -
#24
Nem ilyen egyszerű azért ez a dolog. -
#23
Lehet, hogy csak az én fejemben van így, de én úgy tudom, hogy a DX10-nek a legfőbb előnye, hogy egyszerűbben lehessen megcsinálni ugyanazt, mint DX9 alatt.
(Az új shader azért lett, mert DX9 alatt is csináltak hasonlót, de abban a struktúrába nem fért teljesen bele, igy ott "hackelték" ezt.)
Ha valaki jobban tudja, javitson ki, ugasson le, tiporjon a földbe..
-
jzombi #22 "Az opengl-t meg csak hanyagolják, egy nagy rakás ... az egész, nincs egységesítve, extensionok egymás hegyén hátán, és már eléggé le van maradva, és az OGL 3.0 merre is van?"
Azért egész jó kis API, eléggé átgondolt ahhoz, hogy 10+ évig kompatibilis legyen az összes verzió is az 1.0-val.