Re: RFC: i915 arch changes to better support new chipsets

[Eric Anholt <eric@anholt.net>]

[-- Attachment #1.1: Type: text/plain, Size: 1503 bytes --]

On Wed, 21 Mar 2012 13:41:21 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Tue, 20 Mar 2012 13:13:47 -0700
> Jesse Barnes <jbarnes@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?

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx