Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Cc: igt-dev@lists.freedesktop.org, Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [igt-dev] [PATCH i-g-t v3 12/13] tests/perf: remove libdrm dependency for rendercopy
Date: Fri, 24 Jul 2020 14:48:10 +0300	[thread overview]
Message-ID: <49622d68-636a-892f-8d6d-1a75ebaa4944@intel.com> (raw)
In-Reply-To: <20200724113726.GA3775@zkempczy-mobl2>

On 24/07/2020 14:37, Zbigniew Kempczyński wrote:
> On Fri, Jul 24, 2020 at 02:10:51PM +0300, Lionel Landwerlin wrote:
>> On 24/07/2020 12:56, Zbigniew Kempczyński wrote:
>>> Rendercopy now uses no-drm version so all users has to
>>> migrate to new interface.
>>>
>>> Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
>>> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>>> Cc: Dominik Grzegorzek <dominik.grzegorzek@intel.com>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>
>> Thanks a bunch for this.
>>
>> I have only a single question below, otherwise it looks great.
>>
>> -Lionel
>>
>>
>>> ---
>>>    tests/i915/perf.c | 663 ++++++++++++++++++++--------------------------
>>>    1 file changed, 281 insertions(+), 382 deletions(-)
>>>
>>> diff --git a/tests/i915/perf.c b/tests/i915/perf.c
>>> index 92edc9f1..fd2b4073 100644
>>> --- a/tests/i915/perf.c
>>> +++ b/tests/i915/perf.c
>>> @@ -497,64 +497,42 @@ oa_report_get_ctx_id(uint32_t *report)
>>>    }
>>>    static void
>>> -scratch_buf_memset(drm_intel_bo *bo, int width, int height, uint32_t color)
>>> +scratch_buf_memset(struct intel_buf *buf, int width, int height, uint32_t color)
>>>    {
>>> -	int ret;
>>> -
>>> -	ret = drm_intel_bo_map(bo, true /* writable */);
>>> -	igt_assert_eq(ret, 0);
>>> +	intel_buf_cpu_map(buf, true);
>>>    	for (int i = 0; i < width * height; i++)
>>> -		((uint32_t *)bo->virtual)[i] = color;
>>> +		buf->ptr[i] = color;
>>> -	drm_intel_bo_unmap(bo);
>>> +	intel_buf_unmap(buf);
>>>    }
>>>    static void
>>> -scratch_buf_init(drm_intel_bufmgr *bufmgr,
>>> -		 struct igt_buf *buf,
>>> +scratch_buf_init(struct buf_ops *bops,
>>> +		 struct intel_buf *buf,
>>>    		 int width, int height,
>>>    		 uint32_t color)
>>>    {
>>> -	size_t stride = width * 4;
>>> -	size_t size = stride * height;
>>> -	drm_intel_bo *bo = drm_intel_bo_alloc(bufmgr, "", size, 4096);
>>> -
>>> -	scratch_buf_memset(bo, width, height, color);
>>> -
>>> -	memset(buf, 0, sizeof(*buf));
>>> -
>>> -	buf->bo = bo;
>>> -	buf->surface[0].stride = stride;
>>> -	buf->tiling = I915_TILING_NONE;
>>> -	buf->surface[0].size = size;
>>> -	buf->bpp = 32;
>>> +	intel_buf_init(bops, buf, width, height, 32, 0,
>>> +		       I915_TILING_NONE, I915_COMPRESSION_NONE);
>>> +	scratch_buf_memset(buf, width, height, color);
>>>    }
>>>    static void
>>> -emit_report_perf_count(struct intel_batchbuffer *batch,
>>> -		       drm_intel_bo *dst_bo,
>>> +emit_report_perf_count(struct intel_bb *ibb,
>>> +		       struct intel_buf *dst,
>>>    		       int dst_offset,
>>>    		       uint32_t report_id)
>>>    {
>>> -	if (IS_HASWELL(devid)) {
>>> -		BEGIN_BATCH(3, 1);
>>> -		OUT_BATCH(GEN6_MI_REPORT_PERF_COUNT);
>>> -		OUT_RELOC(dst_bo, I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION,
>>> -			  dst_offset);
>>> -		OUT_BATCH(report_id);
>>> -		ADVANCE_BATCH();
>>> -	} else {
>>> -		/* XXX: NB: n dwords arg is actually magic since it internally
>>> -		 * automatically accounts for larger addresses on gen >= 8...
>>> -		 */
>>> -		BEGIN_BATCH(3, 1);
>>> -		OUT_BATCH(GEN8_MI_REPORT_PERF_COUNT);
>>> -		OUT_RELOC(dst_bo, I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION,
>>> -			  dst_offset);
>>> -		OUT_BATCH(report_id);
>>> -		ADVANCE_BATCH();
>>> -	}
>>> +	if (IS_HASWELL(devid))
>>> +		intel_bb_out(ibb, GEN6_MI_REPORT_PERF_COUNT);
>>> +	else
>>> +		intel_bb_out(ibb, GEN8_MI_REPORT_PERF_COUNT);
>>> +
>>> +	intel_bb_emit_reloc(ibb, dst->handle,
>>> +			    I915_GEM_DOMAIN_INSTRUCTION, I915_GEM_DOMAIN_INSTRUCTION,
>>> +			    dst_offset, dst->addr.offset);
>>> +	intel_bb_out(ibb, report_id);
>>>    }
>>>    static void
>>> @@ -1495,14 +1473,13 @@ enum load {
>>>    static struct load_helper {
>>>    	int devid;
>>> -	drm_intel_bufmgr *bufmgr;
>>> -	drm_intel_context *context;
>>> +	struct buf_ops *bops;
>>>    	uint32_t context_id;
>>> -	struct intel_batchbuffer *batch;
>>> +	struct intel_bb *ibb;
>>>    	enum load load;
>>>    	bool exit;
>>>    	struct igt_helper_process igt_proc;
>>> -	struct igt_buf src, dst;
>>> +	struct intel_buf src, dst;
>>>    } lh = { 0, };
>>>    static void load_helper_signal_handler(int sig)
>>> @@ -1524,6 +1501,14 @@ static void load_helper_set_load(enum load load)
>>>    	kill(lh.igt_proc.pid, SIGUSR2);
>>>    }
>>> +static void set_to_gtt_domain(struct intel_buf *buf, int writing)
>>> +{
>>> +	int i915 = buf_ops_get_fd(buf->bops);
>>> +
>>> +	gem_set_domain(i915, buf->handle, I915_GEM_DOMAIN_GTT,
>>> +		       writing ? I915_GEM_DOMAIN_GTT : 0);
>>> +}
>>
>> Is this what we actually want?
>>
>> Why not use a fence on the intel_bb_sync() ?
> I didn't want to introduce any logic changes so I did exactly
> the same drm_intel_bo_wait_rendering() is doing (setting to GTT domain).
> If your intention is just to wait for completion I can just do
> intel_bb_sync(ibb) to wait on a fence.
>
> --
> Zbigniew

Yeah, the intention was just to not clog the GPU with loads of blits.

Thanks,


-Lionel

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

  reply	other threads:[~2020-07-24 11:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24  9:56 [igt-dev] [PATCH i-g-t v3 00/13] Remove libdrm in rendercopy Zbigniew Kempczyński
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 01/13] lib/intel_bufops: add mapping on cpu / device Zbigniew Kempczyński
2020-07-24 12:18   ` Chris Wilson
2020-07-27  7:24     ` Zbigniew Kempczyński
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 02/13] lib/intel_batchbuffer: add new functions to support rendercopy Zbigniew Kempczyński
2020-07-24 12:25   ` Chris Wilson
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 03/13] tests/gem_caching: adopt to batch flush function cleanup Zbigniew Kempczyński
2020-07-24 12:26   ` Chris Wilson
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 04/13] lib/rendercopy: remove libdrm dependency Zbigniew Kempczyński
2020-07-24 12:29   ` Chris Wilson
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 05/13] tests/api_intel_bb: add render tests Zbigniew Kempczyński
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 06/13] lib/intel_batchbuffer: use canonical addresses for 48bit ppgtt Zbigniew Kempczyński
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 07/13] lib/igt_draw: remove libdrm dependency Zbigniew Kempczyński
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 08/13] lib/igt_fb: Removal of " Zbigniew Kempczyński
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 09/13] tests/gem|kms: remove libdrm dependency (batch 1) Zbigniew Kempczyński
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 10/13] tests/gem|kms: remove libdrm dependency (batch 2) Zbigniew Kempczyński
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 11/13] tools/intel_residency: adopt intel_residency to use bufops Zbigniew Kempczyński
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 12/13] tests/perf: remove libdrm dependency for rendercopy Zbigniew Kempczyński
2020-07-24 11:10   ` Lionel Landwerlin
2020-07-24 11:37     ` Zbigniew Kempczyński
2020-07-24 11:48       ` Lionel Landwerlin [this message]
2020-07-24  9:56 ` [igt-dev] [PATCH i-g-t v3 13/13] HAX: run rendercopy tests Zbigniew Kempczyński
2020-07-24 10:46 ` [igt-dev] ✗ Fi.CI.BAT: failure for Remove libdrm in rendercopy (rev3) 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=49622d68-636a-892f-8d6d-1a75ebaa4944@intel.com \
    --to=lionel.g.landwerlin@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=zbigniew.kempczynski@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