[Intel-gfx] RFC: i915 arch changes to better support new chipsets

[Eric Anholt]

On Wed, 21 Mar 2012 13:41:21 -0700, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Tue, 20 Mar 2012 13:13:47 -0700
> Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> > > > I'm open to suggestions on how to fix i915_reg.h; it's becoming quite a
> > > > beast.  Our goal to be to make it easy to add new definitions while
> > > > also making it easy to not accidentally use old an incorrect
> > > > definitions on a new platform.
> > > 
> > > Close your eyes and just keep on adding gunk. Imo i915_reg.h is pretty
> > > much a write-once file, and cscope can still keep up with the definitions.
> > > So not a pain point for me.
> 
> Oh I forgot the most important thing here: how many f*cking places do
> we need to add PCI IDs??!!
> 
> I'd really really like to see i915_reg.h shared to libdrm and used
> directly by intel-gpu-tools and Mesa if at all possible, whether we
> split it or not.  The IS_* and HAS_* macros should be in there as well,
> with the PCI IDs, then we can just add this stuff in one place...

So, I was thinking about this, but the problem I see is that if we
settle on the PCI ID/gen-number identifier being in libdrm, then some
distro pulls a new libdrm with hsw bits, and ships the rest of old
userland that happily initializes and spits ivb packets at it.

I guess we could have the gen-number stuff be a union of
IS_IVB()/IS_HSW()/IS_VLV(), and switch chipset probing to using each of
those instead of just gen >= 4.

Does this sound sane?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120328/90767e33/attachment.sig>