On Tue 12 Sep 2017, Jason Ekstrand wrote: > 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. > --- > src/mesa/drivers/dri/i965/intel_tex_image.c | 23 ++++------------------- > 1 file changed, 4 insertions(+), 19 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c > b/src/mesa/drivers/dri/i965/intel_tex_image.c
> intel_miptree_make_shareable(brw, rb->mt); > - mt = intel_miptree_create_for_bo(brw, rb->mt->bo, texFormat, 0, > - rb->Base.Base.Width, > - rb->Base.Base.Height, > - 1, rb->mt->surf.row_pitch, > - MIPTREE_CREATE_DEFAULT); > - if (mt == NULL) > - return; > - mt->target = target; > _mesa_lock_texture(&brw->ctx, texObj); > texImage = _mesa_get_tex_image(ctx, texObj, target, 0); > - intel_set_texture_image_mt(brw, texImage, internal_format, mt); > - intel_miptree_release(&mt); > + intel_set_texture_image_mt(brw, texImage, internal_format, rb->mt); > _mesa_unlock_texture(&brw->ctx, texObj); The above hunk looks like the logical conclusion of consecutive commits 40e9be4 and 8ceb7c7. In fact, it seems like this was commit's 8ceb7c7 actual intention. Reviewed-by: Chad Versace <chadvers...@chromium.org> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
