[igt-dev] [PATCH] RFC: Make igts for cross-driver stuff mandatory?
Eric Anholt
eric at anholt.net
Thu Oct 25 16:35:50 UTC 2018
Sean Paul <sean at poorly.run> writes:
> On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> This is just to collect feedback on this idea, and see whether the
>> overall dri-devel community stands on all this. I think the past few
>> cross-vendor uapi extensions all came with igts attached, and
>> personally I think there's lots of value in having them: A
>> cross-vendor interface isn't useful if every driver implements it
>> slightly differently.
>>
>> I think there's 2 questions here:
>>
>> - Do we want to make such testcases mandatory?
>>
>
> Yes, more testing == better code.
>
>
>> - If yes, are we there yet, or is there something crucially missing
>> still?
>
> In my experience, no. Last week while trying to replicate an intel-gfx CI
> failure, I tried compiling igt for one of my (intel) chromebooks. It seems like
> cross-compilation (or, in my case, just specifying
> prefix/ld_library_path/sbin_path) is broken on igt. If we want to impose
> restrictions across the entire subsystem, we need to make sure that everyone can
> build and deploy igt easily.
>
> I managed to hack around everything and get it working, but I still haven't
> tried switching out the toolchain. Once we have some GitLab CI to validate
> cross-compilation, then we can consider making IGT mandatory.
>
> It's possible that I'm just a meson n00b and didn't use the right incantation,
> so maybe it already works, but then we need better documentation.
>
> I've pasted my horrible hacks below, I also didn't have libunwind, so removed
> its usage.
I've also had to cut out libunwind for cross-compiling on many
occasions. Worst library.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20181025/e488ef9d/attachment.sig>
More information about the amd-gfx
mailing list