At 2014-04-18 03:31:38,Jason Garrett-Glaser ja...@x264.com wrote:
On Wed, Apr 16, 2014 at 8:50 PM, chen chenm...@163.com wrote:
At 2014-04-17 08:05:22,Jason Garrett-Glaser ja...@x264.com wrote:
On Wed, Apr 16, 2014 at 11:08 AM, Steve Borho st...@borho.org wrote:
On Wed, Apr 16, 2014 at 12:57
Hi,
We try to build the code on 32-bit machine on WinXp platform with GCC,
We got build error after applying this patch:
[ 78%] Building CXX object encoder/CMakeFiles/encoder.dir/compress.cpp.obj
[ 79%] Building CXX object encoder/CMakeFiles/encoder.dir/reference.cpp.obj
[ 80%] Building CXX
# HG changeset patch
# User Santhoshini Sekar santhosh...@multicorewareinc.com
# Date 1397822534 -19800
# Fri Apr 18 17:32:14 2014 +0530
# Node ID 03aa222ff8eb5ffbe65bd5bf522cad6561210024
# Parent 78c1f43f12f57ba60e63cb79ce567065c700483e
vbv:Avoid infinite loop when row re-encode is
# HG changeset patch
# User Santhoshini Sekar santhosh...@multicorewareinc.com
# Date 1397824258 -19800
# Fri Apr 18 18:00:58 2014 +0530
# Node ID 3d680a36ea9acc45f3db128a5efe557a79a3026b
# Parent 03aa222ff8eb5ffbe65bd5bf522cad6561210024
vbv:reinit cu data when row vbv re-rencode is
x86inc handles this already when it references values in the stack.
If it didn't, none of x264's asm would function.
yes, for value only
it didn't align stack for reserve stack space (4th parameters of cglobal)
If it doesn't, that has nothing to do with registers it's pushed on
the stack --
At 2014-04-19 00:17:20,Jason Garrett-Glaser ja...@x264.com wrote:
x86inc handles this already when it references values in the stack.
If it didn't, none of x264's asm would function.
yes, for value only
it didn't align stack for reserve stack space (4th parameters of cglobal)
If it doesn't,
In this case, they pass a align stack to our code, but cglobal push 3
registers, so broken stack align.
I don't understand what you mean. x264asm knows what the stack
alignment is, so when it allocates scratch space, it references
aligned locations on the stack. It doesn't matter how many
At 2014-04-19 01:47:16,Jason Garrett-Glaser ja...@x264.com wrote:
In this case, they pass a align stack to our code, but cglobal push 3
registers, so broken stack align.
I don't understand what you mean. x264asm knows what the stack
alignment is, so when it allocates scratch space, it
On Fri, Apr 18, 2014 at 7:31 AM, santhosh...@multicorewareinc.com wrote:
# HG changeset patch
# User Santhoshini Sekar santhosh...@multicorewareinc.com
# Date 1397824258 -19800
# Fri Apr 18 18:00:58 2014 +0530
# Node ID 3d680a36ea9acc45f3db128a5efe557a79a3026b
# Parent
On Fri, Apr 18, 2014 at 11:03 AM, chen chenm...@163.com wrote:
At 2014-04-19 01:47:16,Jason Garrett-Glaser ja...@x264.com wrote:
In this case, they pass a align stack to our code, but cglobal push 3
registers, so broken stack align.
I don't understand what you mean. x264asm knows what the
I see what you're trying to do here. m_baseQP is always zero in normal vbv
operation, but contains previous QP values during re-encode.
A better solution would be to find out which field in TComDataCU actually
contains uncleared values, and clear them in TComDataCU::initCU.
On Sat, Apr 19,
In this case, x264asm don't do it because HAVE_ALIGNED_STACK=1
the input stack is aligned, but we need push 3 regs into stack, so we got a
stack mistake.
Again, that's not how it works.
HAVE_ALIGNED_STACK means x264asm can assume the input stack is aligned.
It does not mean x264asm magically
12 matches
Mail list logo
