intel/isl: Add support for RGB formats in X and Y-tiled memory
authorJason Ekstrand <jason.ekstrand@intel.com>
Fri, 9 Sep 2016 05:18:47 +0000 (22:18 -0700)
committerJason Ekstrand <jason.ekstrand@intel.com>
Tue, 13 Sep 2016 02:44:05 +0000 (19:44 -0700)
commitd038adca0eae173be0d2082f9b6d7e6d7c8aadf1
tree0bc9dfe91cb9c40bf14e0eb2513725f719456eab
parent883086500b130e4667108a52bca9f37defcd7564
intel/isl: Add support for RGB formats in X and Y-tiled memory

Normally, using a non-linear tiling format helps improve cache locality by
ensuring that neighboring pixels are usually close-by in memory.  For RGB
formats, this still sort-of holds, but it can also lead to rather terrible
memory access patterns where a single RGB pixel value crosses a tile
boundary and gets split into two pieces in different 4K pages.  It also
makes for some rather awkward calculations because your tile size is no
longer an even multiple of surface element size.  For these reasons, we
chose to simply never create tiled RGB images in the Vulkan driver.

The GL driver, however, is not so kind so we need to support it somehow.  I
briefly toyed with a couple of different schemes but this is the best one I
could come up with.  The fundamental problem is that a tile no longer
contains an integer number of surface elements.  I briefly considered a
couple other options but found them wanting:

 1) Using floats for the logical tile size.  This leads to potential
    rounding error problems.

 2) When presented with a RGB format, just make the tile 3-times as wide.
    This isn't so nice because now our tiles are no longer power-of-two
    size.  Also, it can force the row_pitch to be larger than needed which,
    while not strictly a problem for ISL, causes incompatibility problems
    with the way the GL driver chooses surface pitches.

The chosen method requires that you pay attention and not just assume that
your tile_info is in the units you think it is.  However, it's nice because
it provides a nice "these are the units" declaration in isl_tile_info
itself.  Previously, the tile_info wasn't usable as a stand-alone structure
because you had to also know the format.  It also forces figuring out how
to deal with inconsistencies between tiling and format back to the caller
which is good because the two different consumers of isl_tile_info really
want to deal with it differently:  Computation of the surface size wants
the fewest number of horizontal tiles possible while get_intratile_offset
is far more concerned with things aligning nicely.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Chad Versace <chadversary@chromium.org>
src/intel/isl/isl.c
src/intel/isl/isl.h