| Szerző |
Üzenet |
Cobra
Piros troll
|
# Elküldve: 2008. Sze. 23. 16:37
sadddam: ez baromsag, mind a 9 SPE-t beuzemeltek!
|
rachy
Tag
|
# Elküldve: 2008. Sze. 23. 18:27
Mi? Mar megint?! Epp most masztunk ki vegre a SAM port kemeny tagadasabol... ;)
|
AliveMOon
Tag
|
# Elküldve: 2008. Sze. 23. 20:26 - Szerkesztve: alivemoon
Az egyik legérdekesebb dolog, szerintem az interjúban van, ha jól értettem ezt:
Other areas include the kernel, OpenGL support, and others.
A kernelbe szinten OpenGL támogatást. Ha jól tudom egyik OS-sem nyújt, kernel szinten 3D-s támogatást, mindig fel kell rakni valami + dolgot.
|
sadddam
Tag
|
# Elküldve: 2008. Sze. 23. 20:55
alive: sztwem ő sem így értete, hanem ujítások, mint kernel, opengl support, blabla.. szal felsorolás nem "opengl support included in kernel). sztem
szal ps3 kacsa mi?
amugy is nvidia gpu van benne, szal ez mar onmagaban is no go (amennyire en tudom, bar ki tudja:)
|
Cobra
Piros troll
|
# Elküldve: 2008. Sze. 23. 23:41
AliveMOon: az sima felsorolas, tehat kernel, OpenGL, stb. Nem azt jelenti, hogy a kernelbe epitik az OpenGL-t vagy ilyesmi.
sadddam: PS3-al az a gond hogy az RSX-hez nem fersz hozza, igy semmi hw gyorsitas nincs grafikara. Aztan ha meg csak egy sima blitter sincs akkor nem sokat er ugy...
|
AliveMOon
Tag
|
# Elküldve: 2008. Sze. 25. 00:39 - Szerkesztve: alivemoon
Nekem érdekes ötletnek tünt az a gondolat mikor félre értettem, hogy minél alacsonyabb szinten szolgáltatna az OS kernele vectort dot, cross, mátrix szorzást, invertálást, quaterniót, alap operátorokat, ha megoldhatólenne különböző buffereket, amihez a drivereknek kéne igazodni. Talán elejét venné a rengeteg keveredésnek ami a többi rendszerben is van :)
|
rachy
Tag
|
# Elküldve: 2008. Sze. 25. 08:55
@alivemoon
Mar bocs, de szerintem ez hulyeseg. A kernelnek nem ez a feladata, legfeljebb az olyan elkeffentett uber-monolitikus kernelekben, mint a linux.
Az egysegesitest egyetlen keretrendszerrel is lehet biztositani, ami a drivereknek megfelelo feladatot ad. Ezt hivjuk peldaul ugy, hogy OpenGL.
|
Cobra
Piros troll
|
# Elküldve: 2008. Sze. 25. 10:28
AliveMOon: Nem a grafikus kernelre gondolsz? Csak mert egy modern grafikus rendszernel ugyebar letezik egy olyan, amit grafikus kernelnek hivnak. Ennek az a feladata, hogy a low-level dolgokkal foglalkozzon (command transport, video memory management, stb.).
|
AliveMOon
Tag
|
# Elküldve: 2008. Sze. 25. 14:22 - Szerkesztve: alivemoon
rachy
Valami olyasmire gondoltam, mint amit Cobra írt, én bufferokról írtam, ő memory managementről. Vannak projectek, ahol már GPU-t használnak CPU feladatokra és nagyságrendekkel gyorsabb számítási teljesítményt érnek el mint az FPU-k, a kernel miért nem integrálhatná GPU-t nem csak CPU FPU MMU SPE, stb hanem GPU mint ha egy másik core lenne, ez már szerintem a kernel feleadata lehetne. De egyébként csak félre értettem és tovább játszotam a gondolattal hogyan is müködhetne :)
|
Cobra
Piros troll
|
# Elküldve: 2008. Sze. 25. 17:30
AliveMoon: Ertem mar mirol van szo... amirol te beszelsz az az, hogy bizonyos matematikai feladatokat, amiket egy GPU mar el tud vegezni (pl. egyszeru matrix muveletek), ezeket egy API-n keresztul lehessen az OS-en keresztul elvegeztetni, es ha van GPU, akkor proci helyett azt hasznlaja a muveletek elvegzesehez. De ennek semmi koze a kernelhez, ez inkabb valamilyen math library lenne, aminek van egy API-ja, es a programok amik azt az API-t hasznaljak, gyorsabban futhatnak, ha van egy GPU, ami elvegzi ezeket a muveleteket. Gyakorlatilag ez ugyanaz, mint amire szukseg lenne, ha azt akarnank, hogy a CELL-en fusson az oprendszer, es a programok kihasznalhassak az SPE unit-okat. Kene egy API, ami kulonbozo algoritmusokat tartalmaz, a program megad egy pointert az adatra amit fel akar dolgozni, es a tobbit a rendszer teljesen transzparensen megcsinalna, ha CELL van akkor az SPE-ket kihasznalva, ha GPU van akkor azt, ha Altivec van akkor azt, ha egyik sincs ami gyorsabban tudna vegrehajtani, akkor fallback-elne a mezei CPU algoritmusra. De ahhoz hogy ez hatekony lenne, valami elegge high-level API-ra lenne szukseg. Mert ha olyasmit csinalsz hogy van egy 4x4-es matrixod amit be akarsz szorozni, akkor valszeg azzal nem nyersz sokat, mert mire attolja a GPU-ra az adatot, hogy az elvegezze, aztan vissza main RAM-ba, valszeg sokkal tovabb tart mintha egy mai atlagos proci elvegezne helyben. De pl. ha egy teljes kepet akarsz elforgatni, vagy egy nagyobb tombon akarsz valami egyseges muveletet vegrehajtani, akkor mar lehetne ertelme.
|
AliveMOon
Tag
|
# Elküldve: 2008. Sze. 25. 20:55 - Szerkesztve: alivemoon
A kernel végzi úgye a szálak és processzek ütemezését, szálak elosztását a magok között, memoria menedzselését, azt el tudnám képzelni, hogy lehessen GPU-s szálat is indítani és azokat is tudná ütemezni, ShaderModel 3.0 felett már lehet rendesen ciklusokat és feltételeket is futattni. Az FPU a procikban még mindig úgy müködik tudtommal, hogy kiadsz egy FPU utasítást majd az FPU küld egy megszakítást, hogy készen vagyok, majdnem úgyanílyen lehet egy GPU-t integrálni. Ha jól tudom a GPU-kban, mind az ATI-ban mind az NVidiak-ban azonos a shader assembly. Természetesen én is nagyobb tömbök feldolgozására szeretném használni.
A kernel közvetít a szálak között ha azok komunikálni akarnak egymással, erre is biztos lehetne kifejleszteni egy modszert, hogy egy GPU szál miként kap adatokat és miként közli a többi szállal.
Sőt ha jóbban belegondolok szálak között most is memorián keresztül adom át a cuccot, elején belépek a kritikus szakaszba, kiolvasom a cuccot, majd a végén kilépek.
Végül is a kernel is egy absztrakciós réteg, ha jól sejtem.
|
AliveMOon
Tag
|
# Elküldve: 2008. Sze. 25. 21:20 - Szerkesztve: alivemoon
Egyébként bocsi ha a definiciókat keverem én grafikus vagyok és egy malőr miatt álltam neki programozásnak és néha baromira nem érdekelnek a definíciók, én ki szoktam dolgokat találni és addig nyüvöm a gépet amíg azt nem csinálja amit én akartam és azt kel mondjam nem szoktam hülyeséget kitalálni, az esetek többségében beválnak az ötleteim és tök jól működnek :)
Van már egy alkalmazottam innen az egyetemről és tényleg azt szokta mondani hogy ezt nem így tanulta, de elismerése ahogy megcsináltam,nem gondolta volna, hogy így is fog müködni :)
Most jobban belegondolva a fordítókat is meg kéne ehhez reformálni.
Valami SHADER vagy HLSL kulcsszót bevezetni.
|
AliveMOon
Tag
|
# Elküldve: 2008. Sze. 25. 22:40 - Szerkesztve: alivemoon
Igen csak durva dolgokra lehetne használni,
egyszerre x*y szálat lehet indítani. minden szálnak 1,2 vagy 3 D-s buffer lehet a bemenete, vektorokkal lehet címezni bennük és ha lefutottak egyszerre x*y visza térési érték lehet az eredmény. Amit másik shader szálak, vagy proci is fel tud használni.
Szál indítás nem az lenne, hogy kérek egy új szálat, kérek x*y új szálat :)
Most nagyon belelkesedtem, azt hiszem rögtön alaklmazom is,
a játékban átírom az ütközés vizsgálatot ilyenre:
Két object két textura, a két objectum háromszögeit betudom szorni egy sima memcpy-vel két float texturába RF32 GF32 BF32.
a kimeneti kép pedig egy igen érdekes cumo lesz,
x = y = n db háromszög
pixel(két szám -> RF32 GF32) = x metszi y háromszöget, amikben ha 0.0f és 1.0f között találok értéket akor a két háromszög metszette egymást.
Képnek csak a felét kell végig mazsolázni CPU-val mert az egyik átló másikfelén inverze az eredmény, sőt ha a draw primitívvel csak azt a háromszöget rajzoltatom akkor a pixelshader is csak a kellő menyiséget számolja ki.
Pl. valami ilyesmiket lehetne futatni, ha egy kernel csípőből tudná kezelni a GPU-t :) és nem egy másik API-ból kéne egy valag fügvényt meghívni, és még így is meg fogja érni.
Forásban egy HLSL kulcsszóval ellátott fügvény lene az egész, amit a fordító binárisan beis linkelheti a kódba vagy valami ilyesmi.
Ha erre a hívásra kerül a sor, a kernel már tudná, hogy azt GPU-n kell futatni. A modern GPU-kban már van multithread is.
Még tovább gondolva, ha egy általános fügvényt, nem CreatThread indítaná, hanem valami új GPU-s viszatérési típusa lenne és új CreatThreadArray vagy valami hasonlóval hívnák életre, akkor a mostani fordítoknak is érthető lehetne hogy ezek GPU-s szálak.
Na és kezem belelóg a bilibe :) Befejeztem az OFF-ot, megyek lekódolni, sajnos Win-re :(
Üdv!
|
rachy
Tag
|
# Elküldve: 2008. Sze. 26. 09:50
@alivemoon
Ah, most mar ertem mire gondoltal.
<OFF>
Az ATI (AMD) es az nVidia is kiadott ilyen kiegeszto kernelt, amivel altalanos feldolgozo muveleteket lehet elvegeztetni a GPU-val, de fuggetlen kiserletezoktol is vannak hasonlo megoldasok. Az a kozos mindegyikben, hogy a GPU-k parhuzamositott nagy mennyisegu adatfeldolgozo kapacitasara fekudtek ra (a'la AltiVec vagy az SPU-k a Cell-ben).
Amigara is meg lehetne oldani, bar nem hiszem, hogy ez most elsodleges kerdes lenne egyelore. Mindenesetre akkor valami altalanosan hasznalhato rendszert kellene felepiteni, ami a grafkartyakon ugyanugy mukodhetne, mint a AltiVec-en vagy a Cell SPU-kon.
</OFF>
Addig is bounty Thomas Frieden PS3-ara... Merjunk nagyot almodni... ;)
|
Cobra
Piros troll
|
# Elküldve: 2008. Sze. 26. 09:51
AliveMoon:
A CPU-kban nincs megszakitas ha egy FPU muveletet akarsz vegrehajtani, igen silany is lenne a teljesitmenye a programoknak... egyszeruen a proci fogjak as instruction pipe-ban levo utasitasokat, es ami az FPU-nak szol, az bemegy egy FPU pipe-ba, ott pedig altalaban tobb stage-en keresztul hajtodnak vegre, vagyis az elso FPU utasitas bemegy az elso stage-be, ami 1 orajelen keresztul dolgozik az utasitason, majd az eredmeny bekerul a masodik stage-be, igy az elso stage felszabadul es oda mehet a kovetkezo utasitas. Egy G3-as prociban 3 stage van az FPU pipeline-ban, G4 eseteben 5 stage, G5-nel tudtommal megtobb. Ebbol adodik a latency is, ugyan kepes a proci minden orajelben egy utasitas eredmenyet befejezni, csak van par orajel "faziskeses" ;-)
Ami a GPU-kat illeti, konkretan hogy gondoltad, hogy az OS kulon szalat tudjon letrehozni a GPU-n? A programok egy adott processzorra vannak megirva, tehat a program egy binaris adatsorozat (1-ek es 0-k :-)), ami csak az adott processzoron tud lefutni. Az OS nem tudna ezt atadni egy GPU-nak, mert az nem tudna mit kezdeni vele, nem "ertene". A GPU-knak egy sajatos "programnyelvuk" van, es ez egyaltalan nem is egyseges a kulonfele GPU-k kozott.
Ami a lenyeg: Ha olyan rendszert akarsz, ami teljesen transzparensen osztja szet a szalakat/muveleteket a CPU es GPU kozott, akkor valamilyen virtualizalt rendszert kell csinalnod, mint pl. a java, mert ugyebar ha valaki lefordit C-ben egy programot PPC-re, akkor egy GPU azzal nem sokat tudna kezdeni... Ha pedig van egy olyan forditod, ami kepes olyan kodot forditani, ami egy GPU-n fut, akkor az pedig csak es kizarolag GPU-n tudna futni. Ja es akkor meg az a kerdes is felmerul, hogy fog az a program rendszerrutinokat meghivni? Csak mert az oprendszer ugye szinten PPC futtathato kod, tehat akkor ott context switch, meg minden bejaccana... Nem veletlen talaltak ki ezt a felallast, hogy van egy proci, ami bizonyos dolgokban eros (mint pl. altalanos szamitasok, bonyolult algoritmusok), es van egy GPU, ami mas dolgokban eros (grafikai muveletek). A ketto nagyon jol kiegesziti egymast, de mint ahogy egy CPU-ra sincs ertelme raeroltetni a grafikai renderelest, ugy a GPU-ra sincs ertelme raeroltetni az altalanos muveletek elvegzeset. Helyette inkabb a CPU es GPU kozotti interface leheto leggyorsabba tetele a fontos szerintem.
|
AliveMOon
Tag
|
# Elküldve: 2008. Sze. 26. 16:12 - Szerkesztve: alivemoon
A pc-kben a FPU a 13 mas IRQ-ra van kötve, programozásnál, lehet, hogy nem kell rá figyelni, vagy gyakorlatban nem szoktak, mert inkább wait utasításokkal ki sakkozák, de egyébként a 68000-es könyvében is így olvastam (piros csíkos db könyv).
Tudtommal a Shader modell x.x binárisan azonos kódot jelent, szabványos.
Általában annyi különbség van amennyit a gyártók trüköznek, hogy néhány utasítást nem implementálnak, de ez PPC és PPC között is fen áll ahogy mondjátok.
Hát ha jól tudom a c foórdítok készítik el a bináris cumokat és vannak adat területek és vannak futatható kódok, a futatható kódterületeknek miért nem lehet több fajtája, azaz ha egy fügvény viszatérési értékét speciálísan definiálom akor abból tudnia kéne, hogy ez a fügvény nem PPC hanem GPU, mint ahogy tudja ha beírom hogy ASM akkor assemblyt fordít, gondolom azért nem így müxik mert edig nem sokan gondoltak erre? Továbra is a PPC-n futna a kernel, de a fordító úgy rakná ösze az exe-t hogy egy bizonyos fügvény hívások már GPU-n futnak le.
|
rachy
Tag
|
# Elküldve: 2008. Sze. 26. 17:26
@alivemoon
<OFF>
A 13-as IRQ-n valo kommunikaciot PC-n kb. a DOS korszakban hasznaltak utoljara, mar nem vacakolnak real modban valo programozassal. (Csarli majd kijavit, ha tevednek... ;)
A shader modellek valoban egyeznek, de ez nem azt jelenti, hogy alacsony szinten is minden szempontbol azonosak a GPU-k, es a shader modellekkel bizonyos tipusu muveleteket lehet elvegezni, nem altalanos celuak. (Tehat szukseges, hogy alacsonyabb szinten is hozzanyulj a GPU-hoz.)
A C forditok nem kepesek arra, amit leirtal, de nem is kell, mert ezt a modszert a forditoktol fuggetlenul mar reg kitalaltak, viszont az OS-nek kell tamogatnia a megfelelo tipusu funkcio hivasat. Ugy hivjak "fat binary" es mar vagy 10 eve alkalmazzak erre-arra, mostanaban pl. MacOSX-en PPC+intel kodot rakva ugyanabba a futtahatoba. (Amigan is hasznaltak anno WarpUP alatt, osszefogva egy futtathatoba a 68k es a PPC kodot.)
Amit elkepzeltel az mukodik vegul is, csak nem biztos, hogy abban a formaban van ertelme, mert rengeteg adatot kellene ide-oda mozgatni a kozponti memoria es a GPU-k altal kozvetlenul kezelt kartya memoria kozott. Vagyis inkabb csak bizonyos, specialis celu fuggvenyeket lenne ertelme megirni/leforditani GPU-ra.
Mielott ebbe a temaban elmelyednenk, ajanlom, hogy vess egy pillantast az nVidia CUDA nevu rendszerere, vagy a Stanfordon fejlesztett BrookGPU-ra, amiket mar emlegettem. (Tobb ilyen projekt is van, de most hadd ne soroljam fel.)
</OFF>
|
AliveMOon
Tag
|
# Elküldve: 2008. Sze. 26. 17:47 - Szerkesztve: alivemoon
IRQ vagy nem IRQ, a lényeg az volt a mondandomnak, hogy várni kell az FPU ra mig befejezi a müveletet.
Hát én naponta programozok shadereket és 3.0-tól van benne minden amit egyébként is használok c-ben és gyors és párhuzamosan hajtja végre mint a barom olyan sebességgel. Pár memcpy-be nem hal bele a CPU vagy a kernel, amikor utánna több terra/s-el kiszámolja a GPU az a lényeg olyan müveletekre érdemes használni, amit egyébként is párhuzamosan szeretnél feldolgozni, és ilyen feladatból egyre tőbb van. Szerintem megérné.
A projectekben pedig nyafognak, hogy ilyen nehéz meg olyan nehéz, tipikus "Prof" duma, de mi olyan fasza gyerekek vagyunk ezt is megoldottuk, pedig csak arról van szó kikell találni új modszereket és nem elég csak a Quake3 motort újra modolni.
Van egy csomó adatom, van egy GPU ami párhuzamosan tud rajta dolgozni, igaz egy pass ban nem fognak tudni egymásról, de a végén lesz egy csomó részeredményem, mert közben nem tudtak dumálni, sebaj majd a következő lépésben végre hajtom megint GPU val és kész az eredmény, szó sincsen arról, hogy a szálak nem tudnának egymással komunikálni, két pass között nem is kell GPU ram és SYSRAM között másolni, csak ha tényleg a cpuval akarok valamit.
|
Cobra
Piros troll
|
# Elküldve: 2008. Sze. 29. 12:13
http://royal.pingdom.com/2008/09/26/10-amazingly-alternative-operating-systems-and-wh at-they-could-mean-for-the-future/
OS4.1 az elejen, es meg DvPlayer is van a screenshoton :P Ocsem szerint az OS4 nez ki legjobban az oldalon, screenshot alapjan. Mondjuk a Haikun en meglepodtem, hogy milyen gagyi Win3.1-feeling a GUI-ja. Meg az is mokas, hogy a 10 felsorolt OS-bol 4 Amiga-derivativ OS :) Viszont errol a Syllable-rol nem is hallottam, es igy ranezesre nem sok koze van az AOS-hez.
|
Lazi
Mr. AmiCon
|
# Elküldve: 2008. Okt. 03. 21:03
Nyugodtan rendelheti mindenki az OS4.1-et. Nem kamu.
Itt van a kezemben :-)
|
Chain-Q
Divatamigás
|
# Elküldve: 2008. Okt. 04. 00:00 - Szerkesztve: charlie
Cobra:
Idezet az AtheOS (Syllable elodje/ose/alapja) weboldalarol:
Q: The GUI look very Amigaish, is it an AmigaOS clone?
A: No. In the beginning it was actualy ment to be one, but this days there is nothing resembling the AmigaOS in AtheOS other than the window-borders. This seems to be rather hard for the Amiga-community to grasp though. They still think AtheOS is an Amiga clone :) Hey the Window borders look like on my Amiga! It must be an Amiga clone Right? I find it rather amusing to see that the Amiga-hord think that the single-most important property of an OS is the window-borders :) BTW: You can replace the border-look by writing a plugin to the appserver so I guess the Amiga look will go away quite soon.
Tehat egy jol ismert helytelen informaciot sikerul tovabbterjeszteni a buzgo ujsagiroknak. Halleluja. Egyebkent, szerintem is az OS4 desktop nez ki legjobban, mert az a leg "eletszagubb". Marmint latszik, hogy az egy aktualisan hasznalt rendszerrol keszult, nem csak egy funkciotlan "beallitas" az OS-hez adott programokrol, minden alapertelmezetten, stb.
Egyebkent a cikk iroi nem eroltettek meg maguk. Bazeg ez a felsorolas/screenshotok hany perc guglizas alatt szedheto ossze? Elvartam volna mondjuk minden OS-rol 4-5 shotot, leirast az OS jellemzoirol, 1-2 fontosabb alkalmazasrol, ilyesmi. Annyira nem eroltettek meg magukat, hogy ez a MOS screenshot ami fentvan pl. a "hivatalos" MOS 2.0 bejelentesi screenshot, a morphos-team.net-rol... :/
(Offtopic: ha mar itt tartunk, eszrevettetek, hogy a morphos.net "megjavult", es a csapat visszakapta? Ezuton is koszi mindenkinek, hogy annyi helyre bepasteltetek anno (akinek inge)... :)
|
Cobra
Piros troll
|
# Elküldve: 2008. Okt. 04. 00:15
ChainQ: Ja, en is pont arra gondoltam, hogy szinte semmit nem irnak egyik rendszerrol se, csak hogy van ilyen, es kesz. De lehet jobb is, mert a vegen meg ismet egy csomo baromsagot szedtek volna ossze, amibol ugye a legujabb ArsTechnica OS4 review-ba is belekerult jopar, barmennyire is jo fej meg joindulato a srac aki irta.
Miert, mi volt a gond a morphos.net-el? :-P
|
rachy
Tag
|
# Elküldve: 2008. Okt. 04. 08:55
Szerintem se sokat er a cikk, raadasul a 4.1-et is 4.0-as screenshottal illusztraltak. Nademindegy, manapsag mindenki ugy gondolja, hogy tud cikkeket irni. Eljen az internet! Web2.0!!!!111
|
Lazi
Mr. AmiCon
|
# Elküldve: 2008. Okt. 05. 23:26
OS4.1 első benyomások:
A hossssszúra nyúlt várakozás cseppet sem törte meg a lelkesedést, amellyel kibontottam a gondosan csomagolt küldeményt.
A diszkrét dobozban egy CD-t és egy negyvenegynéhány oldalas szívmelengető útmutatót találtam. Ez utóbbi egész gondos munka. Jól láthatóan olyan szempontokat is figyelembe vettek elkészítésekor, ami egy az Amiga világba újonnan érkezett jövevénynek lehet hasznos.
A végén található, számos szoftvert bemutató függelék hasznos segítség a rendszer élettel való megtöltéséhez.
Talán életemben először tettem ilyet, de végigolvastam az EULA-t. (erről majd később)
Tudni kell, hogy jómagam bár az elmúlt 18 évben folyamatosan Amigát használtam, 15 éve a 3.1-es OS-t telepítettem fel teljesen tisztán, a telepítő által meghatározott módon.
Az AmigaOne-ra került első OS4-re is azonnal felmásoltam a 3.1-ről áthozott beállításokat, programokat. Az ezt követő update-eket legtöbbször az éppen futó OS-felülírásával frissítettem, ami azt hiszem meglehetősen egyedi lehetőségét jelzi ennek a rendszernek.
A 4.1 azonban teljesen új kickstart elemeket is tartalmaz, ezért a CD-ről boot-olás elengedhetetlen. A régi rendszeren még elkészítettem egy SWAP-nek használható ~1GB méretű partíciót, valamint egy ennél kisebbet az új rendszernek.
A 4.1 telepítő futtatása szót sem érdemel. Eltartott legfeljebb 4 percig.
Az újraindítást követően az első szembeötlő dolog, a boot képernyő volt, amely rövid időt követően átadta helyét a boot-jingle élvezetének. Itt mindjárt az első szemráncolásnak is eljött az ideje, mivel a hang rendszer indításával járó pattanás vezette be Hirasawa mester kellemes dallamát.
Sajnos a U-Boot egyenlőre maradt karakteres képernyőn, ám mivel már készül az új kiadás remélhetően az szakít majd eme ízlést romboló állapottal.
Az első boot után természetesen jött a compositing engine megszemlélése. Az átlátszó ablakokkal való játék hamar eljutott az eredményre, miszerint ez a dolog wb ablakokra felejthető, ám a benne rejlő lehetőségek értékelhetőek. A hardware keze tetten érhető az effekteken, mivel teljesen hibátlanul működik még video lejátszás közben is (természetesen nem overlay üzemmódban).
Az igazán átütő újdonság, a virtuális memória tesztelését néhány kísérlet előzte meg.
Első lépésként elkészült egy boot-menü a bejáratott 4.0-ás és az új teljesen szűz 4.1 rendszerhez. Megvalósítása rém egyszerű, midössze egy kicsit módosított kicklayout fájlra volt szükség.
Második lépést már a türelmetlenség szülte. Hogyan fog minden korábbi beállításom az új rendszeren működni? Az elmúlt másfél évtized tapasztalatán felbuzdulva egyszerűen rámásoltam a 4.1-es partíció tartalmát a 4.0-ás rendszerre, kihagyva a user-startup-ot és az envarc:-ot.
Nagyon nem lepődtem meg, hogy ezután újraindítva a gépet a régi beállításaim fogadtak, működő 4.1 fícsörökkel.
Ezután már lehetőség nyílt a SWAP életszerű tesztelésére. Gépem 256 MB fizikai memóriával büszkélkedik. Ezt megtöltendő telemásoltam a ramdisk:-et kb 300MB-al. Elindítottam az ImageFX-et és megnyitottam 10 kb 6 mp-es képet. PageStream indul és egy fájlként is 60 megás dokumentumot nyitottam meg. Végül pedig elkezdtem játszani a DukeNukem3D-vel.
Mivel a programokkal, adatokkal közös lemezen lett létrehozva a SWAP partíció, ezért a vm használatakor érezhetően lassultak a program indulások, illetve adat beolvasásások. Azt ezt követő munka során viszont már nem lehetett különbséget tapasztalni. Talán egy másik lemezen létrehozott SWAP partícióval még gördülékenyebb lehet a virtuális memória kezelése, ám ez már további kísérletezést igényel.
Egyenlőre ennyit tudok megosztani a nagyérdeművel, amit majd kiegészítek időm és igényetek keretein belül.
Lázi
|
Chain-Q
Divatamigás
|
# Elküldve: 2008. Okt. 06. 06:42 - Szerkesztve: charlie
AliveMOon:
IRQ vagy nem IRQ, a lényeg az volt a mondandomnak, hogy várni kell az FPU ra mig befejezi a müveletet.
Offtopic, es csak most olvastam vissza, de ez egy marhasag. Meg kb. minden, ami az x86 FPU-rol elhangzott. A modern procik (P1-tol folfele biztosan, de szerintem mar a 486 is), siman parhuzamositanak CPU es FPU utasitasokat (040/060 detto). Sot a mai procik akar 2-4 FPU utasitason is dolgoznak egyszerre, a CPU utasitasokkal parhuzamosan.
Az IRQ nem arra valo, hogy varjunk, amig az FPU befejezi a muveletet, hanem az FPU hibakezelesben van szerepe, mivel a korai x86-okon (8086) nem volt kivetelkezeles, ezert az FPU hibakat az interrupt kontrolleren at route-oltak a szoftverek fele. A mai procikon (286/287-tol felfele) mar van Math Fault exception... Nagyon nagy vonalakban ennyi. Aki kivancsi a piszkos reszletekre pl. itt megtalalja.
|
Chain-Q
Divatamigás
|
# Elküldve: 2008. Okt. 06. 06:54
Rachy:
Ugy hivjak "fat binary" es mar vagy 10 eve alkalmazzak erre-arra, mostanaban pl. MacOSX-en PPC+intel kodot rakva ugyanabba a futtahatoba. (Amigan is hasznaltak anno WarpUP alatt, osszefogva egy futtathatoba a 68k es a PPC kodot.)
Leszamitva, hogy az OSX overhyped "fat binary"-ja, gyakorlatilag annyi, hogy egy konyvtarstrukturaban egymas melle van teve az x86 es a PPC binaris, oszt csa'. (Mivel egy atlag OSX alkalmazas egy szabvany konyvtarstruktura.) Mig WarpUP-on a 68k-s executableben voltak kiterjesztett hunk-ok PPC kod szamara, tehat ott tenylegesen egy file-ban volt minden.
|
Cobra
Piros troll
|
# Elküldve: 2008. Okt. 06. 14:51
@Lazi: kosz a beszamolot, ezekszerint vegre megerkezett a cucc :) A multkori E-Mail-emet megkaptad?
|
Cobra
Piros troll
|
# Elküldve: 2008. Okt. 06. 14:53
Chain-Q: Es ugye PPC-n meg mindigis volt exception, mint ahogy 68k-n is :) Igen, WarpUp-on lehetett rendes kevert 68k es PPC kod, vagyis egy kodresz lehetett 68k, masik kodresz PPC. Hogy ez mennyire jo az mar kerdeses :)
|
rachy
Tag
|
# Elküldve: 2008. Okt. 08. 08:59
@lazi
Szoval akkor elviselheto az uj rendszer, ugye? (Duzzogva... ;)
@chainq
Ja, tudom, hogy nem Jobsek nem eroltettek meg magukat, de vegul is az o megkozelitesuk se annyira rossz, legalabb nem kell hozza mindenfele extra tool. Felhasznalo elol ugyis elrejt mindent az OSX, regi Mac-es szokas szerint.
Ha mar fat binary-nel tartunk: egy bizonyos AmigaDE is alkalmazza a megoldast... ;)
|
Chain-Q
Divatamigás
|
# Elküldve: 2008. Okt. 09. 11:41
@rachy:
AmigaDE
Fuuuuj... :) Muszaj ezt? Eppen ettem! :D
Egyebkent szerintem sem rossz megkozelites az OSX-fele, az egyetlen problemam vele, hogy ezekrol a dolgokrol egyedul a GUI tud, az alatta levo kernel, meg a shell lof*szt se. Ez az, amit mar targyaltunk, hogy iszonyu (es egyre novekszik) a szakadek a GUI-k es az alattuk futo OS-ek kozott, fuggetlenul attol, hogy Linux, Vindoz, OSX, vagy micsoda.
Szerintem kibaszott jo otlet, hogy egy szabvany konyvtarstruktura egy alkalmazas, es Amigan is lehetne valami hasonlo, foleg, hogy a nagyon alapjai mar megvannak ennek (PROGDIR:, pl.). De az rohadt nagy acsolat, ahogy es foleg ahol (az OS-ben) meg van csinalva OSX-en, IMHO.
|
