[Mesa-dev] [PATCH 1/2] i965: remove cache_aux_free_func array
Matt Turner
mattst88 at gmail.com
Wed Oct 21 14:44:24 PDT 2015
On Wed, Oct 21, 2015 at 2:16 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 21 October 2015 at 21:33, Kenneth Graunke <kenneth at whitecape.org> wrote:
>> On Monday, October 19, 2015 02:54:56 PM Emil Velikov wrote:
>>> Ping on these two trivial patches ?
>>>
>>> -Emil
>>
>> Oh, sorry, I thought I'd sent R-bs for these...
>>
>> Both are
>> Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
> Thanks Ken. I was wondering if people looked at them and went "meh ...
> too small, we need something beefier" :-P
>
> And now ... some C++ questions. I realise that templates (or is it
> only STL?) are out of the question, but how about
> - Initialization upon object declaration, rather than copy
> constructors ? Rather trivial yet we have thousands of
You're talking about things like this?
fs_reg reg = fs_reg(...)
I seem to remember trying at one point to replace those with just
fs_reg reg(...)
and found that it made absolutely no difference in the compiled code.
The second's probably preferable if for no other reason than it's
shorter, but I don't know that there's anything to be gained...
> duplicated/wasted CPU cycles due to it. One example is the memset()
> from {fs,src,dst}_reg. Does the compiler squash/optimize those for us
> ?
Not sure. Experiments and data are welcome.
I think people preferred the memset because there wasn't an
alternative safe way of ensuring everything was initialized? Not sure.
> - Where is the line about "big enough to pass as reference" rather
> than a copy for i965 ? It seems that older code(?) and extremely
> common things such as the *_reg are passed around as copies.
We want to use const references for dst_reg/src_reg/fs_reg where
possible (see commit e58992aed and the three immediately before it for
data). I don't think there should be many more instances of this.
brw_reg is 8 bytes, so there's no reason to pass it as anything but by value.
More information about the mesa-dev
mailing list