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!
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev