public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: igt-dev@lists.freedesktop.org,
	Vanshidhar Konda <vanshidhar.r.konda@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t 1/8] lib/igt_draw: Refactor get_tiling calls
Date: Mon, 10 Feb 2020 13:37:54 +0200	[thread overview]
Message-ID: <20200210113754.GA31846@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <87y2tcwvt5.wl-ashutosh.dixit@intel.com>

On Sat, Feb 08, 2020 at 02:36:38PM -0800, Dixit, Ashutosh wrote:
> On Fri, 07 Feb 2020 11:15:17 -0800, Imre Deak wrote:
> >  void igt_draw_rect(int fd, drm_intel_bufmgr *bufmgr, drm_intel_context *context,
> >		   uint32_t buf_handle, uint32_t buf_size, uint32_t buf_stride,
> > -		   enum igt_draw_method method, int rect_x, int rect_y,
> > -		   int rect_w, int rect_h, uint32_t color, int bpp)
> > +		   uint32_t tiling, enum igt_draw_method method,
> > +		   int rect_x, int rect_y, int rect_w, int rect_h,
> > +		   uint32_t color, int bpp)
> >  {
> > +	uint32_t buf_tiling, swizzle;
> > +
> >	struct cmd_data cmd_data = {
> >		.bufmgr = bufmgr,
> >		.context = context,
> > @@ -667,24 +660,32 @@ void igt_draw_rect(int fd, drm_intel_bufmgr *bufmgr, drm_intel_context *context,
> >		.h = rect_h,
> >	};
> >
> > +	swizzle = I915_BIT_6_SWIZZLE_NONE;
> > +	if (tiling != I915_TILING_NONE && gem_available_fences(fd)) {
> > +		gem_get_tiling(fd, buf_handle, &buf_tiling, &swizzle);
> > +		igt_assert(tiling == buf_tiling);
> > +	}
> 
> Probably a nit, but looks a little strange to call gem_get_tiling() to get
> the swizzle and then doing an assert.

gem_get_tiling() is the way to get the swizzling for a buffer. The
assert only makes sure that the caller's and kernel's idea of the tiling
matches. While the callers will pick the tiling (when creating the
buffer), the swizzling is fixed based on this tiling and platform.

> Instead, since igt_draw_rect() has only two callers how about moving
> the gem_get_tiling() call into the callers and passing both tiling and
> swizzle into igt_draw_rect()?

Why?

> 
> > diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
> > index 2c765c34..9c2c3a5d 100644
> > --- a/tests/kms_frontbuffer_tracking.c
> > +++ b/tests/kms_frontbuffer_tracking.c
> > @@ -291,6 +291,7 @@ struct {
> >	int height;
> >	uint32_t color;
> >	int bpp;
> > +	uint32_t tiling;
> 
> Should not need this if we follow the suggestion above.

This contains the tiling of the buffer as now we won't have a way to
retrieve the same from the kernel.

--Imre
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2020-02-10 11:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 19:15 [igt-dev] [PATCH i-g-t 1/8] lib/igt_draw: Refactor get_tiling calls Imre Deak
2020-02-07 19:15 ` [igt-dev] [PATCH i-g-t 2/8] tests/kms_frontbuffer_tracking: Skip set tiling calls if not supported Imre Deak
2020-02-08 22:36   ` Dixit, Ashutosh
2020-02-10 22:32   ` Matt Roper
2020-02-07 19:15 ` [igt-dev] [PATCH i-g-t 3/8] tests/kms_available_modes_crc: Don't set tiling for framebuffer Imre Deak
2020-02-10 22:47   ` Matt Roper
2020-02-07 19:15 ` [igt-dev] [PATCH i-g-t 4/8] tests/kms_draw_crc: Skip GTT subtests on platforms w/o aperture Imre Deak
2020-02-10 22:51   ` Matt Roper
2020-02-07 19:15 ` [igt-dev] [PATCH i-g-t 5/8] tests/kms_draw_crc: Fix generating reference CRCs " Imre Deak
2020-02-10 22:58   ` Matt Roper
2020-02-11  0:38     ` Imre Deak
2020-02-07 19:15 ` [igt-dev] [PATCH i-g-t 6/8] tests/kms_frontbuffer_tracking: Skip GTT subtests " Imre Deak
2020-02-10 23:19   ` Matt Roper
2020-02-11  1:18     ` Imre Deak
2020-02-07 19:15 ` [igt-dev] [PATCH i-g-t 7/8] lib/igt_draw: Fix igt_draw_fill_fb() " Imre Deak
2020-02-10 23:22   ` Matt Roper
2020-02-07 19:15 ` [igt-dev] [PATCH i-g-t 8/8] lib/igt_fb: Make sure tiled YUV framebuffers are fully cleared Imre Deak
2020-02-10 23:34   ` Matt Roper
2020-02-11  1:26     ` Imre Deak
2020-02-07 19:51 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/8] lib/igt_draw: Refactor get_tiling calls Patchwork
2020-02-08 22:36 ` [igt-dev] [PATCH i-g-t 1/8] " Dixit, Ashutosh
2020-02-10 11:37   ` Imre Deak [this message]
2020-02-11 19:10     ` Dixit, Ashutosh
2020-02-11 19:18       ` Imre Deak
2020-02-12  4:17         ` Dixit, Ashutosh
2020-02-10 22:13 ` Matt Roper
2020-02-11  0:37   ` Imre Deak
2020-02-11  9:30 ` [igt-dev] ✗ Fi.CI.IGT: failure for series starting with [i-g-t,1/8] " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200210113754.GA31846@ideak-desk.fi.intel.com \
    --to=imre.deak@intel.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=vanshidhar.r.konda@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox