All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kristian Høgsberg" <krh@bitplanet.net>
To: Kenneth Graunke <kenneth@whitecape.org>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 00/16] Move chipset specific stuff to struct intel_chipset
Date: Wed, 8 Jun 2011 20:36:46 +0200	[thread overview]
Message-ID: <BANLkTi=sgk4k=myfmmCk=HzBtky_8KRhTg@mail.gmail.com> (raw)
In-Reply-To: <4DEF622D.90001@whitecape.org>

2011/6/8 Kenneth Graunke <kenneth@whitecape.org>:
> On 06/07/2011 12:34 PM, Kristian Høgsberg wrote:
>>
>> Hi,
>>
>> Here's a handful of patches that try to replace most of our chipset
>> feature checking with data in a new struct intel_chipset.  It uses the
>> new PCI ID list infrastructure and eliminates all IS_FOO macros in
>> favor of a per-family chipset info struct.  Actually, I was surprised
>> how much in the driver is really just a gen check, but there are a few
>> cases where we have to check a certain feature, as well as all the
>> gen4+ urb and thread limits (includes the recent fix for swapped VS
>> entry counts).
>>
>> The series compiles and passes casual testing for me, but I've not run
>> piglit on it yet.
>>
>> Kristian
>
> This patchset is fantastic.  Way better than what I'd been doing.  I'm
> tidying it up a bit and working on a bunch of follow-on cleanups...I'll send
> out a proposed replacement series tomorrow.

It was a Tuesday morning distraction for me, and now I'm in Denmark
for a few days vacation.  If you want to take over the patch set, I'd
be very happy :)  One thing I was thinking about changing was to just
pull the chipset inteo the chipset_map array and set that in
intelScreen in intel_screen.c, instead including the chipsets again in
the big pci id switch.

> The only concern I have is with the intel_decode changes to use gen.  I like
> the idea, but I'm afraid it may get us into trouble: What if we need G45
> specific decoding?  We'll -certainly- need Gen 7.5 specific dumping (over
> and above Gen7), eventually.
>
> ickle's idea to use gen 70 and 75 would solve that...though, in general I
> agree with Eric in preferring chipset->gen >= 7 and chipset->is_name.

Chris also suggested sharing the chipset structs so maybe we could
just move it all to intel-gpu-tools (and make decode use the chipset
struct perhaps) as the canonical location for these chipset
definitions.  We also have a similar setup in the kernel, but I'm not
sure it's practical to consolidate all that.  I'd rather get this
first step done and then maybe think about further improvements.

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

      reply	other threads:[~2011-06-08 18:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-07 19:34 [PATCH 00/16] Move chipset specific stuff to struct intel_chipset Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 01/16] intel: Use gen number instead of PCI ID in decoder Kristian Høgsberg
2011-06-08  0:52   ` Eric Anholt
2011-06-07 19:34 ` [PATCH 02/16] intel: Use the PCI ID map for determining chipset gen Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 03/16] intel: IS_9XX is just gen >= 3 Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 04/16] intel: Remove unused IS_915 macro Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 05/16] intel: Replace intel_screen::gen with the chipset struct Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 06/16] intel: Add a is_945 bit to chipinfo and use that instead of IS_945 Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 07/16] intel: Remove unused IS_MOBILE and IS_IGD* macros Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 08/16] intel: Replace single use of IS_965 with gen check Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 09/16] intel: Drop unused IS_GEN4 macro Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 10/16] intel: Drop unused IS_GEN5-7 macros Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 11/16] intel: Put urb and thread limits into the chipset struct Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 12/16] intel: Drop unused IS_SNB/IVB_GT1/2 macros Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 13/16] intel: Replace IS_G4X macro with an is_g4x bit in the chipset struct Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 14/16] intel: Add is_855ish for handling 855 and 865 specific lod clamping Kristian Høgsberg
2011-06-07 20:22   ` Chris Wilson
2011-06-08  1:13     ` Eric Anholt
2011-06-07 19:34 ` [PATCH 15/16] intel: Get chipset name from PCI ID list Kristian Høgsberg
2011-06-07 19:34 ` [PATCH 16/16] intel: Remove intel_chipsets.h Kristian Høgsberg
2011-06-08 11:51 ` [PATCH 00/16] Move chipset specific stuff to struct intel_chipset Kenneth Graunke
2011-06-08 18:36   ` Kristian Høgsberg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTi=sgk4k=myfmmCk=HzBtky_8KRhTg@mail.gmail.com' \
    --to=krh@bitplanet.net \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kenneth@whitecape.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.