It provided a large increase in complexity of the logging system while
having a negligible performance impact: the usage patterns of the ring
buffer meant that each log contended with the logging thread, causing
it to effectively act as a synchronous extra buffering.
Also removed some broken code related to filtering of subclasses which
was broken since it was introduced. (Which means no one ever used that
feature anyway, since, 8 months later, no one ever complained.)
There's no other coprocessor outside the VFP (which has its own VMOV variants) in which the MPCore can send/retrieve data from.
Stubbed so citra won't crash and burn on the odd chance someone actually tries to use these.
@neobrain, could you confirm that this is correct?
It's been tested with various different games and fixes different textures, including in Animal Crossing, Kirby Triple Deluxe, and SMB3D.
This works around crashes related to GSP/HID/etc. shared memory blocks
having garbage values. The proper fix requires proper management of
mapped memory blocks in the process.
When the macro was introduced in 326ec51261
it wasn't noticed that it conflicted in name with a heavily used macro
inside of dyncom. This causes some compiler warnings. Since it's only
lightly used, it was opted to simply remove the new macro.
It is superfluous for Citra. (It's only really necessary if you're doing
JIT. We were using it but not taking any advantage from it.) This should
make 32-bit builds work again.
The old system of just defining macros available in some other platform
was susceptible to silently using the wrong code if you forgot to
include a particular header. This fixes a crash on non-Windows platforms
introduced by e1fbac3ca1.
Yuri Kunde Schlesner