On Mon, 30 Jan 2006 02:00:19 -0500 Michael Jennings [EMAIL PROTECTED] babbled:
I'm getting a SIGILL from evas on one of my systems which has MMX
support but no SSE support. I think it might be a bug in evas'
choosing of optimized routines. Here's the trace:
#8 0xb7e678a5 in
On Monday, 30 January 2006, at 17:45:15 (+0900),
Carsten Haitzler wrote:
what does you src/lib/engines/common/evas_cpu.c say in
evas_common_cpu_sse_test ().
You want me to set a breakpoint there or something? Watching the
strace, I do get an illegal instruction early on in the execution, but
On Mon, 30 Jan 2006 12:36:17 -0500 Michael Jennings [EMAIL PROTECTED] babbled:
On Monday, 30 January 2006, at 17:45:15 (+0900),
Carsten Haitzler wrote:
what does you src/lib/engines/common/evas_cpu.c say in
evas_common_cpu_sse_test ().
You want me to set a breakpoint there or
On Tuesday, 31 January 2006, at 10:29:48 (+0900),
Carsten Haitzler wrote:
literally the mmx in that uses movq (see the macro in evas_mmx.h)
and monvtq - movntq is a newer call in sse and thats what the sse
test routines should be looking for - stargint at the code in front
of me right
On Mon, 30 Jan 2006 22:51:48 -0500 Michael Jennings [EMAIL PROTECTED] babbled:
On Tuesday, 31 January 2006, at 10:29:48 (+0900),
Carsten Haitzler wrote:
literally the mmx in that uses movq (see the macro in evas_mmx.h)
and monvtq - movntq is a newer call in sse and thats what the sse
On Tuesday, 31 January 2006, at 13:31:51 (+0900),
Carsten Haitzler wrote:
ok - your evas is not what is in cvs:
void
evas_common_cpu_sse_test(void)
{
#ifdef BUILD_SSE
int blah[16];
movntq_r2m(mm0, blah);
#endif
}
[EMAIL PROTECTED] ~/cvs/e17/libs/evas mzblame
On Mon, 30 Jan 2006 23:35:44 -0500 Michael Jennings [EMAIL PROTECTED] babbled:
On Tuesday, 31 January 2006, at 13:31:51 (+0900),
Carsten Haitzler wrote:
ok - your evas is not what is in cvs:
void
evas_common_cpu_sse_test(void)
{
#ifdef BUILD_SSE
int blah[16];
I'm getting a SIGILL from evas on one of my systems which has MMX
support but no SSE support. I think it might be a bug in evas'
choosing of optimized routines. Here's the trace:
#8 0xb7e678a5 in evas_common_copy_pixels_rgba_to_rgba_sse () from
/usr/lib/libevas.so.1
#9 0xb7e7c988 in
