At 2015-03-11 00:36:45,"Steve Borho" <[email protected]> wrote: >On Tue, Mar 10, 2015 at 11:34 AM, dave <[email protected]> wrote: >> On 03/10/2015 08:56 AM, Steve Borho wrote: >>> >>> On 03/10, dave wrote: >>>> >>>> On 03/09/2015 11:40 PM, Steve Borho wrote: >>> >>> <snip> >>>>> >>>>> No, but the command line option --cu-stats does show how much it is >>>>> called (but not how long it took) >>>>> >>>> This produces some interesting numbers. >>>> >>>> Without using registers for constants >>>> >>>> x265 [info]: I32: Intra 100%(DC 0% P 40% Ang 58%) >>>> >>>> encoded 2000 frames in 95.98s (20.84 fps), 1020.04 kb/s >>>> >>>> With using registers for constants >>>> >>>> x265 [info]: I32: Intra 99%(DC 39% P 16% Ang 43%) >>>> >>>> encoded 2000 frames in 93.10s (21.48 fps), 1008.63 kb/s >>>> >>>> I just added --cu-stats to the same command options that I used >>>> previously and I ran it several times and got exactly the same >>>> percentages. Times varied by less than a second for each build. So >>>> how can simple register usage in one primitive affect intra pred >>>> decisions? >>> >>> it shouldn't, the behavior must be wrong in one of the cases. no change >>> in performance should be able to impact the encoder output (or any >>> coding decisions) >>> >> So execution time isn't directly measured for decision making? >> >> The output is also different. >> >> ls -l bridge-close* >> -rw-r--r-- 1 shakezula shakezula 8432204 Mar 10 09:25 bridge-close1.y4m >> -rw-r--r-- 1 shakezula shakezula 8527219 Mar 10 07:49 bridge-close.y4m >> >> bridge-close1.y4m was generated without the use of registers to hold >> constants. > >yeah, definitely a bug in one of the two versions and if the testbench >doesn't catch it that's really bad. > We need disable assembly to confirm and try to find which function made the bug
_______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
