Peter Lund wrote:
I imagine the interface should be modelled very closely on PCI, but not
at the level of individual signals, of course, but rather on the level
of "here's a write of 6 bytes to that address, here's a read, here's a
configuration space write, ..."
-Peter
With proper abstraction in the driver, it should be possible to write a
pretty complete driver that could use any number of transport methods to
talk to the back end display device, be it the software model or a
hardware device. The driver should have a high level section and a
hardware interface section. The high level code does all the setup and
handling of application calls including any software emulation needed.
For things that are passed off to the hardware for acceleration, a call
is then made to the interface code, which like you noted above, provides
a very simple interface. Any number of transport layers could provide
the same functionality. Need to run the driver against the simulator,
compile it against the simulator transport layer which could use
sockets, shared memory, etc. Do you have an FPGA development board with
enough gates to hold the design? Great? It uses USB to interface? Ok,
then compile the driver against the USB transport layer. As the PCI
interface moves forward, work can progress on the actual PCI transport
layer as well as a separate test harness driver that is designed to test
the PCI transport layer explicitly. Yes, this obviously means that
someone has to write the transport layers before you can use them, but
open source development is all about scratching the proverbial itch.
I've seen a number of people at various times note that the register
interface is not well defined and that some of the functional interface
is still up in the air as to how it will work. That shouldn't stop
people from starting on the drivers. Registers are easily abstracted
and readily changeable if the code is properly written. Changing a
register location should be as simple as changing a single #define. As
for the functional interface, pick something and figure out how it
should work. Start with something simple like a non-shaded colored
triangle. How should that be sent to the card. Check the archives from
a while back and see what has been said. You didn't find enough
information? Then propose a method of doing it. The hardware folks and
Timothy will let you know if it's impossible our breaks any other
assumption. If it doesn't, congratulations, your way is now "the way"
until someone comes up with a better way and implements it.
There will be large amounts of work and rework in this process. As
drivers are written decisions there will influence the design and
implementation of the hardware. As hardware is implemented it may very
well be found that a chunk of the driver has to be stubbed out or
re-written because of hardware limitations. It's ok to get it wrong in
the first pass, just make sure that things are modular and it's not hard
to fix later.
Patrick M
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
