All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Mark Yacoub <markyacoub@chromium.org>
Cc: Petri Latvala <petri.latvala@intel.com>,
	Anson Jacob <Anson.Jacob@amd.com>,
	igt-dev@lists.freedesktop.org, Sean Paul <seanpaul@chromium.org>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	Mark Yacoub <markyacoub@google.com>
Subject: Re: [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.
Date: Tue, 15 Jun 2021 18:20:23 +0200	[thread overview]
Message-ID: <ae4be25c-c50d-56bb-6699-5ab6210f80bf@amd.com> (raw)
In-Reply-To: <CAJUqKUqVZb-GatjkGXChFYPXrYLCqwCe9Uu0epEASn8SMrzEfw@mail.gmail.com>

The alternative would be to try to create a framebuffer, but don't take 
it as a failure when that fails with the correct return code.

Christian.

Am 15.06.21 um 17:46 schrieb Mark Yacoub:
> @Petri Latvala would it make sense that I go ahead and move this test to i915?
>
> On Tue, Jun 15, 2021 at 10:55 AM Christian König
> <christian.koenig@amd.com> wrote:
>> Am 15.06.21 um 16:49 schrieb Mark Yacoub:
>>> On Tue, Jun 15, 2021 at 9:43 AM Christian König
>>> <christian.koenig@amd.com> wrote:
>>>> Hi guys,
>>>>
>>>> first of all thanks Rodrigo for bringing this to my attention.
>>>>
>>>> Mark, as the DMA-buf maintainer I unfortunately have to reject this patch.
>>> This test is currently running on i915, but fails on amdgpu due to the
>>> check of `import_attach` (this is the commit that introduced the
>>> change: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fagd5f%2Flinux%2F-%2Fcommit%2F1769152ac64b0b07583f696b621624df2ca4c840&amp;data=04%7C01%7Cchristian.koenig%40amd.com%7Cee404ba949124914936808d93014d4ef%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637593688314449415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=qFUa24zx9I1ku%2FuRo4eFEQ4Ky0CbGoeo4VBe1HQMtBc%3D&amp;reserved=0)
>>> What do you recommend instead?
>> Dropping the test from the general KMS tests. Scanning out from imported
>> DMA-bufs is completely vendor specific.
>>
>>>> Direct scanout from imported surfaces is not something supported with
>>>> DMA-buf in general at the moment.
>>> Do you mean the problem is in the test itself?
>> Yes, exactly. Testing that without checking for vendor specific support
>> is utterly nonsense.
>>
>> I'm pretty sure that this is not even fully supported by i915. Daniel
>> Vetter and I chatted about stuff like that a while ago and he mentioned
>> that i915 similar to AMD GPUs have some rather strict hardware
>> requirements which are currently not expressible with DMA-buf.
>>
>> I'm not sure about other drivers, but my guess is that none of them will
>> actually support this.
>>
>> Regards,
>> Christian.
>>
>>>> We do have some support for this between AMD GPUs in A+A laptops, and it
>>>> might work with i915 and some of the drivers used on ARM.
>>>>
>>>> But all of this is completely vendor specific since there are some very
>>>> low level and hardware specific limitations to take account into.
>>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>> Am 15.06.21 um 15:12 schrieb Rodrigo Siqueira:
>>>>> Hi Alex and Christian,
>>>>>
>>>>> This patch is related to prime, but I'm not familiar with this part of
>>>>> our driver. Could you take a look at that?
>>>>>
>>>>> Thanks
>>>>>
>>>>> On 06/14, Mark Yacoub wrote:
>>>>>> Some devices such as amdgpu do not support imported buffers.
>>>>>> Filter out those devices.
>>>>>> Tested on Zork with chromeos-kernel-5_4.
>>>>>>
>>>>>> Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
>>>>>> ---
>>>>>>     tests/kms_prime.c | 14 ++++++++++++--
>>>>>>     1 file changed, 12 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/tests/kms_prime.c b/tests/kms_prime.c
>>>>>> index 8cb2ca2a..480c7eb4 100644
>>>>>> --- a/tests/kms_prime.c
>>>>>> +++ b/tests/kms_prime.c
>>>>>> @@ -249,6 +249,16 @@ static void test_crc(int exporter_fd, int importer_fd)
>>>>>>        igt_display_fini(&display);
>>>>>>     }
>>>>>>
>>>>>> +/* The test attempts to import the buffer object from one device to another.
>>>>>> + * Filter out devices that aren't capable of doing this.
>>>>>> + */
>>>>>> +bool does_device_support_dmabuf_import(int fd) {
>>>>>> +    /* AMDGPU uses VRAM. Any use of the fb will migrate it to VRAM, which is not sensible for
>>>>>> +     * an imported dma-buf.
>>>>>> +     */
>>>>>> +    return !is_amdgpu_device(fd);
>>>>>> +}
>>>>>> +
>>>>>>     igt_main
>>>>>>     {
>>>>>>        igt_fixture
>>>>>> @@ -262,10 +272,10 @@ igt_main
>>>>>>
>>>>>>                /* ANY = anything that is not VGEM */
>>>>>>                first_fd = __drm_open_driver_another(0, DRIVER_ANY | DRIVER_VGEM);
>>>>>> -            igt_require(first_fd >= 0);
>>>>>> +            igt_require(first_fd >= 0 && does_device_support_dmabuf_import(first_fd));
>>>>>>
>>>>>>                second_fd = __drm_open_driver_another(1, DRIVER_ANY | DRIVER_VGEM);
>>>>>> -            igt_require(second_fd >= 0);
>>>>>> +            igt_require(second_fd >= 0 && does_device_support_dmabuf_import(second_fd));
>>>>>>
>>>>>>                if (has_prime_export(first_fd) &&
>>>>>>                    has_prime_import(second_fd))
>>>>>> --
>>>>>> 2.32.0.272.g935e593368-goog
>>>>>>

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

  reply	other threads:[~2021-06-15 16:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14 16:41 [igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers Mark Yacoub
2021-06-14 18:48 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2021-06-15  0:25 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2021-06-15  9:05 ` [igt-dev] [PATCH] " Petri Latvala
2021-06-15 14:46   ` Mark Yacoub
2021-06-15 14:51     ` Christian König
2021-06-15 13:12 ` Rodrigo Siqueira
2021-06-15 13:43   ` Christian König
2021-06-15 14:49     ` Mark Yacoub
2021-06-15 14:55       ` Christian König
2021-06-15 15:46         ` Mark Yacoub
2021-06-15 16:20           ` Christian König [this message]
2021-06-16  7:34             ` Petri Latvala
2021-06-16  8:07               ` Christian König
2021-06-16  8:46                 ` Petri Latvala
2021-06-16  9:07                   ` Christian König
2021-07-02 19:45                     ` Daniel Vetter

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=ae4be25c-c50d-56bb-6699-5ab6210f80bf@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Anson.Jacob@amd.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=markyacoub@chromium.org \
    --cc=markyacoub@google.com \
    --cc=petri.latvala@intel.com \
    --cc=seanpaul@chromium.org \
    /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.