From: Karolina Stolarek <karolina.stolarek@intel.com>
To: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t 1/2] lib/intel_blt: Release an offset in the allocator on buffer destroy
Date: Fri, 6 Oct 2023 10:02:14 +0200 [thread overview]
Message-ID: <126ae5fa-3bcc-808a-9c5a-2acedf177a58@intel.com> (raw)
In-Reply-To: <20231004163729.464980-2-zbigniew.kempczynski@intel.com>
On 4.10.2023 18:37, Zbigniew Kempczyński wrote:
> Blitter library code requires allocator handle only at the execution
> time. That means blt_copy_object structure is allocator agnostic and
> offsets are taken for block-copy or fast-copy just before operation.
> Operations on bo's like close/create requires to reflect on the
> allocator state, otherwise allocator will contain outdated
> offsets + sizes leading to fail on allocator operations or the exec.
>
> Helpers blt_create_object() and blt_destroy_object() are unaware
> of allocator so if in the meantime object was used in block-copy or
> fast-copy it has assigned offset in the allocator.
Something is slightly off with that sentence. It gets assigned the same
offset as the "old" object, right?
But the solution itself looks good to me:
Reviewed-by: Karolina Stolarek <karolina.stolarek@intel.com>
Thanks,
Karolina
> Destroying object
> with blt_destroy_object() doesn't release this offset what might
> cause failures described above.
>
> There're two possibilities how to solve this - to couple blitter
> library with allocator or provide additional helpers which will
> release offset in the allocator on destroy path. Latter one is
> easier to provide so this is a subject of this change.
>
> Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
> Cc: Karolina Stolarek <karolina.stolarek@intel.com>
> ---
> lib/intel_blt.c | 15 ++++++++++++++-
> lib/intel_blt.h | 2 ++
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/lib/intel_blt.c b/lib/intel_blt.c
> index b55fa9b529..d2ea88d95f 100644
> --- a/lib/intel_blt.c
> +++ b/lib/intel_blt.c
> @@ -1470,15 +1470,28 @@ blt_create_object(const struct blt_copy_data *blt, uint32_t region,
> return obj;
> }
>
> -void blt_destroy_object(int fd, struct blt_copy_object *obj)
> +static void __blt_destroy_object(int fd, uint64_t ahnd, struct blt_copy_object *obj)
> {
> if (obj->ptr)
> munmap(obj->ptr, obj->size);
>
> gem_close(fd, obj->handle);
> + if (ahnd)
> + intel_allocator_free(ahnd, obj->handle);
> free(obj);
> }
>
> +void blt_destroy_object(int fd, struct blt_copy_object *obj)
> +{
> + __blt_destroy_object(fd, 0, obj);
> +}
> +
> +void blt_destroy_object_and_alloc_free(int fd, uint64_t ahnd,
> + struct blt_copy_object *obj)
> +{
> + __blt_destroy_object(fd, ahnd, obj);
> +}
> +
> void blt_set_object(struct blt_copy_object *obj,
> uint32_t handle, uint64_t size, uint32_t region,
> uint8_t mocs, enum blt_tiling_type tiling,
> diff --git a/lib/intel_blt.h b/lib/intel_blt.h
> index d9c8883c7d..a9ddb99647 100644
> --- a/lib/intel_blt.h
> +++ b/lib/intel_blt.h
> @@ -245,6 +245,8 @@ blt_create_object(const struct blt_copy_data *blt, uint32_t region,
> enum blt_compression_type compression_type,
> bool create_mapping);
> void blt_destroy_object(int fd, struct blt_copy_object *obj);
> +void blt_destroy_object_and_alloc_free(int fd, uint64_t ahnd,
> + struct blt_copy_object *obj);
> void blt_set_object(struct blt_copy_object *obj,
> uint32_t handle, uint64_t size, uint32_t region,
> uint8_t mocs, enum blt_tiling_type tiling,
next prev parent reply other threads:[~2023-10-06 8:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-04 16:37 [igt-dev] [PATCH i-g-t 0/2] Add flat-ccs tests Zbigniew Kempczyński
2023-10-04 16:37 ` [igt-dev] [PATCH i-g-t 1/2] lib/intel_blt: Release an offset in the allocator on buffer destroy Zbigniew Kempczyński
2023-10-06 8:02 ` Karolina Stolarek [this message]
2023-10-04 16:37 ` [igt-dev] [PATCH i-g-t 2/2] tests/xe_evict: Add flat-ccs eviction tests Zbigniew Kempczyński
2023-10-04 19:25 ` [igt-dev] ✓ Fi.CI.BAT: success for Add flat-ccs tests Patchwork
2023-10-04 21:07 ` [igt-dev] ✓ CI.xeBAT: " Patchwork
2023-10-05 5:13 ` [igt-dev] ✗ Fi.CI.IGT: failure " 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=126ae5fa-3bcc-808a-9c5a-2acedf177a58@intel.com \
--to=karolina.stolarek@intel.com \
--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