All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ruhl, Michael J" <michael.j.ruhl@intel.com>
To: "C, Ramalingam" <ramalingam.c@intel.com>,
	igt-dev <igt-dev@lists.freedesktop.org>
Cc: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t v3] tests/kms_prime: Create the exporting BO with smem
Date: Fri, 17 Sep 2021 13:30:07 +0000	[thread overview]
Message-ID: <6263eddc5a464e609c46f90f3a9f8a13@intel.com> (raw)
In-Reply-To: <079a6cbef7c746c1ae281ba4ad4cef86@intel.com>

>-----Original Message-----
>From: Ruhl, Michael J
>Sent: Friday, September 17, 2021 9:04 AM
>To: C, Ramalingam <ramalingam.c@intel.com>; igt-dev <igt-
>dev@lists.freedesktop.org>
>Cc: Dixit, Ashutosh <ashutosh.dixit@intel.com>
>Subject: RE: [PATCH i-g-t v3] tests/kms_prime: Create the exporting BO with
>smem
>
>
>>-----Original Message-----
>>From: C, Ramalingam <ramalingam.c@intel.com>
>>Sent: Thursday, September 16, 2021 9:33 AM
>>To: igt-dev <igt-dev@lists.freedesktop.org>
>>Cc: Ruhl, Michael J <michael.j.ruhl@intel.com>; Dixit, Ashutosh
>><ashutosh.dixit@intel.com>
>>Subject: [PATCH i-g-t v3] tests/kms_prime: Create the exporting BO with
>>smem
>>
>>On i915, to avail the dmabuf, the sharing object needs to migratable
>>into smem. So if the shared object is lmem, then it needs to have the
>>smem as second placement option.
>
>Some minor word smithing:
>
>"the shared object needs to be migratable"
>
>"needs to have smem as"
>
>>Currently kms_prime sharing the dumb buffer between the devices.
>
>s/sharing/shares/
>
>>But dumb buffer can't have the placements and resides at lmem for the
>>dgfx. Hence to meet the i915 expectation for dgfx, we create the BO
>>using the gem_create with smem as second placement option.
>
>Would it make more sense to just have i915_gem_dumb_create() create
>the object with both placements?
>
>So then for the use case, it will "just work"?
>
>This patch looks reasonable, but the change in dumb buffer usage is a
>concern because we will need to change all usages in order to cover this
>new feature/ability.

This has apparently already been discussed, and this patch is the result.

So, with the above fixes:

Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>

m

>Mike
>
>>v2: Used gem_mmap__device_coherent for mmaped ptr (Ashutosh)
>>v3: dumb buffer ioctls are used for non i915 drivers
>>
>>Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
>>Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
>>Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
>>---
>> tests/kms_prime.c | 33 +++++++++++++++++++++------------
>> 1 file changed, 21 insertions(+), 12 deletions(-)
>>
>>diff --git a/tests/kms_prime.c b/tests/kms_prime.c
>>index 2e20c58bc16e..5cdb559778b3 100644
>>--- a/tests/kms_prime.c
>>+++ b/tests/kms_prime.c
>>@@ -100,18 +100,27 @@ static void prepare_scratch(int exporter_fd, struct
>>dumb_bo *scratch,
>> 	scratch->height = mode->vdisplay;
>> 	scratch->bpp = 32;
>>
>>-	scratch->handle = kmstest_dumb_create(exporter_fd,
>>-			ALIGN(scratch->width, 256),
>>-			scratch->height,
>>-			scratch->bpp,
>>-			&scratch->pitch,
>>-			&scratch->size);
>>-
>>-
>>-	ptr = kmstest_dumb_map_buffer(exporter_fd,
>>-				      scratch->handle,
>>-				      scratch->size,
>>-				      PROT_WRITE);
>>+	if (!is_i915_device(exporter_fd)) {
>>+		scratch->handle = kmstest_dumb_create(exporter_fd,
>>+						      ALIGN(scratch->width,
>>256),
>>+						      scratch->height, scratch-
>>>bpp,
>>+						      &scratch->pitch, &scratch-
>>>size);
>>+
>>+		ptr = kmstest_dumb_map_buffer(exporter_fd, scratch-
>>>handle,
>>+					      scratch->size, PROT_WRITE);
>>+	} else {
>>+		igt_calc_fb_size(exporter_fd, mode->hdisplay, mode-
>>>vdisplay, DRM_FORMAT_XRGB8888,
>>+				 DRM_FORMAT_MOD_NONE, &scratch->size,
>>&scratch->pitch);
>>+		if (gem_has_lmem(exporter_fd))
>>+			scratch->handle =
>>gem_create_in_memory_regions(exporter_fd, scratch->size,
>>+
>>REGION_LMEM(0), REGION_SMEM);
>>+		else
>>+			scratch->handle =
>>gem_create_in_memory_regions(exporter_fd, scratch->size,
>>+
>>REGION_SMEM);
>>+
>>+		ptr = gem_mmap__device_coherent(exporter_fd, scratch-
>>>handle, 0, scratch->size,
>>+						PROT_WRITE | PROT_READ);
>>+	}
>>
>> 	for (size_t idx = 0; idx < scratch->size / sizeof(*ptr); ++idx)
>> 		ptr[idx] = color;
>>--
>>2.20.1

      reply	other threads:[~2021-09-17 13:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16 13:32 [igt-dev] [PATCH i-g-t v3] tests/kms_prime: Create the exporting BO with smem Ramalingam C
2021-09-16 15:48 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2021-09-16 18:11 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2021-09-17 13:03 ` [igt-dev] [PATCH i-g-t v3] " Ruhl, Michael J
2021-09-17 13:30   ` Ruhl, Michael J [this message]

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=6263eddc5a464e609c46f90f3a9f8a13@intel.com \
    --to=michael.j.ruhl@intel.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=ramalingam.c@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.