Re: [PATCH] drm/i915: Drop platform_mask

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 15, 2019 at 12:13 AM Tvrtko Ursulin
<tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
>
>
> On 15/03/2019 06:56, Tvrtko Ursulin wrote:
> >
> > On 15/03/2019 00:52, Chris Wilson wrote:
> >> Quoting José Roberto de Souza (2019-03-15 00:42:35)
> >>> We don't have any platform that is composed by 2 or more platforms so
> >>> we don't need a mask, lets drop it and remove the actual limit of 32
> >>> platforms.
> >
> > Platform mask was a nifty trick to compile tests like IS_SKYLAKE ||
> > IS_BROADWELL etc into a single conditional.
> >
> >> gcc doesn't entirely agree, this is a net loss here (i.e. code size
> >> increases).
> >
> > Perhaps the size re-gain of dropping the platform mask could be checked
> > against the size gain of making the mask 64 bit.

current:
  text       data        bss        dec        hex    filename
1836533      40454       4176    1881163     1cb44b
drivers/gpu/drm/i915/i915.o.old

64 bit bitmask:
1836757      40454       4176    1881387     1cb52b drivers/gpu/drm/i915/i915.o

no platform_mask:
1837591      40454       4176    1882221     1cb86d
drivers/gpu/drm/i915/i915.o


So current situation to "just use a number" we are talking about 1k
here, which for me looks acceptable. Alternative is the 64-bit
bitmask, with ~200 bytes.

Lucas De Marchi



>
> One possible alternative could be splitting the 64-bit platform mask
> into two 32-bit dwords. Like:
>
>    u32 platform_mask[2];
>
>    #define IS_PLATFORM(p) (platform_mask[p / 32] & BIT(p % 32))
>
> And a bit of jigging the enum space so that we don't end up with
> something often tested together on the dword boundary.
>
> In fact I had a prototype many months ago which went a step further and
> interleaved platform with gen mask, in some sized chunks, so even
> IS_PLATFORM || IS_GEN checks could be merged. This included the
> sub-platform thing as well with the ULT/ULX/LP stuff I think.. maybe I
> need to dig this out to see how it worked.
>
> Regards,
>
> Tvrtko
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



--
Lucas De Marchi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux