Re: [Dri-devel] New texture conversion code

[Brian P. <br...@va...>]

Gareth Hughes wrote:
> 
> Early optimization may be the root of all evil, but early benchmarking
> isn't necessarily...
> 
> The following texture download bandwidth numbers were obtained with
> Mesa/demos/texdown.  The tests were run at 16bpp and 32bpp to allow the
> drivers to select appropriate texel sizes.  The Radeon and MGA scores
> are used to show typical performance from the Utah-GLX style texture
> conversion code. Big caveat: these drivers use full async DMA to
> transfer the images via the AGP bus.  The tdfx driver, on the other
> hand, has to do PIO transfers.  Please keep this in mind.
> 
> The tdfx driver also uses the "new" single-copy texture image support in
> Mesa.  I will include the original scores as well as those obtained with
> my even-newer pluggable texture conversion architecture.  Again, keep in
> mind that the tdfx transfers are done via PIO, and thus the scores will
> be lower.  However, the gains from my new code should mean that a
> DMA-based solution will get scores as good or better than the Utah-style
> conversions, with the added benefit of the single-copy mechanism.
> 
> At the moment, all the conversion code is still in C, but it is now
> trivial to plug in MMX assembly versions of the important conversion
> routines.  Best part about this is that *all* drivers will benefit from
> this once they are moved across to the new interface.
> 
> Here are the four texdown tests:
> 
>  run   format     type     internal format
> 
>   1     RGB       ubyte         RGB
>   2     RGBA      ubyte         RGBA
>   3     RGBA      ubyte         RGB
>   4     RGB     ushort565       RGB
> 
> 16bpp:
> 
>  run                Radeon                     MGA
> 
>   1             146 mb/s  RGB565        148 mb/s  RGB565
>   2             144 mb/s  ARGB4444      148 mb/s  RGB565
>   3             105 mb/s  RGB565        106 mb/s  RGB565
>   4               5 mb/s  RGB565          5 mb/s  RGB565
> 
>  run                tdfx old                tdfx new
> 
>   1              41 mb/s  ARGB8888       77 mb/s  RGB565
>   2              74 mb/s  ARGB8888       86 mb/s  RGB565
>   3              53 mb/s  ARGB8888       96 mb/s  RGB565
>   4               4 mb/s  ARGB8888      210 mb/s  RGB565
>                           ^^^^^^^^
>                           Don't know why it does this...
> 
> 32bpp:
> 
>  run                Radeon                     MGA
> 
>   1             140 mb/s  RGBA8888      136 mb/s  ARGB8888
>   2             142 mb/s  RGBA8888      141 mb/s  ARGB8888
>   3             106 mb/s  RGBA8888      105 mb/s  ARGB8888
>   4               5 mb/s  RGBA8888        5 mb/s  ARGB8888
> 
>  run                tdfx old                tdfx new
> 
>   1              41 mb/s  ARGB8888       73 mb/s  ARGB8888
>   2              74 mb/s  ARGB8888       82 mb/s  ARGB8888
>   3              53 mb/s  ARGB8888       83 mb/s  ARGB8888
>   4               4 mb/s  ARGB8888      207 mb/s  ARGB8888
> 
> If we change the tdfx driver's 32bpp texture format from ARGB8888 to
> RGBA8888, we get:
> 
>  run                                        tdfx new
> 
>   2                                     210 mb/s  RGBA8888
> 
> TODO:
> 
> - Finish off texsubimage versions of the functions.
> - Port radeon driver to new interface, with other drivers to follow.
>   Volunteers always appreciated!
> 
> Once I've got the Radeon up and running, I'll post more numbers to see
> how well this works with DMA-based texture uploads.


Just a few words of warning about the texdown test.  At the time I
wrote it I was only targetting the 3dfx driver.  The 3dfx driver used
to always immediately transfer the texture image to glide; i.e. no
lazy evaluation.

The driver has changed since then and uses lazy texture download
like the other DRI drivers.  The texdown program should probably
draw a tiny primitive after _every_ glTexImage call in order to
force the image all the way to the hardware.

Just be sure you completely understand what's happening all they way
through the glTexImage path before putting too much stock in your
numbers.

-Brian