On Tue, Mar 10, 2015 at 05:39:24PM +0000, Neil Roberts wrote: > Ben Widawsky <benjamin.widaw...@intel.com> writes: > > > This patch will use a new calculation to determine if a surface can be > > blitted > > from or to. Previously, the "total_height" member was used. Total_height in > > the > > case of 2d, 3d, and cube map arrays is the height of each slice/layer/face. > > Since the GL map APIS only ever deal with a slice at a time however, the > > determining factor is really the height of one slice. > > Do you mean to say that total_height is the combined height of all of > the slices/layers/faces? If so the wording is confusing. >
Yep. Thanks, I agree, and fixed. > > +static inline uint32_t > > +intel_miptree_blit_height(struct intel_mipmap_tree *mt) > > +{ > > + switch (mt->target) { > > + case GL_TEXTURE_CUBE_MAP: > > + case GL_TEXTURE_1D_ARRAY: > > + case GL_TEXTURE_2D_ARRAY: > > + case GL_TEXTURE_2D_MULTISAMPLE_ARRAY: > > + case GL_TEXTURE_CUBE_MAP_ARRAY: > > + assert(mt->logical_depth0); > > + return mt->qpitch; > > + case GL_TEXTURE_3D: > > + /* FIXME 3d textures don't have a qpitch. I think it's simply the > > tiled > > + * aligned mt->physical_height0. Since 3D textures aren't used > > often, just > > + * print the perf debug from the caller and bail > > + */ > > + /* fallthrough */ > > + default: > > + return mt->total_height; > > + } > > +} > > This function might stop working on Skylake if we land my patch to fix > the qpitch calculation. In that case the qpitch isn't necessarily a > count of the number of rows. In 1D textures it is the number of pixels > and for compressed textures it is the number of blocks. Maybe we could > also store the physical_qpitch that is calculated in > brw_miptree_layout_texture_array? > I'm pretty sure today we never use the blitter for compressed textures. Therefore, I believe we can ignore that case. In the case where we use pixels, I believe it will still work fine as long as long as each layer is tightly packed (which I thought it was). If it's not, then I suppose we have a problem. I'm also totally fine with making 1D fallthrough since I don't think it's a particularly common case for it to surpass total_height anyway. Any preference on which to land first (and therefore who has to fix it)? My patches are older, but yours potentially fixes bugs and mine is just perf. > Regards, > - Neil -- Ben Widawsky, Intel Open Source Technology Center _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev