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@xxxxxxxxx> > >> > >> 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. Regards, Joonas > > Regards, > > Tvrtko > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
