[Pixman] Basic infrastructure for MIPS architecture and initial set of SRC routines.
Siarhei Siamashka
siarhei.siamashka at gmail.com
Tue Feb 21 12:26:28 PST 2012
On Tue, Feb 21, 2012 at 8:24 PM, Matt Turner <mattst88 at gmail.com> wrote:
> How does this affect compiling with -march=mips64{,r2}, assuming that
> there are mips64 CPUs with DSPr2?
It will likely either build without DSPr2 optimizations (by failing
the DSPr2 configure test), or fail the compilation itself. Somebody
will have to fix this.
But IMHO a much worse scenario would be successful compilation for
MIPS64 hardware with DSPr2 support and >=64 byte cache line. The
unique feature of PrepareForStore prefetch is that it can clear the
whole cache line to zero on a cache miss. With at least two potential
runtime problems to watch out for:
1. The code assumes that doing prefetch 32 bytes before the end of the
buffer is safe and uses it, but happens to erase some data beyond it.
2. The code assumes that doing prefetch 32 bytes ahead of the
previously written data is safe, but we get a context switch
immediately before the prefetch instruction, some other process
thrashes the cache, and after resuming the execution prefetch
instruction erases some earlier processed data.
> All this seem like a ton of work to deal with the unsolved problem of
> mips runtime testing.
Sure. But if nobody takes care of fixing the kernel, the problem will
remain unsolved.
> Wouldn't it be simpler to just have the
> configure test fail if you're not compiling with the needed CFLAGS?
> Any distro wanting maximum compatibility is going to compile with
> mips1, which is incompatible with DSPr2.
Yes, it is a somewhat acceptable solution (if we forget about the
PrepareForStore prefetch for a moment). Though pixman DSPr2 optimized
code will not have any chance to provide any speedup in such distros.
--
Best regards,
Siarhei Siamashka
More information about the Pixman
mailing list