(This turned out to be a long response for some reason, so if you have to piss... :-)
On Thu, 21 Mar 2002, Rodolphe Ortalo wrote: > > KGI directories other than libkgi should be moved to an attic, IMO, > > Since they cannot drive the current KGI. libkgi is the playground. > > >From what I've read in ggi-core/libggi/display/libkgi/ and > ggi-core/libggi/include/ggi/display/libkgi.h ; for the moment, libkgi > contains/uses libgalloc (the "rotor" things?). So (correct me if I'm wrong > please), libkgi (the in-GGI code) is prepared to use an advanced hw engine > via display lists (aka batchops the galloc way). However, libkgi does not > really incorporate any code to actually *use* the current KGI? Right, because LibKGI doesn't really exist yet. What exists in KGI CVS for LibKGI is just basically a setmode command. > KGI is more or less frozen for the moment (not much activity on the > mailing list for 2-3 months). I'm as guilty as someone wrt this but I'd > like to see some improvements. Golbez says he'll be kicking in when his semester ends and wants to work on LibKGI, but that won't be for months yet. > Similarly, elementary drawing commands (ie: the "drawline" ioctl() and > co.) are not ready in KGI: Steffen wiped out the last kgi_command_t system > before going back on the design board, and nobody really knows what he > really invented then for KGI. [1] 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. > 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: 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. 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. 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 don't think KGI gains much by being rushed into a working state with LibGGI either, before its basic infrastructure is even ready to fulfill all of it's mission objectives. Having a working LibGGI target will only serve to slow development of KGI at this point because it is more code to maintain and there is the temptation to not change things that need to be changed in KGI in order to keep it working. IMO, developing LibKGI and refining the already very nice design to deal with the project's mission is where KGI should be concentrating. This may involve more thinking/discussion/prototyping than actual production-quality coding right now. > 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. 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. > 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. > (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. -- Brian
