[Mesa-dev] mt->first_level != BaseLevel

Eric Anholt eric at anholt.net
Wed Sep 18 12:59:19 PDT 2013


Until now, whenever someone adjusts BaseLevel, we copy around the miptree
contents to a new miptree that starts from BaseLevel, which is pretty
awful when you think about things like generating mipmaps using FBOs and
BaseLevel/MaxLevel (which our glGenerateMipmap() does).  Disentangling
this code has been hard, though.

I've been on a mission to kill mt->first_level for a while.  It doesn't
fit with other drivers, which has blocked any plans I've come up with to
share miptree management code between drivers (which it seems obvious to
me we ought to be doing, given how common they all look).  As of this
series, the only source of mt->first_level != 0 should be
intel_renderbuffer_move_to_temp() callers.

After this, I think I can extract a series to do color render target
LOD/array index on gen4-6, removing another first_level != 0 case, and
then I get to try and finally figure out why gen6 non-hiz is broken so we
can do depth LOD != 0.


More information about the mesa-dev mailing list