Taky existoval VBE/AF, coz byl pokus VESY vytvorit jakysi standard na platforme nezavisleho ovladace gr. akceleratoru (funkce z VBE 3.0 + podpora 2D akcelerace). Bohuzel se to nechytlo, protoze, jak pisou na webu FreeBE/AF, se VESA zblaznila a chtela za specifikaci neuveritelny penize.
... tak by mě zajímalo, kde jsou v tom VESA BIOSu ty akcelerace?
Hledal jsem je, ale nenašel. Nebo tam žádné nejsou a to
slůvko "accelerated" je tam jen tak? Ví to někdo?
Může to být pouze marketingové označení, bez konkrétní specifikace k té grafické kartě se o tom můžeme pouze dohadovat. Pro některé výrobce stačí, aby se po startu provedla kopie BIOSu do RAM, aby začali mluvit o akceleraci :-) (a ve své podstatě mají trošku pravdu).
To, že se VBE/AF moc neujalo, bylo způsobeno jak způsobem licencování (to jste zmínil), tak i tím, že se zrovinka v té době začalo hromadně přecházet na Windows, a tam si mohl driver napsat kdokoli (tj. jak výrobci grafických čipů, tak i výrobci grafických karet).
Nejedná se však o žádný oficiální standard, pouze o označení grafických karet, které nabízejí vyšší rozlišení či počet současně zobrazitelných (?) karet (?) než karta VGA.
Ano, mame Linear Frame Buffer, zabalme to do COM objektu a s velkou famfarou to "prodavejme" jako DirectDraw (zaklad DirectX) - velkou novinku pro programatory her na Woknech :-)
Přesně tak :-) Potom k tomu ještě přidali detekci a výběr grafických režimů, double a triple buffering a diskutabilni podporu BitBltu a regionů. K tomu jsou pro hodně grafických karet špatně napsané ovladače, například na některých noteboocích "prý" (podle DirectDraw) není podporovaný režim 320x200x256, ale DOSová úloha v tomto režimu bez problémů pracuje.
Ještě, že se dal COM obejít a používat DirectDraw v čistém C-čku (to znamená, že ta objektovost byla pouze "jako").
No, ono to neni celkem pravda. Ten COM model je v pozadi vzdy. Jenom pokud to clovek pise v C/C++ je to jakoby nahrazene makrama. Ale nejhorsi situace je v cistem C, kde si clovek opravdu uzije (a obcas je aj problem sehnat spravne hlavicky :-{
Jasně, ve skutečnosti se volají funkce (metody) pomocí COM. Jde pouze o to, aby se to správně předhodilo kompilátoru C-čka, ten by samozřejmě na objekty řval. Hlavičky obalujících funkcí jsou přímo v hlavičkových souborech od Microsoftu, například v ddraw.h apod. Pomocí #ifdef __cplusplus to tam mají docela dobře oddělený, že ani GCC (MinGW) neřve žádné warningy. Ale je to už dávno, co jsem pracoval v Directech (musel jsem kvůli HW omezením, ale to je delší historie).
Je pravda, že dnes kromě Allegra se VBE/AF moc nepoužívá, pro Windows jsou nativní drivery a na Linuxech se z grafických možností využívají pouze nejznámnější vlastnosti (teď mluvím spíše o starších grafických kartách). Jednu dobu byla snaha přidat ovladače do Linuxového jádra pro lepší podporu framebufferu, ale problém je v tom, že mnoho grafických karet nemá VESU 3 přímo ve svém BIOSu, ale v ovladači, který se musí spustit. Potom tato podpora trošku ztrácí smysl (samozřejmě je možné spouštět Linux z DOSu, ale to jsou zbytečné komplikace, kvůli pár fíčurkám).
Ano, je to ve své podstatě spustitelný binární soubor (a tím pádem pouze pro x86). To by ještě nebylo tak špatné, ale pro správné natažení této binárky je zapotřebí správně nadetekovat grafickou kartu. A to se bez nějaké podporu ze strany VESA BIOSu dělá špatně (samozřejmě lze použít styl: zapiš něco na port 0xDE, počkej 10ms a pokud je hodnota přečtená z portu 0xF1 rovna 1234, jedná se o Trident, ale to samozřejmě není moc stabilní).
Ja bych hlavne cekal, ze pokud se to natahne v DOSu jako nejaky ovladac tak to LOADLIN pri startu odstreli. Kazdopadne je skoda, ze se primo do VBE neprosadil naky standard alespon na par primitivnich
2D funkci jako usecka nebo vyplneny obdelnik. Ja sem si psal vlastni VESA knihovnu na grafiku a krom nastaveni modu je vsechno softwerovy.
Mozna stoji za zminku, ze lze pristup k LFB vyrazne urychlit nastavenim MTRR registru (vim jak se to dela u pentia, u AMD to snad taky nejak jde) z rezimu uncached na write combining, co sem tak zahlid ve zdrojacich jadra tak linux uz to nastavuje ale DOS samozrejme ne.
Dosový ovladač se samozřejmě odstřelí, ale karta je po jeho načtení již inicializovaná. Já jsem například na staré VLB kartě nemohl použít lineární framebuffer bez toho, abych nejprve nenastartoval DOS s ovladačem (ten také nastavil vhodné frekvence pro monitor, 60 Hz mi opravdu nesedlo :-)
:) Presne toto iste som musel robit, ked som chcel pouzivat Vesa framebuffer na SiS6326. Ta karta bola priserna, ale aspon vyrobca poskytoval Vesa driver (uz neviem, ci 2 alebo 3).
Pravda, veci od SiS si kupovali jenom masochisti :-) Graficka karta se snad da jeste prezit, ale co teprve cely cipset. Jeste, ze se nerozhodli udelat i vlastni procesor :-)))
Mal som ju na doske, vela som si nemohol navyberat. Inak aj chipset bol SiS. :) Nastastie je to uz za mnou. Tu dosku som ja nekupoval, mal som ju len "pracovne". Ale bol to horor. Na druhej strane, s chipsetmi SiS745 az take zle skusenosti nemam. Okrem toho, ze ich niekedy nestaci chladit pasivne, co si evidentne vyrobca dosky neuvedomil...
Este ma napadlo, ze tak karta (6326) o sebe tvrdila, ze je akcelerator. Half life 1 isiel na softverovy rendering rychlejsie. A 90% hier sa vykreslovalo uplne sialene (chybajuce polygony, blikanie). Kazdopadne, zmysel tej karty mi je doteraz neznamy. Na 3d absolutne nevyhovujuce, na 2d nic nove nepriniesla. Hmm. Ale ved takych bolo viac.
No, to není tak jednoduché - když ta karta vyšla, tak byla docela dobrá - pokud ste ji ale dostali o nějaký ten rok později v lowend počítači, tak se nemůžete divit. Já mám zkušenost, že takhle karta nebyla zas tak špatná - rychlost měla asi jako konkurenční ATI Rage Pro, ale měla lepší kvalitu obrazu ve 3D. Krom toho tahle karta umí akcelerovat třeba i přehrávání DVD. Mně přišla docela dobrá - ovšem spousta lidí si o ní udělali představu až z těch lowend počítačů v době, kdy už tyto karty zákonitě nemohli stačit.
Ty chybejici polygony a blikani mohou byt zpusobeny malou kapacitou video pameti, ktera je treba zaplnena texturama. Potom se muze stat, ze neni k dispozici zadni buffer ani volna kapacita pro display listy (ve skutecnosti by to samozrejme melo byt naopak, tj. nejdrive se alokuji buffery a potom az texturovaci pamet, ale nektere ovladace karet dokazou divy - napriklad ovladace pro starsi karty ATI delaly neco podobneho, dokonce na nich nejelo ani oficialni demo).
SiS 6326 si pamatam v suvislosti s tym, ze som ju dostal onboard na jednom stroji do bazaru, kde na nu bolo treba nahodit Windowsy, asi na treti pokus sa podarilo najst spravne drivery, ktore aj sli. Prekvapenim vsak bolo to, ze sa drviva vacsina hier na udajne akcelerovanom grafickom adapteri nerozbehla :) Samozrejme chipset bol SiS a dotycna doska o AGP nepocula.
OK,
timto mam moznost nejak inicializovat graficky cip, ale pokud tam budu mit softwerovy VBE 3.0
poveseny na INT 10h tak to mi ho odstreli ne? Takze po spusteni loadlinu budu mit zas spatky
VBE 1.2 nebo 2.0...
Tak musim trochu poopravit nazor, skutecne to ma smysl, a pro me dost zasadni!
Ted sem instaloval na NB s S3-Virge/MX linucha a furt mi vytuhoval pri startu Xserver.
Fungoval jedine VGA. Nakonec sem zistil, ze kdyz pred spustenim linuxu spustim
windows, dam restart do dosu a pres loadlin pustim linux, tak to zacne fungovat spravne.
Tak me napadlo pouzit UniVBE a funguje to taky. Takze ted spoustim DOS->UniVBE->loadlin->
linux->X a funguje to :)
Vidite, takto jsem to na me stare 486 take delal :-)
No, on asi UniVBE nahodi na graficke karte nektere registry (nebo neco povoli), takze to potom jede, i kdyz je BIOS odstrelenej. Asi by to chtelo zjistit, jak se lisi inicializace karty v UniVBE a v X-serveru.
No pokud by existoval nejaky datasheet k tomu cipu, tak bych moh aspon zistit jak se lisi naky registry pred a po spusteni UniVBE. Ale asi to dal nebudu resit. DOS tam pouzivam tak jako tak, pridal sem si na to akorat dalsi polozku do bootmanageru, takze linux spustim jednou klavesou jako ostatni system a ze se to protahne o 2s me uz nezabije. Jen pro informaci tam mam Xorg 6.8.2, jine verze sem nezkousel.
Citujem:
"Standard VESA byl v minulosti použit zejména v operačním systému DOS, v dnešní době má význam pouze jako nejmenší společný prvek, který by (alespoň teoreticky) měly podporovat všechny moderní grafické karty - z toho také mimo jiné vyplývá, že X-server s podporou VESA by měl být funkční na prakticky všech počítačích typu PC, jeho reálná použitelnost je však vinou pomalé práce s video pamětí diskutabilní."
Toto prestava byt pravdou hlavne u novych grafickych kariet (kontkretne nVidia MX440 a novsie ATI radeony), ktore zmrsia, alebo vobec nedokazu dodat informacie o dostupnych grafickych moznostiach pomocou sluzieb VESA VBE. Konkretne u MX440 nie je mozne ziadnym normalizovanym sposobom ziskat velkost grafickej pamati, co komplikuje vypocet double, alebo tripple bufferov, resp. uplne znemoznuje ich pouzitelnost. Naproti tomu moderne ATI graficke adaptery v kombinacii s este modernejsimi ;-) AGP cipsetmi sa stavaju totalne anti normaticke, cize na takychto konfiguraciach je spustenie X-serveru na VESA, VGA16 a vsetkych generickych driveroch nemozne. Otovrene a dokumentovane normy so zazitou kompatibilitou ustupuju dzadom typu M$ Direct X a proprietarnym programovacim rozhraniam na urovni HW kariet... cize v podstate podobny jav, ako pred nastupom VESy.
Casom sa zrejme stretneme s aplikaciami, ktore budu bezat len na karte isteho vyrobcu, lebo system riadenia tychto "diel" bude absolutne nezlucitelny a nepreklenutelny ziadnou omackou. Asi sa vratim k svojmu staruckemu S3 Triu "3D" :)