In the copy fallback, when a texture can not be rendered, the data that resides in the backing iovec needs to be used. For the non-zero levels of mip-map textures the data is located at an offset. This patch adds storing this offset and using it when data is read from the backing iovec and updating the dst iov. We limit the mip-map levels for which this is done to 1-17, which is enough to cover 32kx32k textures. The patch also fixes the stride when accessing mip-map levels. Fixes: dEQP-GLES3.functional.texture.specification.teximage3d_depth.depth_component24_2d_array dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth_component32f_2d_array dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth_component24_2d_array dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth_component16_2d_array dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth32f_stencil8_2d_array dEQP-GLES3.functional.texture.specification.texsubimage3d_depth.depth24_stencil8_2d_array v2: * rebase and remove unused variables * also correct offset when writing to the destination backing iovec v3: * follow mesa/virgl notation and range for storing the mip-map offsets Suggested-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>macos/master
parent
00e62addc3
commit
04f2080d89
Loading…
Reference in new issue