Chris Ison wrote:
ok, looking of the oprofile output of libgl, r200_dri and qw-client-glx, I decided to hunt for the function
texsubimage2d_bgr888_to_rgba8888 which is at the top of the list at 22.6% of the time.
So, it looks like it's basically converting from one byte order to another. There's a comment in texformat.h about "Upcoming little-endian formats". If support for those were added, the driver could just select a format with the right byte-order. It doesn't look like the R200 supports any permutations of RGB888, only RGBA8888, so that may not help here.
Alternately, this might be a case where writing a little assembly conversion routine would help. If we assume at least a 486 instruction set (eh-hem!), the core of the BGR to ARGB conversion should take about 6 or 7 instructions, including the pointer increments. It may even be worthwhile to do an MMX optimized version. Dunno.
I'm wondering though why the heck quakeworld actually uses so much texsubimage2d calls. Typically, games specify textures at level load time and leave them completely alone after that - at least those games I profiled with oprofile never showed texsubimage2d calls. Is there something special about the quakeworld 3d engine?
Roland
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
