If I remember correctly, bit 13 disables the fastpath decoding of x87 instructions,
and bit 14 disables the fastpath decoding of mmx (and 3dnow?) instructions.

Why would this be necessary? Because these instructions are not always available,
such as in the following cases:

CR0.TS=1 // neither x87 and mmx instructions can be executed
CR0.EM=1 // neither x87 and mmx instructions can be executed
FERR is asserted // neither x87 and mmx instructions can be executed
Last media instruction was x87 // x87 instructions can be executed, mmx instructions need cpu cleanup first
Last media instruction was mmx // mmx instructions can be executed, x87 instructions need cpu cleanup first

In each of these cases, one or both SR13 bits is set, the fastpath decoder won't be invoked
for that group, and the instruction will go to microcode, to handle the required exception or cleanup.

What's the deal with the two "Last media instruction was ..." cases?
x87 and mmx were implemented in two different parts of the k6 logic. mmx was handled
near the core, x87 had it's own (practically independent) logic. Only one of the two
units was active at a time. When the other unit was invoked, k6 had to stop, copy the
register values from one unit to the other, then continue. Worst case, this took nearly 100 cycles.
(by the way, this was the motivation for the FEMMS instruction, because it would let
the user choose to not synchronize the register files.)

I suspect you're seeing the effect of this- the cpu says the last media instruction was
x87, so fast-mmx-instruction-decoding is disabled. When a mmx instruction is executed,
the cpu will spend 30-100 cycles updating the mmx copy of the register file, then
will clear SR13.bit14, set SR13.bit13, then do the mmx instruction.