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