Peter Lamberg wrote:
copyTexImage2D et al. seem horribly slow for anything more than few
hundred pixels.

It seems from radeon_tex.c that frame buffer -> texture operations are
implemented without any hardware help from the card:
   ctx->Driver.CopyTexImage1D                = _swrast_copy_teximage1d;
   ctx->Driver.CopyTexImage2D                = _swrast_copy_teximage2d;

Is this due to some fundamental limitation of radeon cards?
(mine is a 7500)

How could this be done with hardware support?
Could this be done with same onboard machinery that puts texels
to frame buffer, only in reverse?
How difficult would this be to implement?

The real issue here is memory management of the texture space. Because there is currently no mechanism to 'pin' on-card or agp texture memory, that memory can be stolen & overwritten by other contexts at potentially any time. The driver copes with this by always keeping a copy of textures in main memory. This works fine most of the time.


Unfortunately, it means that when you do a CopyTexSubImage or whatever, it is necessary to suck the data out of the card to get that copy in main memory.

Ian started work on a better memory manager, and I have a makeshift one on the i865 branch.

Keith



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to