[Mesa-dev] i965/gen9: Compression support for single-sampled

Pohjolainen, Topi topi.pohjolainen at intel.com
Wed Feb 10 12:13:27 UTC 2016


On Tue, Feb 09, 2016 at 05:34:53PM -0800, Ben Widawsky wrote:
> On Mon, Feb 08, 2016 at 06:51:20PM +0200, Topi Pohjolainen wrote:
> > This series enables compression for single sampled color surfaces,
> > also referred to as "lossless compression". This is yet only for
> > driver internal use easing pressure on memory bandwidth and caches
> > when writing, blending and sampling surfaces uing gpu.
> > 
> > As a side effect the need for color buffer resolves after fast
> > clears is also decreased. Current understanding is that sampling
> > engine doesn't understand meta data (auxiliary buffer) for single
> > sampled fast cleared surfaces. However, if the meta data is written
> > with lossless compression enabled, even sampling engine is capable
> > of reading both the color buffer and the auxiliary, and resolves
> > can be omitted in those case.
> > 
> > The final enabling patch is dependent on earlier two-patch series
> > fixing state restore mechanism in i965-meta operations.
> > 
> > There are some performance numbers available in the final commit.
> > 
> > Topi Pohjolainen (23):
> >   i965: Let caller of intel_miptree_create_layout() decide msaa layout
> >   i965: Use miptree non-aligned dimensions directly for x-tiled
> >   i965: Separate miptree creation from auxiliary buffer setup
> >   i965: Don't try to create aux buffer for non-msrt aux-buffer
> >   i965: Stop considering if msrt aux buffers need aux buffer
> >   i965/gen9: Add buffer layout representing lossless compression
> >   i965/gen9: Allow halign == 16 also for losslessly compressed
> >   i965: Allow fast clear to be used with lossless compression
> >   i965: Add resolve option for lossless compression
> >   i965: Use constant pointer when checking for compression
> >   i965/gen8: Remove dead assertion
> >   i965: Refactor resolving of auxiliary mode
> >   i965: Resolve color buffer also in lossless compression case
> >   i965: Add means for limiting color resolves
> >   i965: Add a flag telling color resolve pass to ignore CCS_E
> >   i965: Add a few assertions on lossless compression
> >   i965: Set buffer cleared after actually clearing it
> >   i965/gen9: Prepare surface state setup for lossless compression
> >   i965/gen9: Refactor msrt mcs initialization
> >   i965: Expose logic telling if non-msrt mcs is supported
> >   i965/gen9: Setup MCS for compressed texture surfaces
> >   i965: Add helper for checking for lossless compressible
> >   i965/gen9: Enable lossless compression
> > 
> >  src/mesa/drivers/dri/i965/brw_blorp_blit.cpp    |  21 +-
> >  src/mesa/drivers/dri/i965/brw_context.c         |  22 ++-
> >  src/mesa/drivers/dri/i965/brw_context.h         |   2 +-
> >  src/mesa/drivers/dri/i965/brw_defines.h         |   2 +
> >  src/mesa/drivers/dri/i965/brw_meta_fast_clear.c |  16 +-
> >  src/mesa/drivers/dri/i965/brw_surface_formats.c |   2 +-
> >  src/mesa/drivers/dri/i965/brw_tex_layout.c      |   2 +
> >  src/mesa/drivers/dri/i965/gen8_surface_state.c  |  90 +++++----
> >  src/mesa/drivers/dri/i965/intel_blit.c          |   4 +-
> >  src/mesa/drivers/dri/i965/intel_copy_image.c    |   4 +-
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c   | 249 +++++++++++++++++-------
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h   |  32 ++-
> >  src/mesa/drivers/dri/i965/intel_pixel_bitmap.c  |   2 +-
> >  src/mesa/drivers/dri/i965/intel_pixel_read.c    |   2 +-
> >  src/mesa/drivers/dri/i965/intel_tex_image.c     |   2 +-
> >  src/mesa/drivers/dri/i965/intel_tex_subimage.c  |   2 +-
> >  16 files changed, 318 insertions(+), 136 deletions(-)
> > 
> 
> Need to take a break, my head hurts.
> In addition to the comments I already left, 5, 8, 9, 10, and 11 are:
> Reviewed-by: Ben Widawsky <benjamin.widawsky at intel.com>
> 
> I think they might change at least a bit if you consider the feedback I've given
> so far, but it's really up to you.

Ok.

> 
> 8 is kind of useless on its own IMO, but whatever you like.

I suppose it is a matter of taste. It is non-functional change that just
introduces new enumeration and makes sure all the switch-cases take it
into account (unreachable()). To me it is clearer to have these separated
from real functional. But like said, matter of taste. Where would you
merge this?

> 
> I'd say you should push 10, and 11 now.
> 

Done. Thanks for the review so far!


More information about the mesa-dev mailing list