On Sun, Sep 30, 2001 at 10:09:47PM +0200, Marcelo E. Magallon wrote:
> >> Keith Whitwell <[EMAIL PROTECTED]> writes:
>
> > Very little consumer hardware provides support for the operations
> > necessary to implement much of drawpixels anyway.
>
> Could you please elaborate on this? As someone who has suffered
> because of poor glDrawPixels and glReadPixels performance in the past
> but has never seen a good technical explanation for that, I'm
> interested in the details, if you are willing to at least sketch them.
> Is it really a pure hardware problem? Rumors on comp.graphics.opengl
> are that the vendors don't invest time optimizing that path (in the
> driver) because there's not much demand for it. The Radeon driver
> performs acceptably well (contrast with the mga driver, which is 10x
> slower, IIRC) but it doesn't hit the maximum speed allowable by the PCI
> bus. Could it be faster or the current implementation opmital for that
> particular hardware?
On the i810, the problem is that it only does triangles. There is no easy
to glDrawPixels in an efficient way.
In general, the issue with consumer boards is that it isn't a path they
care about. You can replace "path they care about" with "path used in a
high selling game." In older chips the hardware didn't support any
acceleration.
In professional drivers, it is more of an issue and often
accelerated. Most of our drivers do accelerate it. We even did an AGP
extension which really makes it scream.
Depending on what you're doing, texture mapping a quad can be a fast
substitute for glDrawPixels. Getting even close to PCI bus is probably
as good as it gets. The AGP extension (on the G400) screams. We
demonstrated writes at 500MB/s on an AGP 2x card. Compaq funded that
work, by the way.
- |Daryll
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
