Hi,
On 7 June 2017 at 17:28, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
