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 :) > > 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. -Chris _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
