Re: [RFC 4/7] drm/i915: Remove mkwrite_device_info

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

 



Quoting Jani Nikula (2018-11-13 11:28:11)
> On Tue, 13 Nov 2018, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote:
> > On 12/11/2018 17:25, Chris Wilson wrote:
> >> Quoting Tvrtko Ursulin (2018-11-12 17:12:39)
> >>> From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> >>>
> >>> Now that we are down to one caller, which does not even modify copied
> >>> device info, we can remove the mkwrite_device_info helper and convert the
> >>> device info pointer itself to be a pointer to static table instead of a
> >>> copy.
> >> 
> >> The copy was deliberate to avoid the extra pointer. How does the change
> >> in code size now compare?
> >
> > AFAIR grows a bit, but overall series still ends up overall smaller. I 
> > need to re-run the numbers for more concrete info.
> >
> > However, if we keep having a copy, ie. do not make device info properly 
> > read-only, are we still interested in splitting the two? Benefit would 
> > be diminished, but presumably people still think it would be worth it?
> 
> If we don't turn device info into a pointer to the static const structs,
> IMO there's simply no point in any of this. Then we might just as well
> drop the const and mkwrite_device_info, and use the mutable thing all
> over the place.
> 
> Modifying the device info copy was supposed to be an exception at the
> time of the copy, but with mkwrite_device_info it has proliferated. It's
> silly and ugly and wrong with no benefits. The const was put in place to
> hint that it's not supposed to be modified, but that didn't work out.
> 
> So which is it, runtime/static split with an extra pointer chase to the
> const data in rodata (I'm in favor), or just drop the const from the
> dev_priv copy and remove mkwrite_device_info?
> 
> The latter makes future attempts at utilizing DCE/LTO with a reduced
> number of device infos much harder I think.

The DCE goal is still worthwhile, as is making our constants truly
immutable.

It's just a digression as I remembered one benefit of the copy, and
tracking how much of that benefit remains and could maybe recovered in
other ways is something we can measure.
-Chris
_______________________________________________
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