On Mon, Aug 27, 2018 at 10:40:28PM +0100, Chris Wilson wrote: > Quoting Lucas De Marchi (2018-08-27 22:19:54) > > On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote: > > > Quoting Lucas De Marchi (2018-08-25 00:56:46) > > > That should help cut down the object size expansion. But longer term I'd > > > > I'm not opposed to turning it into inline function, but if the goal is > > to reduce the object size expansion, just making the array static const > > should suffice... we do call the macros several times, but most of the > > size is for constructing the array, not to find the elements. > > It'll construct the array on the stack, painfully. I thought you were > trying for a minimal change :) the way I meant it it won't construct in the stack. > > > > prefer if we moved to towards finding the match data once. Also we need > > > to pull into the canonical header the friendly names for mesa. > > > > what do you mean by "friendly names for mesa". > > > > The other option that is actually my preferred is to let the kernel tell > > user space what it is. What do you think about having an ioctl that returns > > what is the gen + additional interesting info? Then user space could > > base its decisions on features and fallback to gen version when there > > isn't a way to discover if a feature/bug is present. This would allow > > to simply remove the pci ids from user space projects which IMO would be > > a good thing. > > There simply wasn't enough interest. The key point is selling it to > mesa, see include/pci_ids/i965_pci_ids.h > > The challenge with the centralised db of interesting info is that it > will always be out of date for userspace (think userspace having to cope > with a 5 year kernel, and a kernel having to cope with 10 year old > userspace) and never enough so they still have to supplement it without > their own db. > > That isn't to say that there isn't a lot of interesting hw properties > that userspace needs to know, but they are also tend to be the ones tied > to fuses and not pciid. > > What we do all duplicate are the pci-ids, so pulling those into a > central header containing the commonly used per-id information in a format > that can be embedded into any of the caller's structs is challenge > enough. I think kernel, igt and libdrm would be happy with either runtime or a common header. Checking now what mesa does, giving a friendly name and assigning the properties for each and every device is out of reach, at least for now. So fair enough regarding the runtime option. However I don't think that means we shouldn't try improve libdrm/igt just because it won't solve it for mesa (at least with the "common header approach"). I'll try to spin a new version to handle your comment. Lucas De Marchi _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
