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. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
