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
next prev parent 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