[igt-dev] [PATCH] tests/kms_prime: Filter out devices that can't import buffers.
Christian König
christian.koenig at amd.com
Tue Jun 15 14:55:40 UTC 2021
Am 15.06.21 um 16:49 schrieb Mark Yacoub:
> On Tue, Jun 15, 2021 at 9:43 AM Christian König
> <christian.koenig at 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&data=04%7C01%7Cchristian.koenig%40amd.com%7Cbdc7b671688747b5b28808d9300ccce7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637593653819504079%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Nwdst2UNrAZXViQoXowcxzJxHGz0ktuX3OIFLESoEoo%3D&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 at 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
>>>>
More information about the igt-dev
mailing list