On Thu, Feb 16, 2012 at 4:06 AM, Søren Sandmann <sandm...@cs.au.dk> wrote:
> "Lukic, Nemanja" <nlu...@mips.com> writes:
>
>> Run-time detection of the DSP extensions is left as it was in the
>> original patch. Yes, there is no easy way to run-time distinguish if
>> CPU supports DSPr1 or DSPr2. In case of "ddsp" string in the cpuinfo,
>> we don't want to return TRUE. TRUE should be returned only if there is
>> just "dsp" string found.
>
> As mentioned, if DSPr1 and DSPr2 can't be distinguished at runtime, then
> I don't think it makes sense to do runtime detection at all.

Also with the current patch, MIPS code can't be enabled without having
-mdspr2 option in CFLAGS. Having this option to CFLAGS effectively
results in allowing the compiler to use such instructions anywhere in
the library and runtime detection is a bit pointless. If runtime
detection is still desired, then some information could be potentially
extracted from the "cpu model" line from /proc/cpuinfo:

$ cat /proc/cpuinfo
system type             : Broadcom BCM4716 chip rev 1 pkg 10
processor               : 0
cpu model               : MIPS 74K V4.0
BogoMIPS                : 238.59
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 64
extra interrupt vector  : no
hardware watchpoint     : yes
ASEs implemented        : mips16 dsp
shadow register sets    : 1
VCED exceptions         : not available
VCEI exceptions         : not available

unaligned_instructions  : 0
dcache hits             : 2147483648
dcache misses           : 1844436768
icache hits             : 2147483648
icache misses           : 3792270195
instructions            : 2147483648

Right now there are not too many MIPS processors supporting DSP ASE
(either r1 or r2), so the list of CPU model identifiers to parse could
be reasonably finite. Still the current state is far from perfect and
probably should be escalated to MIPS kernel maintainers. The sooner,
the better.

One more bit of important information is cache line size. Because of
using PrepareForStore prefetch, knowing the exact cache line size is
critical for correct program behaviour. By looking at the code, right
now 32 bytes cache line is assumed. It would be better to also have
this information checked at runtime to disable non-compatible
optimizations if the cache line size is not equal to 32 bytes.

-- 
Best regards,
Siarhei Siamashka
_______________________________________________
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman

Reply via email to