intel: Clean up confusion between logical and physical surface dimensions.

In most cases, the width, height, and depth of the physical surface
used by the driver to implement a texture or renderbuffer is equal to
the logical width, height, and depth exposed to the client through
functions such as glTexImage3D().  However, there are two exceptions:
cube maps (which have a physical depth of 6 but a logical depth of 1)
and multisampled renderbuffers (which have larger physical dimensions
than logical dimensions to allow multiple samples per pixel).

Previous to this patch, we accounted for the difference between
physical and logical surface dimensions at inconsistent places in the
call graph (multisampling was accounted for in
intel_miptree_create_for_renderbuffer(), and cubemaps were accounted
for in intel_miptree_create_internal()).  As a result, it wasn't
always clear, when calling a miptree creation function, whether
physical or logical dimensions were needed.  Also, we weren't
consistent about storing logical dimensions in the intel_mipmap_tree
structure (we only did so in the
intel_miptree_create_for_renderbuffer() code path, and we did not
store depth).

This patch refactors things so that intel_miptree_create_internal() is
responsible for converting logical to physical dimensions and for
storing both the physical and logical dimensions in the
intel_mipmap_tree structure.  As a result, all miptree creation
functions interpret their arguments as logical dimensions, and both
physical and logical dimensions are always available to functions that
work with intel_mipmap_trees.

In addition, it renames the fields in intel_mipmap_tree used to store
the dimensions, so that it is clear from the name whether physical or
logical dimensions are being referred to.

This should fix the following bugs:

- When creating a separate stencil surface for a depthstencil cubemap,
  we would erroneously try to convert the depth from 1 to 6 twice,
  resulting in an assertion failure.

- When creating an MCS buffer for compressed multisampling, we used
  physical dimensions instead of logical dimensions, resulting in
  wasted memory.

In addition, this should considerably simplify the implementation of
ARB_texture_multisample, because it moves the code to compute the
physical size of multisampled surfaces out of renderbuffer-only code.

Reviewed-by: Chris Forbes <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Chad Versace <[email protected]>

0 files changed, 0 insertions, 0 deletions