[x265] [PATCH] sse: fix data type for sse functions

[Deepthi Nandakumar]

So, I dont think it's fair to upgrade the datatypes of these variables just
to satisfy debug/check code. We're unnecessarily adding cycles.

I think the best solution here might be to remove these hacky checks in
Mode.invalidate(), and Mode.ok() and add more robust checking into
rdcost.h.



On Thu, Sep 24, 2015 at 9:45 AM, Divya Manivannan <
divya at multicorewareinc.com> wrote:

> sse_ret_t is changed to uint64_t unconditionally in all the modes.
>
> On Wed, Sep 23, 2015 at 8:21 PM, chen <chenm003 at 163.com> wrote:
>
>> Which type?
>> in 8b/10b mode, sse_ret_t may 32-bits
>>
>> At 2015-09-23 16:43:34,"Divya Manivannan" <divya at multicorewareinc.com>
>> wrote:
>>
>> The data type is changed to uint64_t and ok() is also changed accordingly
>> in this patch. Please tell any other changes are required?
>>
>> On Mon, Sep 21, 2015 at 9:52 PM, chen <chenm003 at 163.com> wrote:
>>
>>> The ok() is self verify code, we need correct it.
>>>
>>> At 2015-09-21 12:39:24,"Divya Manivannan" <divya at multicorewareinc.com>
>>> wrote:
>>>
>>> There is no dynamic range overflow in 8bpp and 10bpp mode. But the
>>> threshold in the ok() function is below the dynamic range for 10bpp mode.
>>>
>>> On Wed, Sep 16, 2015 at 8:28 PM, chen <chenm003 at 163.com> wrote:
>>>
>>>> Are you found dynamic range overflow in 8bpp and 10bpp mode?
>>>>
>>>>
>>>> At 2015-09-16 17:11:29,"Divya Manivannan" <divya at multicorewareinc.com> wrote:
>>>> ># HG changeset patch
>>>> ># User Divya Manivannan <divya at multicorewareinc.com>
>>>> ># Date 1442392516 -19800
>>>> >#      Wed Sep 16 14:05:16 2015 +0530
>>>> ># Node ID ee39c10fd573444710aca40ec3bd572aac8b3cd0
>>>> ># Parent  365f7ed4d89628d49cd6af8d81d4edc01f73ffad
>>>> >sse: fix data type for sse functions
>>>> >
>>>> >diff -r 365f7ed4d896 -r ee39c10fd573 source/common/common.h
>>>> >--- a/source/common/common.h	Tue Sep 08 16:38:01 2015 +0530
>>>> >+++ b/source/common/common.h	Wed Sep 16 14:05:16 2015 +0530
>>>> >@@ -134,12 +134,6 @@
>>>> > typedef int32_t  ssum2_t; // Signed sum
>>>> > #endif // if HIGH_BIT_DEPTH
>>>> >
>>>> >-#if X265_DEPTH <= 10
>>>> >-typedef uint32_t sse_ret_t;
>>>> >-#else
>>>> >-typedef uint64_t sse_ret_t;
>>>> >-#endif
>>>> >-
>>>> > #ifndef NULL
>>>> > #define NULL 0
>>>> > #endif
>>>>
>>>>
>>>> _______________________________________________
>>>> x265-devel mailing list
>>>> x265-devel at videolan.org
>>>> https://mailman.videolan.org/listinfo/x265-devel
>>>>
>>>>
>>>
>>> _______________________________________________
>>> x265-devel mailing list
>>> x265-devel at videolan.org
>>> https://mailman.videolan.org/listinfo/x265-devel
>>>
>>>
>>
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
>>
>>
>
> _______________________________________________
> 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/20150929/2f2bbef5/attachment.html>