[Mesa-dev] [PATCH] intel: Kill intel_mipmap_level::nr_images

Chad Versace chad at chad-versace.us
Mon Oct 24 13:51:44 PDT 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/22/2011 11:45 PM, Eric Anholt wrote:
> On Fri, 21 Oct 2011 20:45:59 -0700, Chad Versace <chad at chad-versace.us> wrote:
>> For all texture targets except GL_TEXTURE_CUBE_MAP, the 'nr_images' and
>> 'depth' fields of intel_mipmap_level were identical.  In the exceptional
>> case, nr_images == 6 and depth == 1.
>>
>> It is simple to determine if a texture is a cube or not, so the presence
>> of two fields here was not helpful. Worse, it was confusing.
>>
>> This patch removes 'nr_images' and assigns to 'depth' a consistent
>> meaning: depth is the number of two-dimensional slices at each miplevel.
>> The exact semantics of depth varies according to the texture target:
>>    - For GL_TEXTURE_CUBE_MAP, depth is 6.
>>    - For GL_TEXTURE_2D_ARRAY, depth is the number of array slices. It is
>>      identical for all miplevels in the texture.
>>    - For GL_TEXTURE_3D, it is the texture's depth at each miplevel. It's
>>      value, like width and height, varies with miplevel.
>>    - For other texture types, depth is 1.
>>
>> As a consequence, parameters were removed from the following function
>> signatures:
>>     intel_miptree_get_image_offset
>>         Remove 'face'.
>>
>>     intel_miptree_set_level_info
>>         Remove 'nr_images'.
>>
>>     i945_miptree_layout
>>     brw_miptree_layout_texture
>>     brw_miptree_layout_texture_array
>>         Remove 'slices'.
>>
>> No regressions found on gen6.
>>
>> CC: Eric Anholt <eric at anholt.net>
>> Signed-off-by: Chad Versace <chad at chad-versace.us>
>> ---
>>  src/mesa/drivers/dri/i915/i830_texstate.c       |    2 +-
>>  src/mesa/drivers/dri/i965/brw_tex_layout.c      |   17 +++----
>>  src/mesa/drivers/dri/intel/intel_blit.c         |    1 -
>>  src/mesa/drivers/dri/intel/intel_fbo.c          |   11 ++++-
>>  src/mesa/drivers/dri/intel/intel_mipmap_tree.c  |   55 ++++++++++++-----------
>>  src/mesa/drivers/dri/intel/intel_mipmap_tree.h  |   20 ++++++---
>>  src/mesa/drivers/dri/intel/intel_tex.c          |   13 +++++-
>>  src/mesa/drivers/dri/intel/intel_tex_copy.c     |    1 -
>>  src/mesa/drivers/dri/intel/intel_tex_image.c    |    2 +-
>>  src/mesa/drivers/dri/intel/intel_tex_layout.c   |    4 +-
>>  src/mesa/drivers/dri/intel/intel_tex_layout.h   |    3 +-
>>  src/mesa/drivers/dri/intel/intel_tex_subimage.c |    2 +-
>>  src/mesa/drivers/dri/intel/intel_tex_validate.c |    5 +-
>>  13 files changed, 78 insertions(+), 58 deletions(-)
> 
>> diff --git a/src/mesa/drivers/dri/intel/intel_tex_validate.c b/src/mesa/drivers/dri/intel/intel_tex_validate.c
>> index 4012400..68dc76e 100644
>> --- a/src/mesa/drivers/dri/intel/intel_tex_validate.c
>> +++ b/src/mesa/drivers/dri/intel/intel_tex_validate.c
>> @@ -161,7 +161,7 @@ intel_tex_map_image_for_swrast(struct intel_context *intel,
>>         * share code with the normal path.
>>         */
>>        for (i = 0; i < mt->level[level].depth; i++) {
>> -	 intel_miptree_get_image_offset(mt, level, face, i, &x, &y);
>> +	 intel_miptree_get_image_offset(mt, level, i, &x, &y);
>>  	 intel_image->base.Base.ImageOffsets[i] = x + y * mt->region->pitch;
>>        }
>>  
>> @@ -169,8 +169,7 @@ intel_tex_map_image_for_swrast(struct intel_context *intel,
>>  
>>        intel_image->base.Base.Data = intel_region_map(intel, mt->region, mode);
>>     } else {
>> -      assert(mt->level[level].depth == 1);
>> -      intel_miptree_get_image_offset(mt, level, face, 0, &x, &y);
>> +      intel_miptree_get_image_offset(mt, level, face, &x, &y);
>>        intel_image->base.Base.ImageOffsets[0] = 0;
> 
> I wasn't convinced by the change to drop face from get_image_offset, and
> I think this confirms it for me: you're walking over each face of the
> cube, and maping each face for every iteration.
> 
> It seems like logic that was inside the function is getting pushed out
> to each caller.

intel_mipmap_copy_teximage() will need refactoring for the HiZ miptree work.
So I'll postpone this patch until that refactoring has solidified.

- -- 
Chad Versace
chad at chad-versace.us
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOpc/eAAoJEAIvNt057x8i118P/3hRZuyweaaMIHtZyKhL1CiR
LQ7MvG33YNt8LLNHABtqXjFCdtqxrw5IWYzKuKs6BGxAJYc0IJAqQrP8fASiwlg6
AHtxQF8l+5vVwU7TpsKnaLl85zr8pCSR7XRFZZxKIJlD6p/MZHjic26kHAk9FRqP
6t/Ig4s47M9ZTXlnwtO6jw88V4a4i2sOMoiB+cWevmbzpHAuHSePTT+oiPXQmwCS
VMZzXHxQFjK2kOoNy8T58nxPbuIRvWzFeQ/1qPwtLFl0o/M5cIBgECP+U8UM9MNN
7rRjKlvnKlmVtG7plgKrIxV8SV57NfqiAFPEB/s7/sOtz9bmOZxh7KMVED9xKahr
hAaeU6MMqlDykFXBZnX9URg0Rsto4GnTDq6ctO62bzXDc5epg3GgMkcTLln19fju
MfHa5GUMweR4/gSeIfDd4QMKrTIz++7HmlXDrjTHYav7m8SKLAQJ5ojDuH1MvCWr
E9+5YoPCoZ2BhQHaNCHqb7qmAl9hZAdfIq97pQ2K/zmtf7x8dnhPiryZUBbjMCSD
rnCdFfCflt7zTbDvT6a37V8SO3YcL/ZJdDmBcf+Bv2sgqhkdEV2bM8og1LvKRte5
Eww0lMd2F12EercAyzp2ElYQBrTsSo95pBvI7tZiTJZQF+5jTxxtWEDYc38L/y0R
fOxgoyTd7j2ft6e0JOAT
=0pQF
-----END PGP SIGNATURE-----


More information about the mesa-dev mailing list