- On multithreaded mesa, the program initialization routine was not
being flushed correctly. Set up synchronization fence after initialization
is complete.
- SRC0, SRC1 and SRC2 have different bits for precision modifiers all stored inside SRC1
- This explains the strange observed behavior of the MAD instruction which has 3 inputs
- Revert changes to FM and FMA instructions
- Allow non accurate/approx FMA family instructions to use native FMA
- Minor optimization for FMA ops with a constant 0 multiply
- use CELL_AUDIO_BLOCK_32 where possible
- use CELL_AUDIO_BLOCK_SAMPLES where possible
- remove redundant logging
- return CELL_AUDIO_ERROR_AUDIOSYSTEM in cellAudioGetPortConfig (probably unreachable code anyway)
- return CELL_AUDIO_ERROR_PORT_OPEN in cellAudioPortOpen
- stub cellAudioSetPersonalDevice cellAudioUnsetPersonalDevice and cellAudioMiscSetAccessoryVolume
- Sometimes, usually with shaders that do pack/unpack operations, there is a write-to-self operation.
For example r0.xy = r0.xy
Obviously no new data was introduced into "r0" by this, so we should not mark the register as having new data.
- TODO: Investigate on realhw if self-reference is needed to "cast" the overlapping half registers to their full register counterparts.
- Do not allocate too many objects. This is a problem in games using dynamic memory allocators that can make it rare for a surface to fall on the same address twice, keeping zombie RTVs and DSVs alive much longer than needed.
- Current limit used is 256M of virtual VRAM which is impossible on retail PS3
- Those strange offsets noted in some games seem to match to subpixel addressing.
For example, when scaling down by a factor of 4, a pixel offset of 2 will end up inside pixel 0 of the output