[Mesa-dev] [PATCH 25/53] i965/drm: Drop intel_chipset.h in favor of using gen_device_info.

[Kenneth Graunke]

On Wednesday, April 5, 2017 2:50:01 PM PDT Chris Wilson wrote:
> On Wed, Apr 05, 2017 at 02:36:38PM -0700, Kenneth Graunke wrote:
> > On Wednesday, April 5, 2017 3:33:39 AM PDT Chris Wilson wrote:
> > > On Tue, Apr 04, 2017 at 05:10:15PM -0700, Kenneth Graunke wrote:
> > > > This moves the PCI ID detection to intel_screen.c and makes
> > > > drm_bacon_bufmgr_gem_init() take a devinfo pointer.
> > > > 
> > > > We also drop the HAS_LLC query stuff - devinfo has that info already,
> > > > without kernel queries, and it makes no sense to have two has_llc flags
> > > > set by different mechanisms.
> > > 
> > > Just remember the kernel query actually tells you something more than
> > > what you know from just querying pci-id. As you replace the buffer cache
> > > management, that will become more obvious (and directly controllable).
> > 
> > It does?  I must be missing something - it sure looks like the kernel
> > sets dev_priv->info.has_llc based on the PCI ID, and this getparam
> > just returns that that value.
> > 
> > I'd be happy to set our devinfo->has_llc based on the kernel query,
> > if it's actually useful...but it looks kinda pointless...
> 
> What I was hinting at was that being on a llc architecture is one thing,
> and knowing the actual coherency of the buffer is another. Mostly just
> another warning about handling scanouts carefully, and it is something
> should definitely be taken into consideration when importing a buffer as
> the third party may be using the buffer incoherently even if llc. (And
> for kernels older than v3.6 you would find the buffers were by default
> being treated as incoherent by the kernel so just assuming they were llc
> could cause excess clflushing. The same still applies, just by default
> everything is now treated as coherent on llc.)
> -Chris

Ah, that makes sense.  I agree - I liked how you were storing the
per-BO coherency/caching mode and checking it on import.  We should
definitely move that direction.

Thanks for clarifying!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170405/ae31929f/attachment.sig>