[Intel-gfx] [PATCH 1/8] drm/i915: Implement .get_format_info() hook for CCS

[Daniel Stone]

Hi,

On 7 June 2017 at 17:28, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> On Wed, Jun 07, 2017 at 04:48:06PM +0100, Daniel Stone wrote:
>> It does, and I have correct CCS output (tested by displaying frames
>> either as Y_CCS, or as plain Y; correct display with the former and
>> visibly showing an incomplete primary surface for the latter) with the
>> last set of Mesa patches I submitted, using Weston. It's been that way
>> for a couple of months (?) now, since the stride handling was fixed
>> too.
>
> I still see stuff like
>
> intel_setup_image_from_mipmap_tree()
> -> intel_miptree_get_tile_offsets()
>    -> intel_miptree_get_aligned_offset()
>
> which doesn't return a linear offset.

That's only used when creating a DRIimage from a GL texture.

The (slightly simplified) allocation path for GBM creating a buffer
and then extracting the information to pass to AddFB2 is (assuming an
aux buffer is present):
gbm_surface_create_with_modifiers()
  -> intel_create_image_with_modifiers (as
DRIimageExtension->createImageWithModifiers)
    -> image->aux_offset = ALIGN(height, tile_height) * image->pitch;

gbm_surface_lock_front_buffer()
  -> return gbm_bo wrapping DRIImage created above

gbm_bo_get_stride_for_plane()
  -> gbm_dri_bo_get_stride()
    -> intel_query_image (via DRIimageExtension->queryImage)
      -> return image->pitch

gbm_bo_get_offset()
  -> gbm_dri_bo_get_offset()
    -> plane==0: (intel_from_planar via DRIimageExtension->fromPlanar
returns false)
      -> intel_query_image
        -> return image->offset (hardcoded to 0 at alloc)
    -> else plane==1: (intel_from_planar returns new DRIimage)
      -> intel_query_image
        -> return image->offset (set to image->aux_offset inside
intel_create_image_with_modifiers)

For 3200x1800 with XRGB8888 + CCS, running the actual Mesa patchset
submitted under Weston on the patchset I sent in May which has no
difference in offset handling to this one, this callchain results in:
  offset[0] == 0
  stride[0] == 12800 (== 3200 * 4)
  offset[1] == 23040000 (== 12800 * 1800)

(I hadn't logged what stride[1] was and don't have the kernel to run
it right this second, but given I get a very sparse 'dotty' display
when I just pass the primary buffer as Y_TILED with no aux buffer, and
a completely correct display when I pass it as Y_CCS with the aux
buffer, I'm pretty confident the stride is correct.)

Either I'm seriously hallucinating or it is very definitely linear.
The comments above intel_miptree_get_aligned_offset ('Compute the
offset (in bytes) from the start of the BO to the given x and y
coordinate.') also suggest it's working in linear space. Manually
feeding x==256,y==0 into intel_miptree_get_aligned_offset gives me an
offset of 32768, i.e. two 128x32 tiles, so again that seems right to
me.

Cheers,
Daniel