On Fri, Dec 07, 2018 at 11:30:28AM +0000, Tvrtko Ursulin wrote: > > On 07/12/2018 01:17, Lucas De Marchi wrote: > > On Thu, Dec 6, 2018 at 4:37 AM Tvrtko Ursulin > > <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > On 06/12/2018 06:11, Lucas De Marchi wrote: > > > > Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of > > > > gen_mask to do the comparison. Now callers can pass then gen as a parameter, > > > > > > Since you are calling it out here, I assume there is some good reason to > > > replace gen_mask with gen? > > > > Because in this version we don't have the commit removing gen from the > > device info. > > You had that? Totally don't remember.. what was the goal of that? Derive the same info from mask. gen = ffs(gen_mask) + 1, or something like that. Checking again I had actually removed only the macro INTEL_GEN, not the struct member. Probably because we use that than I thought we would. > > > Checking gen instead of gen_mask is both simpler and generates smaller > > code (although > > the difference is negligible, ~100 bytes) > > Ok fair, and easy enough to change back once per SKU work rekindles. why would you need to change it back for per-SKU work? The compiler won't do anything smarter because of using the bitfield (provided this series is applied, which already merges IS_GEN8() || IS_GEN9() and the like). Lucas De Marchi > > Back to the point, for this particular rename, I don't see the big > attractiveness on it's own so I defer to comments from others. > > Regards, > > Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
