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.
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.
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.
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.
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.
Á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.
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.
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.
"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.
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.
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)
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"
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...
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.
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
é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....
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.
Szerintem ilyen erovel az XP-re is csinálhatnának DX 11-est .
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.
"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.)
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.
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..
"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.
Magyarul az egész DX10 nagyon jó dolog lenne, de nem tudnák úgy megírni a játékokat, hogy dx9 -ben is, meg konzolokon is mennyen a dolog. A jelenlegi bekapcsolható DX10 effektek a játékokban egyértelmûen nem dx10-esek akkor, és dx9-ben is simán mûködnének. Csak azért csinálták, hogy ha már megvették akkor csak legyen valami kis különbség.
A kártyák gyorsabbak is, nem csak új technológiát váltottunk. Bár a dx10 nyilván csábítóbb, de a jobb kártyák úgyis ugyan annyiba kerülnének ha nem dx10 lenne szerintem.
Nyilván nincs kihasználva teljesen a dx9, de ha egy újabb technológiával sokkal egyszerûbben meg lehet oldani dolgokat, akkor miért ne. 1 magos processzort is lehettett volna még valamilyen technikával gyorsabbá tenni, de minek ha sokkal jobb a többmagos rendszer.
Lesz majd XP-s változat? :D
De az nem DX10 alatt futott, hanem uazok az effektek DX9 alatt. Arról nem tehet az ember hogy a crytek elszúrta az egészet, és nem volt képes normális dx10-es motort írni.
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?
A játék fejlesztés anyagilag nagyon nagy kockázat. Az 5-6 legnagyobb, már többször sikert aratott játékfejlesztõ céget kivéve, ez mindenkire igaz. De sokszor a legnagyobbakra is. Minden kis apró költség sokat számít. Vagyis csak akkor lesz több opengl-es játék, ha nagyon sok felhasználó elkezdi preferálni az egyéb oprendszereket. Továbbá mivel directx-en van a pénz, így a minden féle támogatások, fejlesztések, egyeztetések inkább arra vannak.
Ez így egy ördögi kör. Ez bizony akkor fog csak változni, ha felhasználói szokások nagy mértékben változnak.
Egyébként a dirext10 kellett meg a dirext11 is szükség van. Senki nem mondta, hogy kötelezõ gépet újítani. Plusz így a régebbi technológiáknak gyorsan lemegy majd ára, és ez egy jó dolog.
A legtobb embernek windows van a gepen. Ezert a jatekokat windowsra fejlesztik, ahol a directx a nativ api. Az atlag emberek kozzul jatekra szant gepen eleg kevesen hasznalnak linuxot es aki igen, az is inkabb azert mert ingyenes. Az o kedvukert nem fognak fizetos szoftvereket fejleszteni opengl-ben.
A dx9 jelenleg azert maradt az elterjedt api, mert minden jelenlegi konzol (ps3, xbox360) csak ezt tamogatja, tovabba a legtobb ember nem hajlando penzt aldozni a vista futtatasara es jatekra egy idoben alkalmas gepre.
A dx10 eleg nagy fejlesztes volt, megjelentek a geometry shader-ek, ami azt jelenti, hogy most mar a dx trukkozes nelkul is kepes fizikat es futas kozben szamolt animaciokat gyorsitani. Az elso az elethubb fizikai szimulaciokat a masodik a gordulekenyebb, fix fazisok nelkui animaciokat tenne lehetove. A fejlesztok e helyett meg mindig a cpu-val szamoltatjak mindkettot. A kovetkezo lepes az lenne, ha a teljes jateklogika atkerulne a gpu-ba es lehetove valna az ai gyorsitas, tehat a cpu-t szinte nem is hasznalo jatekok szuletnenek. Arrol nem is beszelve, hogy a mai babu modell helyett a karakterek fizikai felepiteset figyelembe vevo animaciokat lehetne generaltatni a geppel. (tehat nem egy animator hatarozna meg a mozgasokat, hanem a jateklogika csak annyit mondana, hogy eppen melyik izmait fesziti meg a karakter, es a tobbit a modell alapjan kiszamolna a gpu, tehat kornyezettel kolcsonhatasban a lehetseges animaciok szama kozel vegtelenre none, azaz pl. soha nem lepne vagy ugrana ketszer pixelre egyforman egy karakter)
A dx10 lehetove teszi ezeket, csupan addig senkinek nem eri meg ilyen drasztikusan eltero elven jatekokat fejleszteni, amig a konzolok nem tudjak futtatni az igy megirt kodot. Ez sokkal drasztikusabb valtas mint ami dx8 es dx9 kozott tortent, mivel itt a teljes jatekmotort kellene a gpu-ra megirni, tehat a grafikus motor valna a jatekmotorra es ezaltal tobbet nem lenne lecserelheto ujrairas nelkul masik technologiara.
nemkell linux alá sem megírni. Egyszerûen opengl grafika kell. Ennyi kell, és linuxon is simán megoldható a win-es program futtatása is jó sebességgel, na meg nem csak linuxon, hanem pölö meken, meg pisi3mon is.
Ahh, lenyúlás szagot érzek... Még jó, h a Battlefield 2 DX 9-en fut. :D :D Az viszont tényleg szar dolog, h egy játékfejlesztõ cég csakis kizárólag DX játékokat csinál. Jó, kivétel az Unreal mert megcsinálták Linux alá is. Az EA hatalmas népszerûségre tenne szert, ha jõk is követnék az Unreal készítõinek példáját és ugyanazt kiadnák OpenGL motorral is.
Crysis DX10-es effektjeit elõ lehet csalogatni DX9-es kártya alatt is, windowsXP-n.
Ez az egész DX-es fejlesztés csak arra jó hogy a felhasználókat átcsábítsák az újabb windows verziókhoz. Meg ugye a vga kártyák eladási adataira is jótékony hatással bír.
Nekünk, játékosoknak az lenne a legjobb ha a fejlesztõk sutbavágnák a DX-et és elkezdenének végre OpenGL alá fejleszteni, így nem lennénk (vagy legalábbis kisebb mértékben) rákényszerítve a microsoft termékeire. John Carmacktõl (doom-ok és quake-ek enginejének fõkódere) egy kis demonstráció az új id enginerõl, OpenGL alapú
Én szerintem ezt a fejlesztést majd az új win-re tartalékolhatnák. Mondjuk arra leszek kiváncsi, hogy melyik gyártó foglya elõször bele építeni az új vga-kba. Mondjuk én 2010-ig tutti nem fejlesztek gépet vagy 2012-re csak. Addigra kijönnek 8magos amd, intel procik.
Mit gondolsz miért találta ki az m$? Annyit segítek nem azért, hogy neked jó legyen, vagy a játékfejlesztõknek...
Ez jó hír! Újabb lehetõségek nyílhatnak meg a fejlesztések elõtt. Ez meg elcsépelt szöveg, hogy a dx9-et sem tudják kihasználni. Persze biztos igaz is, de nem azért van dx10 meg majd 11, hogy legyen ilyen is. Többet tud, mint az elõdje és ez fontos. Mivel konzol és xbox párti vagyok, szerintem a következõ xbox amikb. 2 évvel jöhet ez után már biztos olyan kártya is lesz benne. Fõleg, ha HVD lemezeket is használna... Persze addig még el kellene terjednie, hogy pénztárca barát áron használni lehessen.
A DX) már ki van használva majd nem 100%-ig (lásd CrySiS), de a DX10 ami alig van kihasználva jelenleg. A DX11 meg két új shadert ad csak hozzá, mellyel élethûbb modelllek elkészítését teszi lehetõvé.
Informatika és tudomány
Persze addig még el kellene terjednie, hogy pénztárca barát áron használni lehessen. 