Closed Senryoku closed 1 month ago
Forcing mov.w @Rm+, Rn
to fallback to the interpreter modifies the issue. This might indicate an issue with this instruction, or an issue with the register cache.
Forcing a fallback (and a cache flush) for all of them fixes the issue:
movb_atRmInc_Rn
movw_atRmInc_Rn
movl_atRmInc_Rn
movb_Rm_atRnDec
movw_Rm_atRnDec
movl_Rm_atRnDec
movb_atDispRm_R0
movw_atDispRm_R0
movl_atDispRm_Rn
movb_R0_atDispRm
movw_R0_atDispRm
movl_Rm_atDispRn
Using interpreter_fallback_cached
as a fallback modifies the issue in the same way as a full fallback of mov.w @Rm+, Rn
(flushing all cached values) without eliminating it completely, suggesting that this is indeed a cache issue in another instruction :(
Video playback using YUV420 hardware conversion shows weird (mostly) green artifacts. Seems to only appear when there's movement.
Does the software launch a conversion then starts streaming data in RAM, counting on the processing/transfer time? I'm currently processing all macro blocks immediately, should I process them one by one with some delay?Or maybe it's decompressing and there are floating point issues?It goes away when using the interpreter.
Mostly still image:![image](https://github.com/user-attachments/assets/6b047644-4b62-4010-b009-06010ceede92)
Moving up:![image](https://github.com/user-attachments/assets/1e7dc167-2437-4eb5-a378-5e1d937bc4f5)