[x265] [PATCH Review only] asm: added psy_acEnergy_pp_4x4 in sse4 for psyCost_pp

[Deepthi Nandakumar]

Ok, We just discussed this here - we'll have function pointers initialised
based on size (match up the 4x4 and non-4x4 funcdef primitives using some
assembly tricks Praveen suggested).

On Thu, Dec 18, 2014 at 2:50 PM, Deepthi Nandakumar <
deepthi at multicorewareinc.com> wrote:
>
> Psy-energy is not always measured at the CU level. estIntraPredQT makes RD
> decisions at the PU level (search.cpp: 1532). Also, chroma uses the psy-rd
> 4x4 cost loop for 8x8 CUs.
>
> I see the concern though about performance reduction due to an in-loop if
> (size) check. There's no neat way around this, though.
>
> On Wed, Dec 17, 2014 at 12:33 PM, Steve Borho <steve at borho.org> wrote:
>>
>> On 12/17, Divya Manivannan wrote:
>> > The encoder uses 4x4 block size by testing with these two videos
>> > NebutaFestival_2560x1600_60_10bit_crop.yuv and 720p50_parkrun_ter.y4m.
>> > Since there is no similar function definition, I have generated the new
>> > function definition for 4x4.
>>
>> It can encode intra 4x4, but the CU in that case is still 8x8 and
>> psy-energy is always measured at the CU level (for pixels, for residual
>> it might measure 4x4 shorts).
>>
>> But why make a function that can only measure one half of the psy-value
>> when there already exists a function prototype for generating the full
>> energy score?
>>
>> I can guess where this is headed, where you write one function that
>> fills in an array of costs and then call it twice and have the C code
>> sum the abs(diff) of those costs, but if this is the direction you are
>> headed then the function prototype needs to be the same for all block
>> sizes.  Adding conditional paths for different block sizes will make the
>> function slower, in whole, as will requiring two function calls to make
>> one energy measurement.
>>
>> --
>> Steve Borho
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20141218/73e69efb/attachment.html>