Přeji krásný den,
často se tu hovoří o kompatibilitě karet pro různé verze sběrnic např. PCI; zatím jsem však nečetl nic o možnosti použití karet na různých platformách, vybavených toutéž sběrnicí. Jmenujme např. platformu Sun Ultra 80, která je vybavena sběrnicí PCI: bude do ní možno zasouvat PCI karty, určené pro běžná PC ? Tipuji, že např. s video kartou by byl problém, neboť její BIOS je v kódu x86 a UltraSparc jej rozhodně nepoběží. Stejně asi dopadne řadič SATA, který bych rád do této krabice doplnil (taky na něm vidím EPROM s nějakým nejspíše BIOSem). Co však třeba deska USB OHCI řadiče ? Žádnou ROM na ní nevidím, pozná ji tedy systém (SparcLinux) a obslouží ? Je nějak zajištěna "blbůvzdornost", aby např. při vložení PC videokarty do Suna nenastal při pokusu o spuštění BIOSu bohapustý crash ?
S pozdravem Pavel Troller
To je asi nejlepší vyzkoušet, fungovat mohou i karty s BIOSem, záleží na ovladači (jestli např. spoléha na to, že BIOS tu kartu nějakým způsobem inicializoval apod.).
S grafickou kartou na PCI bude jeden problém - jak nainicializovat grafický režim. To se (přenositelně) provádí právě přes BIOS. Ovšem pokud se inicializace podaří, je možné prakticky jakoukouli kartu (i do AGP) ovládat jednoduše - v BADR0 je počáteční adresa framebufferu, od této adresy lze "ládovat" jednotlivé pixely, formát RGB, BGR, RGBx atd. se sice liší (i počet bytů na jeden řádek - pitch), ale jde to v pohodě i z DOSu nebo úplně bez operačního systému. Například takto pracuje ColorForth - po inicializaci gfx. režimu si již veškeré řízení grafiky obstará sám, žádný OS pod sebou nemá.
Crash by nastat neměl - ten BIOS prostě nikdo nespustí, karta maximálně nepojede. Sběrnici by neměla ani nijak locknout, adresové rozsahy a přerušení přiděluje řadič, bohudík se nejedná o ISA.
Jediny problem je opravdu s tou prvotni inicializaci - ne vsechny ovladace jsou ochotne fungovat s kartou, ktera nebyla BIOSem inicializovana. Napr. v Linuxu funguji bez inicializace BIOSem bez problemu jen karty Matrox.
JJ, zlaty matroxy. G400 byla posldni gr. ke ktery byla vzerejnena kompletni dokumentace.
Dokonce jsem skousel gr. kartu G200 z PowerPC serveru. Na prvni pohled byla identicka s G200, kterou jsem koupil v Alze. Lisila se akorat tim, ze byla cca 5x drazsi a mela BIOS s instrukcema pro PowerPC
(nebo to byl Forth?) V linuxu fungovala uplne stejne.
Záleží na ovladači. U IDE/SATA/SCSI/USB/síťové karty většina ovladačů funguje i bez BIOSu. Můžou se vyskytnout drobné problémy, např. když BIOS IDE disku detekuje typ kabelu, a pokud se ten BIOS nepustí, tak si ovladač bude myslet, že tam máš 40 žilový kabel a nedovolí větší módy než UDMA33 --- dá se to triviálně opravit. Některé ovladače nekonvertují endianitu, takže fungují jen na little-endian procesorech, ale taky se to dá opravit.
Čím je ta karta rozšířenější, tím je větší pravděpodobnost, že ji někdo někdy do ne-PC počítače strčil a ovladač opravil.
Co se týče videokarty, tam je to fakt horší. Některé karty Xserver umí nahodit bez BIOSu, některé ne. Ten samý problém se vyskytne, pokud víc grafických karet zasuneš do obyčejného PC --- BIOS ti inicializuje jen jednu. Zda budou chodit i ty ostatní, to záleží, jak je ovladač v Xserveru napsán.
U alpha serverů (všech?, některých?) to je řešeno tak, že součástí firmware či biosu serveru je i emulátor instrukční sady x86. Přídavné karty jsou inicializovány postupem obvyklým ve světě x86. A až při startu opravdového operačního systému se spustí i nativní ovladač.
Mam zkusenost s E450, Ultra 5,Ultra 10. Zkousel jsem karty: firewire radic pouzivam pro vypalovacku,
sitove karty EEpro 100,1000, Realtek 8139, SATA radice ted s SIS chipsetem. Vse chodi bez problemu.
Na SATA mam diskove pole 1.5T bezi to asi 1/2 roku zalohuje se na to a v pohode.
Je mi jasne, ze clanek neni zatim o PCI-Express, nicmene mam k teto sbernici otazku: Je nekomu znamy nejaky navrh s FPGA ci CPLD, ktery by plne resil "kartovou" cast, a nebylo to FPGA typu Virtex ? Tedy s nejakym levnym low-endem.
Ta sama otazka na HDMI video... u obou jsou potrebne docela vysoke frekvence, a neni mi znamo zadne levne FPGA ci CPLD, ktere by to zvladalo.
V low endech těžko... Viz třeba http://www.fpgajournal.com/articles_2005/20050823_lsi.htm U CPLD bude scházet PHY, což jsou další extérní šváby, navíc, cena u CPLD s ohledem na logiku roste zavratným tempem, takže už se vyplatí FPGA. Ale pak se narazí na to zpoždění a nutnou rychlost. Proto horko těžko to půjde udělat low endem....
Jen dodám, že to je hlavní důvod (latence/rychlost), proč to ty FPGA mají nadrátovaný v sobě (stejně jako celé násobičky, PPC bloky)... Kdyby FPGA byly tak krásný, jak se výrobci snaží říkat, nepotřebovaly by mít příslušné HW jako bloky :)
Pokud ti nevadi ze to nebude od Xilinx-u tak muzes pouzit Lattice ECP2M, ktere maji SERDES modul (v podstate lvds/tmds/pcie phy). Lze s tim obslouzit uz zminene PCI-Express a taky generovat DVI a HDMI signal (tmds) nebo LVDS signal pro prime napojeni LCD. Ty vystupy lze generovat na lowcost FPGA i bez SERDES-u, prostym poskladanim hradel a jemnou spozdovaci smyckou - existuji na to application notes.
HDMI z opravdu low-end FPGA lze pohodlne generovat za pouziti externiho serializeru, napr. od SiI (silicon image).
Mam dojem, ze je to popsane v sedme kapitole. Jedna se o zpetne kompatibilni rozsireni, oproti 64 bitove PCI tam jsou mozne vyssi rychlosti (PCI-X 2), podpora pro reset a odpojeni vadnych karet, kontrola a oprava chyb pri prenosu.
Prosím autora o nějaké rozvedení kapitoly 4. Nerozumím přesně co tam má ma mysli pod pojmem vyrovnávací paměť. Moje představa je, že texturu přenáším z operační paměti do videoadaptéru, tak sakra jaká vyrovnávací paměť ?
K tomu režimu, který se podobá starým 8bitům: mám tomu rozumět tak, že videopaměť se objeví na fyzických adresách v rozsahu operační paměti ?
Děkuji.
Pokud je na grafickém akcelerátoru méně paměti, než je zapotřebí pro framebuffer+textury (+vertexy atd), dají se přes AGP přenášet textury přímo z operační paměti. V klasickém režimu by se přenos prováděl takto:
To však nemá moc smysl právě při nedostatku paměti na gfx. akcelerátoru, takže se texturovací paměť z tohoto řetězce dá vynechat a akcelerátor textury přímo načítá z operační paměti. Je to pomalejší, to jistě (už jen proto, že datové cesty uvnitř akcelerátoru nemusí být omezeny na 32/64 bitů), ale při nedostatku paměti je to lepší řešení než si pořád přepisovat texturovací paměť nebo omezovat framebuffer. Zda se textura přenáší celá nebo se stripuje je již do jisté míry interní záležitost grafického akcelerátoru resp. jeho ovladačů.
Druhý dotaz - přesně tak, přímé mapování. Ono je to samozřejmě pravda i u PCI karet, zde jsou však přenosy efektivnější vzhledem k vytížení.
"mám tomu rozumět tak, že videopaměť se objeví na fyzických adresách v rozsahu operační paměti ?"
Ne, to znamená, že se (potenciálně nesouvislá) část operační paměti objeví na adresách, které vidí grafická karta. Jaká část to bude, určuje ovladač agpgart.
Čili si pomocí toho můžeš udělat to, že si funkcí malloc() naalokuješ paměť, nahraješ do ní texturu, a pak, aniž bys tu texturu musel někam kopíroval, necháš 3D akcelerátor tu texturu vykreslovat.
Videoram takhle namapovat do operační paměti nejde, protože na té sběrnici nemáš zaručenou dobu přístupu --- čili by ti ten obraz vypadával podle momentálního vytížení počítače. Používat operační paměť jako videoram umí jen on-board karty Intel.