[Intel-gfx] [PATCH 0/3] Describe chipsets in struct intel_device_info

Owain Ainsworth zerooa at googlemail.com
Wed Dec 16 21:31:17 CET 2009


On Wed, Dec 16, 2009 at 03:16:14PM -0500, Kristian H??gsberg wrote:
> This patch series implements a change in how we detect chipsets and their
> capabilities.  Our IS_* macros are a pretty confusing, twisted maze to figure
> out and they expand to a ton of equality tests (try counting how many
> comparisons I915_HAS_FBC() expands to and how many of them overlap).
> 
> These patches introduce a struct intel_device_info, that has a bitfield
> that describe which familiy (i8xx, i9xx etc) the chipset belongs to and
> which capabilities is has (fbc, needs_cursor_physical etc).  We map the
> PCI ID of a chipset to one of these structs through the pci_device_id table
> and make it available through dev_priv->info.
> 
> It's a lot less code than what I thought it would be and the collection of 
> struct intel_device_info structs provide a nice catalog of the intel
> chipsets and their capabilities.  It's a nice cleanup on it's own, but
> it turns out that it drops 10% (!!!1) of the stripped driver size.  This
> particular build goes from 216K to 196K.  Not that driver size is a concern,
> and 20K savings in a typical Linux distro isn't gettng anybody excited,
> but that 10% of the generated code came from the IS_* macros is surprising...
> 
> Did a bit of benchmarking using cairo-perf-trace in the hope that eliminating
> some of these big conditionals in the fast path would should up, but I couldn't
> measure any difference.

I did something similar to this a while ago in OpenBSD just because it
cleaned things up.

In short: I like this.

-0-
-- 
UNIX was half a billion (500000000) seconds old on
Tue Nov  5 00:53:20 1985 GMT (measuring since the time(2) epoch).
		-- Andy Tannenbaum



More information about the Intel-gfx mailing list