i965/tex_image: Reference the renderbuffer miptree in setTexBuffer2
authorJason Ekstrand <jason.ekstrand@intel.com>
Tue, 12 Sep 2017 21:26:04 +0000 (14:26 -0700)
committerJason Ekstrand <jason.ekstrand@intel.com>
Mon, 18 Sep 2017 19:16:55 +0000 (12:16 -0700)
commitd80cbbeaff9329fdc78ae3d97097c1e65dfcdd61
tree0d24c22dcee13db0c905a23e525ea1b754ceeab2
parente97f4b748094466567c7f3bad1a02ecee13db9c8
i965/tex_image: Reference the renderbuffer miptree in setTexBuffer2

The old code made a new miptree that referenced the same BO as the
renderbuffer and just trusted in the memory aliasing to work.  There are
only two ways in which the new miptree is liable to differ from the one
in the renderbuffer and neither of them matter:

 1) It may have a different target.  The only targets that we can ever
    see in intelSetTexBuffer2 are GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE
    and the difference between the two doesn't matter as far as the
    miptree is concerned; genX(update_sampler_state) only looks at the
    gl_texture_object and not the miptree when determining whether or
    not to use normalized coordinates.

 2) It may have a very slightly different format.  Again, this doesn't
    matter because we've supported texture views for quite some time so
    we always look at the gl_texture_object format instead of the
    miptree format for hardware setup anyway.

On the other hand, because we were recreating the miptree, we were using
intel_miptree_create_for_bo which doesn't understand modifiers.  We
really want this function to work without doing a resolve so long as you
have modifiers so we need to fix that.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
src/mesa/drivers/dri/i965/intel_tex_image.c