[PATCH libdrm 1/4] intel: add IS_GENX() generic macro

[Lucas De Marchi]

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