On Sun, 1 Jul 2001, Christoph Egger wrote:
> I wanna try to explain my understanding how the KGI-target should
> work/look like.
[...]
> The GGI app opens the KGI-target. The KGI-target opens /dev/graphic
> and /dev/event and asks the KGI-driver through an IOCTL, which
> graphic card (chipset/ramdac/clock-chips) is used. The KGI-target
> then loads a card/chipset-specific sublib like the fbdev-target does.
> Then all the card/chipset-specific initialization will be done using
> the ping-pong mechanism.
Close: I think the plan was for there to be a libkgi, which is started
in the KGI source tree but to me looks incomplete. My understanding
of what libkgi is supposed to do is abstract the mechanism used
to communicate between the KGI and userspace. That is to say, accesses
to the KGI target will either be given as a MMIO mapping (for fb data)
and/or as a generic "pipeline," which could use ping-pong, safe-MMIO, ioctl,
or any other mechanism; this would be done through an API layer so the
actual mechanism would be transparent to the coders of the display-kgi
target/sublibs.
The design of this generic interface is IMO one of the primary things
holding KGI in stasis. It has to be carefully designed to gain
optimal performance in a variety of situations -- different mechanisms
and different variations in OS capabilities will mean that there
will be a large variety of different locking/data concurrancy scenarios.
At the same time, the interface has to reduce itself during compile
time to minimize overhead (unecessary indirection, unneeded function calls).
Here we are in an area that requires heavy optimization effort.
Thoroughly looking at the possible scenarios and finding an API for libkgi
that works optimally will require a good-to-expert knowlege of locking
issues on a variety of OSes. I think though that if LibGGI decides to use
the upcoming batchop proposal, that may simplify the API design, and that
the KGI API design could find ways to improve the rather primitive plan for
batchops. So, after the pre-release is out (just need to clean the
tree and deal with those last few remaining directx issues) we can
post the batchop materials to both lists and see where it takes us... OK?
> KGI-driver makes sure, that the ACCEL-engine is idle and nothing is
> in the execution queue. Then /dev/graphic and /dev/event will be
> closed. GGI apps exists as usual then (KGI-target will be closed,
> etc.).
libkgi will probably handle all the opening/closing of fd's; display-kgi
need only pass libkgi any relevant initialization parameters, then
ask for a list of KGI resources from libkgi, use them, tell libkgi to
free them, and tell linkgi to clean up anything that is left over
when display-kgi is done.
--
Brian
