On Wed, 21 Mar 2012 13:41:21 -0700, Jesse Barnes <[email protected]> wrote: > On Tue, 20 Mar 2012 13:13:47 -0700 > Jesse Barnes <[email protected]> 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?
pgpEn7v9q3d4g.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
