# Handling hardware that can't handle mipmaps

To one degree or another, most older graphics chips do not support mipmaps.  Some new chips, such as the R100 family, don't support mipmaps on cubic or volume textures.  This document presents a couple different ways to deal with such hardware.  A description of each technique will be presented along with its pros and cons. 

The following table summarizes the chips know to have mipmapping limitations. 
[[!table header="no" class="mointable" data="""
**Chip name** | **Supported by Mesa?** | **Rasterization Method** | **1D / 2D mipmaps** | **3D mipmaps** | **cubic mipmaps**
ATI Rage IIc |  No |  Scanline |  No |  N/A |  N/A
ATI [[RagePro|RagePro]] |  Yes |  Polygon setup |  No |  N/A |  N/A
ATI Radeon R100 |  Yes |  TNL |  Yes |  No |  No
ATI Radeon R200 |  Yes |  TNL |  Yes |  No |  Yes
S3 Virge |  No<sup>[1](#driver-exists)</sup> |  Scanline |  No |  N/A |  N/A
3Dlabs 500TX |  No |  Polygon setup<sup>[2](#polygon-setup)</sup> |  No |  N/A |  N/A
Matrox G100 |  No |  Scanline? |  No? |  N/A |  N/A
"""]]

<a name="driver-exists">1</a>: A driver exists, but it is not maintained and is know to have significant problems. 

<a name="polygon-setup">2</a>: Polygon setup is performed by a Glint Delta chip, and rasterization is performed by the 500TX.  Some (rare) cards may exist that omit the Delta, and it may be possible to circumvent the Delta and program the 500TX directly. 


## Clamp to base LOD

The easiest technique is to simply use the base LOD setting for the texture.  When selecting which mipmap to use, all of the usual variables (e.g., LOD bias, explicit baselevel setting, etc.) are considered.  Then, that single mipmap is used until either the current texture or the LOD settings are changed. 

It should be noted that this technique will produce very incorrect results if the successive mipmaps are not scaled, filtered versions of the base map.  Other than programs that test the texture filtering quality of a driver, I don't know of any applications that do this, but they may exist. 

Pros: 

* Very easy to implement 
* Fast 
Cons: 

* Non-conformant 
* Low visual quality 

## Fallback to software

Another option is to fallback to software rasterization if a mipmapped texture filter is selected. 

Pros: 

* Very easy to implement 
* Conformant 
* High visual quality 
Cons: 

* **SLOW** 

## Calculate per-polygon LOD

After the points of a polygon have been transformed, clipped, lit, and transformed to screen space, the resulting data can be used to approximate the rho calculation defined by the OpenGL spec (see pages 171 and 172 of the [[OpenGL 2.0 spec|http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf]]).  For each edge in the polygon, the following calculation is performed. 

   * rho = max( sqrt( sqr(du/dx) + sqr(dv/dx) + sqr(dw/dx) ), sqrt( sqr(du/dy) + sqr(dv/dy) + sqr(dw/dy) ) ) 
Where dx and dy are the changes in screen space coordinates across the edge.  du, dv, and dw are the changes in texel addresses across the edge.  In this case, u = s * width, v = t * height, and w = r * depth.  For 1D textures, height and depth are zero.  For 2D textures, depth is zero. 

On hardware that is scanline based (e.g., S3 Virge), this calculation could be done per-scaneline during rasterization.  However, other hardware limitations may make this impractical. 

As an interesting side effect, this algorithm could be used to implement per-polygon anisotropic filtering.  The technique is [[described|http://www.opengl.org/resources/tutorials/advanced/advanced98/notes/node37.html]] in the SIGGRAPH '98 course [[Advanced Graphics Programming Techniques Using OpenGL|http://www.opengl.org/resources/tutorials/advanced/advanced98/notes/notes.html]]. 

Marc Olano et. al. has a paper on a similar technique called [["Vertex-based Anisotropic Texturing"|http://www.csee.umbc.edu/~olano/papers/vbat/vbat.pdf]].  [[Slides|http://www.csee.umbc.edu/~olano/papers/vbat/]] are also available for the 2001 SIGGRAPH/Eurographics Workshop on Graphics Hardware presentation.  This algorithm may not be of much use here, but the paper is an interesting read either way. 

Pros: 

* Improved visual quality 
* Allows "fake" anisotropic filtering 
Cons: 

* Non-conformant 
* Difficult to implement in Mesa 
* Sizable performance hit 

## Calculate per-batch LOD

This technique is just like calculating the per-polygon LOD, but the same mipmap level is used for all polygons in a batch (e.g., within a single glBegin / glEnd pair). 

Pros: 

* Improved visual quality 
* Modest performance hit on non-TNL cards 
Cons: 

* Non-conformant 
* Difficult to implement in Mesa 


---

 [[CategoryHardware|CategoryHardware]]