[ This mail is even longer than Brian's... You've been warned. ;-) ]
Hi Brian,
overall I really understand your point, and you are right on many aspects,
including the fact that no "rush" is needed, and that some more design
work (or discussion) would be useful to KGI as a project (as useful as
actual low level coding).
However, there is an area where I disagree: I do think that exposing some
simple and limited functionality of KGI to applications in LibGGI would be
useful *now*.
Why? And why inside GGI? (It could be done in a separate library, in fact
it *is* done inside kgi-0.9/lib/libkgi/) Because of flexibility.
I do not believe that a single monolithic graphics API (whether kernel
based or library based) would satisfay *any* application programmer,
especially when it comes to graphic applications. And I'm pretty sure you
agree with me or you would not have worked on LibGGI in the first place.
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.
Initially, LibGGI modularity grew out of this constatation wrt KGI that no
single monolithic userspace library *or* kernel API will ever match the
unique specificities of all graphics hardware neither the
unique specifities of all graphics programmmers.
Back in 1996, it made sense to build into KGI mode settings calls and
some basic "standard" things like 2D operations, but soon it appeared that
some heavy modularity was needed in userspace to be able to load dedicated
implementations targetting specific hardware (*especially* for 2D
operations, the idea to apply this technique also to mode setting in order
to run on X11 appeared in fact afterwards). A side effect of the last
constatation was also the need to provide "default/" (software)
implementation to compensate for the lack of functionality in the hardware
or for incomplete development (or lack of documentation) for the driver.
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]
This is also why (the inside-KGI) libkgi currently takes advantage of its
own copy of (an old version of) libggi.
In my view, mode-setting support is just the root part of this work. Hence
my feeling that it could be done right now without raising many problems,
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()).
It is probably right too that all *sub*libs written now (for example
directed towards Matrox hardware with the use of the current command
FIFOs) will need heavy rework when KGI evolves. (Hence my idea to focus on
a limited number of these - just for research.)
Furthermore, given the way KGI "resources" are accessed, even these
deprecated sublibs may not raise so much problems in the long term. KGI
lets userspace enumerate the various resources available, and if one is
not available (or is no more available because the driver does not support
it anymore), the userspace library knows that the corresponding sublib
should not be loaded. These research libs will simply end up taking some
space on the disk (and get removed in the end) while newer version (using
the new resources) will takeover.
Well, this is how I thought to all this, maybe I'm wrong and underestimate
the problems or overestimate the benefits. Maybe I could try some
implementation work, just to see; and maybe we could continue the
discussion and focuss on more specific technical to clarify the issues.
The "big problems" I see currently in KGI(+GGI) is:
1) the "accel" resource currently available in KGI is not satisfactory
from your point of view - at least you do not want to base serious
userspace work on it.
2) IMO, there are also a few problems with other resources (like setting
the palette, or the pointer shape). But I need to go back to the KGI code
to look at this again.
3) The lack of a "programmable condition" resource that waits for some
event to occur before returning to the application (e.g. to sync on end of
execution, or vertical retrace, etc.).
4) The lack of an "information" resource that returns information
concerning the hardware.
It seems that the "framebuffer" resource is satisfactory for most of us
however (it's the simplest :-).
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). 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?
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?)
To summarize, it seems to me that 3) and 4) are even more important than
1) (*currently*) and that the existence of some userspace applications
would really help us to put priorities on what KGI needs first.
Rodolphe
[1] It seems to me that it is also the case currently for mga chipsets
with the fbdev display target no? (Unless the code in default/fbdev/mga/
is not used?)
On Thu, 21 Mar 2002, Brian S. Julin wrote:
>
[...]
> I wouldn't worry about that. GGI doesn't expect KGI to provide any
> primitives. (It shouldn't ever IMO.) Just access methods for register
> sets, DMA/AGP buffers, and framebuffers virtualized in a secure and
> cross-OS-portable manner. Primitives are bloat for an OS level driver.
Yep. Sorry, I always forget that...
> > However, mode-setting commands to obtain a fb access could be extracted
> > very fast from the KGI CVS tree
>
> [...]
>
> > I know that Steffen Seeger (the primary KGI author) wants to
> > create/maintain an independent libkgi to offer a userspace abstraction of
> > the KGI functionality (and because it may be a key part of his graphic
> > world domination grand plan). But until it is ready, I *really* think that
> > we should copy these 6-7 functions from the KGI source tree into libggi
> > and rush towards framebuffer-based KGI applications. [2]
>
> Personally I don't think we should be rushing. This would basically
> get the GGI Project nowhere -- if we want to just initialize a
> framebuffer, and maybe twiddle registers from userspace, that would
> make KGI no more useful than basic Linux /dev/fb:
While you are right on the overal picture (/dev/fb *is* a downsized
variant of KGI), there are several details that could do a (small but
noticeable) difference: text support, hw pointer support, etc. Plus KGI
can accomodate tricky situations (e.g.: the dual-head text-mode with 2
Matrox boards that's officially unsupported, or VGA fb
"linearization"...).
> 1) If the KGI core ports to NewOS/FreeBSD were already done, then
> there might be a justification for doing so, but then again we are
> back to needing LibKGI to make the OS transparent to the LibGGI target code.
In theory, not for mode-setting and fundamental text/graphics management,
which could be enough for some applications.
> 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).
> 3) The virtualized command FIFOs don't have a truly solid API, and
> since they are at the heart of the code we would be subject to as many,
> if not more tedious target code updates as we already today have to
> contend with when other back-ends change their API.
I guess I should more or less agree for this. But I do not demand you to
maintain such a thing. I'd just be happy to see you help/guide to do the
"Not So Bad Thing(tm)". :-)
Finally, I'd add a:
4) KGI lacks support for, for example, overlay, video codecs, etc.
[...]
> > In fact, this is my question: with only a framebuffer provided by the hw
> > driver, will most of current GGI applications run decently? (BTW, my guess
> > is "yes of course!")
>
> No, actually, they will run slower because other fb-based targets already
> offer hardware acceleration. Even library-based targets offer hw accel.
> And, until the batchops are written and ready to go, KGI's super-fast
> pipelines won't really fill much faster than a direct MMIO register writing
> application using a userspace driver due to the overhead of a functionally
> oriented API where parameters are reprocessed from scratch into pipeline
> values every time a drawbox() is invoked.
I find you pessimistic. I won't go into any benchmarks (because there are
many things to do before even thinking to performance issues), but I'd say
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!)
> Were the KGI driver authors to start implementing GGI targets for their
> pipeline metalanguages, just in order to get GGI/KGI into a working
> state, we would end up with just your average chipset register code
> (with some minor massaging for current KGI ping-pong buffers), lots of
> it, littering the working tree and needing constant maintainance. Such
> a codebase would have no extra benefit as source material for a later,
> greater batchop/LibKGI target over that which is already accruing in
> DirectFB's CVS, and we already have LibGGI trained to use DirectFB
> 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.)
Anyway, in any case hardware-specific code will appear in userspace
libraries. And there will probably be several (competing) variants. That's
why I proposed to do some "research" work with the Matrox as a basis. I
would not mind if you simply get rid of this hw specific part at the end
of the "research" work. It would simply help us validate the
API/infrastructure issues. (Nothing more.)
> > That could give a boost to those wanting to try some KGI driver
> > development *now*; because they could see some applications running.
>
> ?? Like a moral boost? Generally I don't need to see applications
> running during driver development (by the time I see the app running,
> I'm done :-), and I think people's moral would be more boosted if they
> had a clear handle on the internals (read: aren't wandering around
> the codebase confused) and agree strongly with the design and the
> reasons behind the design. That, and having only marginally better, or
> even inferior performance to competing graphics back ends would be
> discouraging.
Hmmm. That's exactly the situation I'm in and, honestly, I *have* been
encouraged by these small running apps. Maybe I'm a single case; but I
really like to see (some) things running at every steps of the
development.
> > (Going through up to mode-setting is 90% of driver development work IMO.
>
> IMO going through mode setting has been a mostly solved problem for OpenSource
> since about 5 years ago. Every project has a solution for it already, to
> varying tunes of flexibility. KGI is more flexible but that is only of
> benefit to the discerning customers. It's the other 10% that matters
> to prospective application developers now, e.g. look at LibDirectFB, which
> is architecturally in almost every way inferior to LibGGI, but which
> was kicking our butts because we just plain didn't have API for things
> people want to do (what situation is changing now.) Before we code it,
> we had to design it, and KGI is in the same spot IMO.
I think the real benefit of KGI flexibility is not for application
developers (this is LibGGI domain :-), but for drivers developpers. I'd
even say for *initial driver* developpers (*not* those playing with
advanced 3D pipelines).
Btw, this is probly why I also think that LibGGI flexibility is needed
for the initial userspace work...
