On Wed, Jul 10, 2013 at 09:40:18AM -0700, Ben Widawsky wrote: > On Wed, Jul 10, 2013 at 09:59:01AM +0100, Chris Wilson wrote: > > On Tue, Jul 09, 2013 at 07:58:02PM -0700, Ben Widawsky wrote: > > > The algorithm/information was originally written by Chad, though I > > > changed the control flow, and I think his original code had a couple of > > > bugs, though I didn't look very hard before rewriting. That could have > > > also been different interpretations of the spec. > > > > Just a cpuid query that can already be done more simply from userspace > > (i.e. with no syscalls)? I was expecting a lot more magic. > > -Chris > > > > -- > > Chris Wilson, Intel Open Source Technology Centre > > Chad wrote this originally for mesa. And yes, it's doable from > userspace. Chatting with Daniel, we thought maybe other GPU clients > might want this info, and so a central place to put the code would be > nice, in case there are quirks or anything like that (I've had a > particularly hard time figuring out if Xeon really has L3 or not). > > So what's a central place? Libdrm, everybody uses that right? You can > read /proc/cpuinfo as far as I know, but then you still need to query > the HAS_LLC getparam to figure out what kind of L3 (or do your own > chipset ID check). > > In addition to the centrality argument, I noticed while poking around > cpuid in the kernel that it is a vitalized function. I'm not sure what > the purpose of this is, but it's something you can't fake in userspace. In fact, isn't this functionality already part of arch/x86, and isn't the value already exposed via /proc/cpuinfo? -Chris -- Chris Wilson, Intel Open Source Technology Centre
