On Fri, 22 Mar 2002, Rodolphe Ortalo wrote:
> Thus, I think that, inside LibGGI, several components will make use of
> several parts of KGI. I'm simply arguing now in favour of the
> (re)inclusion of the first (simplest) of these components.
Well, basically my inclination towards that is if you (or
anyone) wants to give the display/kgi directory a repreive
so it sticks around for a while before we stow it, and update
it to work with current KGI, go for it. You won't find me
complaining unless someone suddenly checks in 50Megs of material :-)
Christoph can set you up with CVS access if you're not already
indicated as a GGI developer on SF.
> I am not sure if my terminology is right anymore, but it seems clear to me
> that (the inside-GGI) libkgi should also provide its own sublibs (possibly
> as "extensions"): with dedicated implementations of some functions for
> specific KGI drivers (hw features) and/or operating constraints (like
> security constraints: the administrator may dictate the deactivation of
> some features). [1]
Right, that's still how it is done.
> because the basic API for accessing KGI is not supposed to change (the
> Init,CheckMode, SetMode and Get{Mode,Image}Resource access points via
> ioctl()).
Hmm, well... I am not so sure they will make the distance unchanged.
But they are simple enough to code for for now.
> Concerning 1) I guess this is because you think the mmap()-trick
> and ring buffers idea is not good. IIRC you would rather see a sort of
> "dmalloc()" resource that would give userspace an area of memory with an
> "Exec" capability. Plus, you would like the memory to be returned intact
> to the application after execution.
> I see three problems with this. One is probably due to my lack of
> understanding of kgi resources so I'll skip. The second is: this resource
> is in fact a "resource factory" that you probably expect to allocate
> several times (to get several areas). I don't see how to handle this sort
> of behavior easily (and we need to put some limits on this).
Hmmm... well, I was thinking more like the resource had a max length
and you could grow or shrink it within the limits -- simpler than multiple
allocations that way.
> The last
> problem is a detail (but it will illustrate the interest of real-life
> attempts): what if the driver *modifies* the DMA stream before execution
> (e.g. to take care of small MGA2164 vs MGAG{2,4}00 differences or to
> remove dangerous commands due to security issues). Is this really
> forbidden?
I assume you mean the KGI kernel module by driver. If the DMA stream
contains security violations, then it is userspace's fault for putting
them there, so it loses it's right to expect the DMA buffer will retain
data.
I suspect the chipset version compatibility may have many answers
depending on the details. In most cases, the answer would be that
userspace is responsible for putting the right material in the DMA
buffer in the first place, but there could be cases where that just
doesn't work, and if there's no elegant work-around, then worst case
we have to eat the overhead of a buffer memcpy in the driver.
> Concerning 4, it could be simple to provide I think - an initial set of
> the desired information would be useful to see how it should be
> provided. (I can guess memory size, but then?)
There was a thread about this a while ago on KGI-develop.
> To summarize, it seems to me that 3) and 4) are even more important than
> 1) (*currently*)
Agreed. You cannot even really have 1) without 4).
> > 2) Unless and until KGI offers a way to do DMA from mlocked RAM it will
> > have no capability advantages over the existing raw framebuffer systems.
>
> There is one existing technique in KGI right now. IMO, it would be an
> interesting case to use that one from a userspace library while
> simultaneously preparing the userspace library to accomodate a different
> one. (BTW, different hardware engine will probably *also* provide
> different ways to manage a DMA stream; so this flexibility from the
> userspace lib is probably mandatory.) It would oblige us to think
> carefully to the library API for accessing one DMA abstraction (or
> another).
Well, if you can get textures directly from RAM into the card, then
that would allow the display-kgi to benchmark WAY above all other targets
on all the Put* functions.
> that once the graphics engine is 100% busy (with drawing) and the CPU is
> <10% busy feeding the pipeline, the exact way that pipeline is filled
> won't matter much to application developpers. No? (*I* do *not* say that
> it does not matter!)
Well, let's see if that 10% number happens in reality on anything
short of an Athlon. If it does, then great :-)
> > drivers. In short, people wanting to code simple register-level chipset
> > drivers and not deal with the API/infrastructure design issues both
> > projects are currently faced with should just go write a DirectFB driver
> > and kill two birds with one stone.
>
> Do you really think so? I've not been very fond of DirectFB: I had to look
> at it a lot while debugging/testing the MGA KGI driver. It imposes the
> application to operate the DirectFB-way. These drivers are monolithic and
> do not adapt to application (or programmers) with different needs. (Well,
> at least, they do not adapt more than imposing to the programmer that
> wants something not in it to code it into DirectFB; not necessarilly the
> way he wanted to do it.)
I'm no big fan of LibDirectFB as a whole though there is merit to some of
the concepts invented therein. The drivers are not as contorted though
and are a much much cleaner source than XFree to use as working sample code.
--
Brian
