Re: [RFC 00/15] Selectable platform support

From: Jani Nikula <jani.nikula@linux.intel.com>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Intel-gfx@lists.freedesktop.org,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Subject: Re: [RFC 00/15] Selectable platform support
Date: Fri, 09 Feb 2018 13:49:16 +0200	[thread overview]
Message-ID: <878tc28jsz.fsf@intel.com> (raw)
In-Reply-To: <151810246741.12980.8493340966397698584@jlahtine-desk.ger.corp.intel.com>

On Thu, 08 Feb 2018, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> Quoting Tvrtko Ursulin (2018-02-08 16:06:41)
>> 
>> On 08/02/2018 13:26, Chris Wilson wrote:
>> > Quoting Tvrtko Ursulin (2018-02-08 13:05:51)
>> >> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> >>
>> >> For Joonas basically. :)
>> >>
>> >> Rough goal - add Kconfig options to turn off supported platforms
>> >> and count on compiler DCE to make the driver smaller.
>> >>
>> >> Tested as so much that it boots and renders on Skylake with all
>> >> platforms/gens older than Gen8 turned off.
>> >>
>> >>     text    data     bss     dec     hex filename
>> >> 1502847   54223    2888 1559958  17cd96 i915.ko.original
>> >> 1375647   51939    2888 1430474  15d3ca i915.ko.gen8+
>> >>
>> >> So only ~124kiB saving. Or ~8.5%. Perhaps once GCC LTO support
>> >> lands it would be better than this?
>> > 
>> > Did you get to the point where the compiler was complaining about
>> > unused functions?
>> 
>> No, but on a random check it seems that it is removing some. For
>> instance i965_emit_bb_start and i830_emit_bb_start are not in my
>> build.
>> 
>> Doesn't mean I haven't made some other mistake which is preventing
>> more savings.
>> 
>> >> Starts with smaller patches to show the idea step by step on Gen2,
>> >> then proceeds in larger chunks, to finish with some invasive
>> >> Coccinelle works to enable the last few kilo-bytes of savings.
>> > 
>> > So, if we want to support this, how do we test it?
>> > 
>> > Do a per-platform build and check modinfo for pci ids?
>> > 
>> > Limit the CI builds to be per-platform and check they work?
>> 
>> Extensively. :) Which will probably be a problem. PCI ids is not
>> enough, I think it would actually need functional testing so a growth
>> of number of builds we would need to test.
>
> My original suggestion was to be able to "pre-select the PCI ID" and
> let the compiler do the magic with LTO to get rid of the dead
> code. You would test by comparing the "include all" and "one PCI ID"
> kernel operation on same system. I'm assuming that the feature would
> be a useful non-default to opt-in to similarly to a "targeted" initrd.

So I can imagine someone shipping a specific product with a specific
platform (or even PCI ID) could use this. Beyond that, who would use
this? Some rare enthusiasts?

Is there any way a general purpose distro could use it? I guess only by
building several drivers with different options (and names) that would
have different PCI ID matches.

The increased testing requirements are not to be taken lightly. We need
to have pretty good rationale for the CI team before just dropping this
on them to test.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx