On 8/21/06, Jon Smirl <[EMAIL PROTECTED]> wrote:
You might want to poll your consumers and see if they are going to buy a PCI board. I only use PCI versions of cards for test and development. They are visibly too slow for normal use.
Unless you accelerate enough stuff so that it's not visibly slow. Cards are only visibly slow under Linux because the drivers are half done. Some don't accelerate a lot more than bitblt and solid fill (it would seem), so text, lines, patterned fills, and numerous other things are slow and you can tell. Even image loads are perceptibly faster when you use DMA (more efficient use of the bus). My 2000-era TROZ design is something you would never know was on a PCI bus. That's partly because my DDX accelerates everything. Tiles, stipples, text (with a number of special cases for more performance), solid fills, bitblts, lines, complex shapes (via accelerated spans, solid, stippled, and tiled), and a number of other things you would never consider accelerating because they're useful for ATC and give your system a more responsive feel. I even accelerate zeropolyarcs! You would be surprised how much more responsive your system feels when the default X11 root window tile is accelerated. TROZ even has a mechanism to apply a planemask and a ROP to host writes to the framebuffer, so rather than a read-modify-write cycle, it's just a write, making something like a putimage with XOR several times faster than it would otherwise be. I've been writing X11 drivers for a long time, so I have a really good idea of what is necessary to make a graphics system feel fast, even on PCI.
There is also the problem with bus saturation. If I have a PCI graphics card running at full speed it eats all of the bus bandwidth from other PCI devices. Internal IDE controllers are often on the same PCI bus even though they are on the motherboard.
Yes, this is a concern we have. What can we do about it? All we can do is strive to make the best of what we have. I've been doing that for a long time, so I think I can figure out what to do.
This is why we are disconnecting on discussions about frequency of DMA use. With AGP around DMA is less relevant.
In my opinion, DMA is paramount. I've come to really despise graphics drivers that eat CPU time for no good reason (in part because I've written a lot of them myself and have seen the drawbacks). DMA is the only way to minimize use of CPU overhead for graphics. Get two network cards, one that does DMA and one that doesn't. Under heavy networking load, you'll notice a difference. Even more noticable: Turn off DMA for your IDE hard drive. It makes your whole system unbearably slow.
> What is the "PCI-express way"? The GPU operates in it's own internal 32b address space. There are still address translation tables on the graphics card mapping from internal addresses to system addresses.
I thought AGP GART and IOMMU and these other things were already doing this with legacy PCI.
My suggestion would be to go PCI express and make the card adapt from 1/4/8 lanes. That way I can plug it into an extra 1 lane socket for development and an 8/16 lane socket for general use. There is no real gain going from 8 to 16 lanes for any existing apps.
Do you know how complicated it is to go from 1-lane to 4-lane? Plus, I'm not sure we could make good use of the extra bandwidth anyhow. If OGC1-PCI will feel fast (and I know it will), there's nothing that PCIe 4x is going to give us that 1x won't. KEEP IT SIMPLE. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
