On Tue, Feb 21, 2012 at 8:24 PM, Matt Turner <matts...@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 _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman