On 6/20/06, Dieter <[EMAIL PROTECTED]> wrote:
My crystal ball says AGP will go away very soon. My crystal ball says PCI will go away, but slower than AGP. The problem will be too few slots per board. (Even worse than now.) My crystal ball says PCIe will be good for several years.
That's why we chose PCI-X. That's because PCI will be around a while, and we can slap a PCIX-PCIe bridge chip on a board and get PCIe.
The real unserved market is Ethernet, but I don't expect to be able to convince anyone of that.
I'm convinved. I just have to get the more common case done first. :)
> We can compete with commodity items as > long as the commodity items have closed source drivers. However, we can > only compete on this basis with Linux and BSD users. Or provide something (in addition to openness) that the commodity items do not.
OGC1 performance won't be as bad as you may think.
> Can we get the performance we need with 65 nm or do we need > to go smaller? If the design were ready today, could we even get 65 nm? Isn't AMD still using 90 nm?
I don't think it's necessary. 65nm, compared to 90, buys you mostly power consumption and yield. Performance doesn't go up that much. Keep in mind that it's wire delays, not transistor switching time, that dominates chip performance.
> > If I want an OpenGL card, I will buy a nVidia or ATI card that is > > reasonably well supported by an open source driver. In fact, I > > already have, several times. Sure, I can't play games with texture > > compression, or using the very latest card, but that will apply to an > > OGP card too. But, guess what? The Radeon 9200 (with open source > > drivers) in my machine will probably outmatch any OGP design, and > > will cost a negligible amount of money by the time any OGP design > > tapes out. Is there any area where the OGC1 is faster than a Radeon 9200/9250? Or equally fast with less CPU load?
It'll go exactly the same speed as any other card that has a 128-bit DDR400 memory bus. Ok, well, slower for some operations, but once you saturate the bus, the same speed. (Except for those with Z compression, but that may not buy you huge amounts.)
> This is something to consider. While nVidia and ATI do not actually > make native OpenGL cards they do dominate the market to the detriment of > the *NIX graphics market. Solaris is some form of open source now, right? What graphics/video chips do Sun's machines use?
A variety of things, including this product whose X11 driver I wrote: http://www.sun.com/products-n-solutions/hardware/docs/html/819-5737-10/
> > I, personally, do not want a 3D card for GUI use at all. I want a GUI > > that works, and works responsively, and smoothly. Ex-Amiga users > > will know what I mean. Everyone else has yet to experience what I am > > talking about. > > I have not experienced what you are talking about but I do experience > what I think that you are complaining about. IIUC, this is not a > function of the graphics card but rather of the way that *NIX does > multitasking. UNIX will block user I/O to do other things -- a very > broken idea for GUIs. Some distros try to ameliorate this by bumping X > up to Nice=-10, but I don't see that this really helps. What versions of Unix block I/O to do other things? It is normally I/O that gets preference.
I'm not sure what's being discussed here. Usually, you try to overlap CPU and I/O by using DMA. But the process waiting on the I/O is blocked. And sometimes, you can't do the I/O via DMA. There are also issues with the X server using enough CPU that process schedulers will drop it in priority.
You mention "distros", so is this something specific to linux? > I think that what you need to address this without rewriting parts of > the Linux Kernel is to have a CPU dedicated to running X. If so, someone needs to rewrite the Linux Kernel.
With a graphics card that uses DMA, you offload the I/O overhead from the CPU to the GPU, so the CPU can do other things. This has the effect of lowering the load for the X server, so it gets a higher process priority. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
