This E-Mail may be vary controversial and lame to no extent. I.E. It's negitive.
> [*] The "write register/read register" should be made to use > PCI register sets, instead of any hardcoded addresses. > So instead of "write a byte to I/O address 0xc0f", you would make > a call to "write a byte to register set 1, offset 0x2". > My comments to this really don't apply hear because System CPU cycles are not really in demand, now that most of the computation has been off-loaded to the GPU. This seamed like something that should be done with #defines and not effect the actual code. I knew that this was done with the Sound Blaster driver and I investigated there solution. ... #define DSP_STATUS (devc->base + 0xC) ... Vary slick, it makes the real code look clean. My problem is that every IO is preceded with an add instruction. I don't see this getting optimized ought, devc->base is derived from the mandatory mod. param. "IO". If this were code from the original dos quake/wolf3d I would have a real problem. Now I wonder if I could get higher FPS had I spotted this back when I had a 486 just barely playing quake. I will say MS-Dos 6.22 could not out preform linux in that case :) --- Philip Brown <[EMAIL PROTECTED]> wrote: > On Thu, Jan 24, 2002 at 08:07:18PM -0700, Jens Owen wrote: > > [WARNING, this is a long response that addresses the pros and cons of > > separating the 3D drivers from XFree86] > > .... > > > I'd like to respond to just a few things in Jens's excellently written > email. > > > Another pitfall that comes to mind is we're going to have to deal with a > > significantly larger number of incompatability problems if we separate > > the trees. ... > > Not if things are designed properly. see below. > > > > > I think the level of reorganization involved with separating out 2D and > > 3D trees will be a MAJOR disruption to current development. We should > > consider waiting until we have a major structural change that's going to > > impose a similar level of disruption, like a Unified Driver Interface > > and if we have a solid plan that minimizes the pitfalls, possibly > > address the seperation at that time. > > If you make stipulations like that, it will NEVER happen. > [or, contrariwise, it's time to make that Unified Driver Interface!] > If you agree that it's a good idea, and that it should happen.... it should > happen as soon as someone capable is wiling to do the work on it. > > Now, to address what "it" might look like: > > I think having the driver stuff buried way under the DRI source, which > itself is buried deep in the xfree source... is *nasty*. > > One of the best cleanups possible, IMO, would be a one-two punch in the > driver arena: > > 1. Minimize the driver interface, to make it both easy to port, yet > flexible to allow lots of future possbilities. > WIth the right driver interface, there would be minimal future > incompatibility problems, because the driver interface would not > have to change. See lower down for details on a potential interface. > > > 2. Strip it out of the tree completely. Document in the DRI subtree, > "This is the API we need: .... > These are the drivers known to implement it, on these OS's" > > > For example, instead of a whole bunch of different odd hardware-specific > calls, limit the driver to the following classes of operations: > > 1. AGP (and make it SIMPLE!) > 2. DMA (See above) > 3. write register/read register [*] > > This should cover EVERYTHING possibly needed. > [*] The "write register/read register" should be made to use > PCI register sets, instead of any hardcoded addresses. > So instead of "write a byte to I/O address 0xc0f", you would make > a call to "write a byte to register set 1, offset 0x2". > > This gives lots of benefits, from being intrinsically "cleaner", to > meaning that you no longer have to be doing driver-type operations > directly in user-space. Well, you kind of are, but at least it's a > LITTLE more abstracted. I think the reliability factor here is worth > the slight degredation in performance that this would entail. > > _______________________________________________ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
