GGI (Re: Multihead a Matrox?)

[Marian Jančár]

Marian Schubert wrote:
> 
> Martin `MJ' Mares wrote:
> >    Volat na kazde graficke primitivum kernelovou funkci je hloupost -- kdyz
> > pozadam kartu o danou operaci primo, stoji mne to nekolik malo taktu, zatimco
> > volani kernelu samotne uz pres sto. Takze zpomaleni odhadem desetinasobne.
> 
> no nevolaju sa vsetky len tie ktore su potencialne nebezpecne. napriklad
> taky namapovany framebuffer je bezpecny cize mas nan priamy pristup. tak
> isto
> aj pristup na niektore registre moze byt priamy.
> 
> > > pristupe na hw je to prijatelne spomalenie. kontrola sa vykonava len pri
> > > akciach ktore su nebezpecne (DMA transfer napr.)
> >
> >    Jenze uz samo zjisteni, zda se jedna o potencialne nebezpecnou operaci,
> > neni zadarmo.
> 
> ok ja by som to uzavrel asi tak ze ked si chcem byt isty bezpecnostou
> nejakej
> binarky(urobenej pod GGI) tak nastavim target na FB co zabezpeci
> kontrolu
> nebezpecnych cinnosti programu a ked budem chciet rychlost tak pouzijem
> ako
> target napriklad DRI. Cize GGI s tym nema problem proste si zvolis ktoru
> variantu preferujes.
> 

GGI neni spatna myslenka, ale pokulhava provedeni. DRI neni az tak
direct z user-space, jako napr. X-server, vzdyt je to ovladac v jadru.
Za cil si stejne klade spis zabezpeceni atomicnosti akcelerovanych
operaci - aby jedna aplikace pracujici s kartou nebyla odstavena druhou
uprostred prace, napr. kdyz budete zadavat souradnice trojuhelniku a
scheduler vas po prvni souradnici uspi a pusti proces, ktery zacne, nebo
bude pokracovat v nejake jine operaci, tak z toho bude peknej chaos. 

-- 
Marian Jančár <mjanx123 na milada.troja.mff.cuni.cz>