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

[Ville Syrjälä]

On Wed, Jun 07, 2017 at 04:48:06PM +0100, Daniel Stone wrote:
> Hi,
> 
> On 7 June 2017 at 16:33, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> > On Wed, Jun 07, 2017 at 03:24:58PM +0100, Daniel Stone wrote:
> >> On 7 June 2017 at 13:53, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> >> > Anyways, I'll have to revisit the the offsets[] thing because people
> >> > didn't like my original linear offset idea, and it doesn't match what
> >> > userspace already does.
> >>
> >> I'm still really confused about this. Your patches implement a linear
> >> byte offset. The last time it came up on IRC, all four of myself, Ben,
> >> Jason, and you, agreed that linear byte offsets were the only thing
> >> which made sense. The Mesa patchset that's been sent out a couple of
> >> times and is now in Jason's hands use linear offsets. If everything
> >> (kernel, Mesa) uses linear offsets, and everyone (the four of us in
> >> the discussion) wants linear offsets - why revisit?
> >
> > Mesa doesn't use linear offsets. Or at least it didn't when I last
> > looked.
> 
> 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.

-- 
Ville Syrjälä
Intel OTC