12-04-2010, 11:29 AM
I thinks there are some issues in the function FlushMadeNewTarget
1/ g_bSaveTex is check twice in a row (so there are some dead code). My opinion the 2nd is probably another variable.
2/ I do not get why g_MemTargs.GetMemoryTarget(curvb.tex0, 0) is called !
---------------------------------------------------------------------------------
Some ideas for the target cache implementation.
1/ In function CMemoryTargetMngr::CompareTarget before the comparaison of the clut. It maybe worth to check that it-> csa == tex0.csa. If the condition is false, data are likely to be different.
2/ Cache management (maybe someone already test). When SearchExistTarget found a target, move it in the beginning of the list. To avoid too big list, just cut last element. The current VALIDATE_THRESH method is not really fair, it tend to trash more the begin (and less last elements). Moreover it keeps a little more the comparison time in the cache under control because there is a maximum of a element. However it would be a little more complex to keep the different level of CompareTarget. Another solution could be to add a coefficient of usefulness, bigger for clut, bigger when texture is large, bigger when the texture is use a lot.
-------------------------------------------------------------------------------
If I'm correct the listClearedTargets mechanism is to save some malloc call. Is it malloc really so slow ?
1/ g_bSaveTex is check twice in a row (so there are some dead code). My opinion the 2nd is probably another variable.
2/ I do not get why g_MemTargs.GetMemoryTarget(curvb.tex0, 0) is called !
---------------------------------------------------------------------------------
Some ideas for the target cache implementation.
1/ In function CMemoryTargetMngr::CompareTarget before the comparaison of the clut. It maybe worth to check that it-> csa == tex0.csa. If the condition is false, data are likely to be different.
2/ Cache management (maybe someone already test). When SearchExistTarget found a target, move it in the beginning of the list. To avoid too big list, just cut last element. The current VALIDATE_THRESH method is not really fair, it tend to trash more the begin (and less last elements). Moreover it keeps a little more the comparison time in the cache under control because there is a maximum of a element. However it would be a little more complex to keep the different level of CompareTarget. Another solution could be to add a coefficient of usefulness, bigger for clut, bigger when texture is large, bigger when the texture is use a lot.
-------------------------------------------------------------------------------
If I'm correct the listClearedTargets mechanism is to save some malloc call. Is it malloc really so slow ?
)
nInit!
) here: