[Mesa-dev] [PATCH] [v2] i965: Add lossless compression to surface format table

Chad Versace chad.versace at intel.com
Wed Nov 18 10:28:27 PST 2015


On Tue 17 Nov 2015, Ben Widawsky wrote:
> Background: Prior to Skylake and since Ivybridge Intel hardware has had the
> ability to use a MCS (Multisample Control Surface) as auxiliary data in
> "compression" operations on the surface. This reduces memory bandwidth.  This
> hardware was either used for MSAA compression, and fast clear operations.  On
> Gen8, a similar mechanism exists to allow the hiz buffer to be sampled from, and
> therefore this feature is sometimes referred to more generally as "AUX buffers".
> 
> Skylake adds the ability to have the display engine directly source compressed
> surfaces on top of the ability to sample from them. Inference dictates that
> enabling this display features adding a restriction to the formats which could
> actually be compressed. The current set of surfaces seems to be a subset as
> compared to previous gens (see the next patch). Also, if I had to guess I would
> guess that future gens add support for more surface formats. To make handling
> this a bit easier to read, and more future proof, the support for this is moved
> into the surface formats table.
> 
> Along with the modifications to the table, a helper function is also provided to
> determine if a surface is CCS compatible.  Because fast clears are currently
----------------------------^^^
Should say "CCS_E".

> disabled on SKL, we can plumb the helper all the way through here, and not
> actually have anything break.
> 
> The logic in the table works a bit differently than the other columns in the
> table and therefore deserves a small mention. For most other features, the GEN
> which began implementing it is set, and it is assumed future gens also support
> this. For this feature, GEN9 actually eliminates support for certain formats. We
> could use this column to determine support for the similar feature on older
> generation hardware. Aside from that being an error prone task which is
> unrelated to enabling this on GEN9, it becomes somewhat tricky to implement
> because of the fact that surface format support diminishes. You'd probably want
> another column to cleanly implement it.

Does the above paragraph still apply to the table's ccs_e column?
I understand your patch series, the ccs_e column behaves identically to
all other columns:

	feature_is_supported == (10 * gen >= table[format].feature)

The patch's diff looks good to me. My only remaining questions/issues
with the patch are the ones stated in this message.


More information about the mesa-dev mailing list