Drew Northup wrote:
> I think that you are confusing the API layer with the hardware
> layer........... Go find yourself a good graphic model of the OHCI network
> model--this model best explains the interaction between hardware & software
> in a system (network, really) like the IBM PC-AT/ATX & IA-32 architecture.
> OGL may be how you communicate with the driver...., but the driver still has
> to do the dirty work on the hardware/memory map level.
Unless the driver itself converts GDI (assuming Windows) primitives to openGL
primitives and just passes the lot through to the host. Mesa with a new target
and a couple of wrapper hacks springs to mind. Application openGL calls to the
driver can be passed straight through. As openGL is a client - server system
anyway, there should not be too many architectural problems with writing a
driver to do this.
OK, without host accelerated openGL, this could be quite slow but the interface
between the host and virtual system reduces to a couple of buffers and you have
the advantages of display lists begin stored on the host, not the client (for a
little speed gain). With a little hackery, frame buffer addresses could still be
passed through in order to speed up direct access for full screen mode.
Just a thought...
Bryan Meredith
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> > Of Max-Wilhelm Bruker
> > Sent: Monday, November 06, 2000 6:16 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: plex86 video proposal
> >
> >
> > Why is writing 3d acceleration drivers card specific? One could
> > implement a Voodoo card emulation, for example, and put the OGL commands
> > through the host's OGL driver. D3D commands could be converted to OGL,
> > or, if supported by the host, sent to the host's D3D implementation.
> >
> > --
> >
> > Max-Wilhelm Bruker <[EMAIL PROTECTED]>
> > ICQ: 14592934
> > Brukie on IRCnet
> >
> >
