Dolphin, the GameCube and Wii emulator - Forums

I don't know why developer didn't just make efb to RAM and efb to Texture mix together. The problem is, If i choose efb to Ram (screen A1) is not accurate but (screen B1) are accurate... If i choose efb to texture (screen A1) are accurate but (screen B1) are not accurate. Sorry about my bad english.



efb copy to RAM(screen A1 not accurate)



efb copy to RAM(screen B1 are accurate)



efb to Texture(screen A1 are accurate, but the background color should be black)



efb to Texture(screen B1 not accurate)

Technically RAM is a mix

If you use a Texcache Rewrite build both options can be used in the same time

Quote:If you use a Texcache Rewrite build both options can be used in the same time

......and in regular builds too.

The ram option creates a ram copy and if enable cache is turned on it also creates a texture copy. The texture option only creates a texture copy.

(01-27-2012, 04:44 AM)ExtremeDude2 Wrote: [ -> ]Technically RAM is a mix

Is it? o_o

(01-27-2012, 05:20 AM)neobrain Wrote: [ -> ]

(01-27-2012, 04:44 AM)ExtremeDude2 Wrote: [ -> ]Technically RAM is a mix

Is it? o_o

Well I know that NV made a issue once (that was closed eventually XD), but maybe I was confusing it with this:

(01-27-2012, 05:19 AM)NaturalViolence Wrote: [ -> ]The ram option creates a ram copy and if enable cache is turned on it also creates a texture copy.

(01-27-2012, 05:19 AM)NaturalViolence Wrote: [ -> ]

Quote:If you use a Texcache Rewrite build both options can be used in the same time

......and in regular builds too.

The ram option creates a ram copy and if enable cache is turned on it also creates a texture copy. The texture option only creates a texture copy.

That's not completely true; actually regular builds use a hybrid approach to EFB copies even if only EFB to RAM is selected (i.e. cache disabled). That means that we always create a texture copy, but we throw it away in case the game needs RAM copies.
The EFB copy cache is a minor optimization to this and bscly only causes bugs :/

EDIT: For more detailed information, read http://code.google.com/p/dolphin-emu/sou...dd89e2#373 .

Quote: Emulation methods:
EFB to RAM
Encodes the requested EFB data at its native resolution to the emulated RAM using shaders. Load() decodes the data from there again (using TextureDecoder) if the EFB copy is being used as a texture again.

Advantage: CPU can read data from the EFB copy and we don't lose any important updates to the texture.

Disadvantage: Encoding+decoding steps often are redundant because only some games read or modify EFB copies before using them as textures.

EFB to texture
Copies the requested EFB data to a texture object in VRAM, performing any color conversion using shaders.

Advantage: Works for many games, since in most cases EFB copies aren't read or modified at all before being used as a texture again. Since we don't do any further encoding or decoding here, this method is much faster. It also allows enhancing the visual quality by doing scaled EFB copies.

Disadvantage: CPU can't read data from the EFB copy and we lose any important updates to the texture.

Hybrid EFB copies
1) Whenever this function gets called, encode the requested EFB data to RAM (like EFB to RAM)

2a) If we haven't copied to the specified dstAddr yet, copy the requested EFB data to a texture object in VRAM as well (like EFB to texture). Create a texture cache entry for the render target (isRenderTarget = true, isDynamic = false). Store a hash of the encoded RAM data in the texcache entry.
2b) If we already have created a texcache entry for dstAddr (i.e. if we copied to dstAddr before) AND isDynamic is false so the same thing as above, but reuse the old texcache entry instead of creating a new one.
2c) If we already have created a texcache entry for dstAddr AND isDynamic is true (isRenderTarget will be false then). Only encode the texture to RAM (like EFB to RAM) and store a hash of the encoded data in the existing texcache entry. Do NOT copy the requested EFB data to a VRAM object. Reason: the texture is dynamic, i.e. the CPU is modifying it. Storing a VRAM copy is useless, because we'd end up deleting it and reloading the data from RAM again anyway.

3) If the EFB copy gets used as a texture, compare the source RAM hash with the hash you stored when encoding the EFB data to RAM.
3a) If the two hashes match AND isDynamic is still false, reuse the VRAM copy you created
3b) If the two hashes differ AND isDynamic is still false, screw your existing VRAM copy. Set isRenderTarget to false and isDynamic to true. Redecode the source RAM data to a VRAM object. The entry basically behaves like a normal texture now.
3c) If isDynamic is true, treat the EFB copy like a normal texture.

Advantage: Neither as fast as EFB to texture nor as slow as EFB to RAM, so it's a good compromise. Non-dynamic EFB copies can be visually enhanced like with EFB to texture. Compatibility ideally is as good as with EFB to RAM.

Disadvantage: Depends on accurate texture hashing being enabled. However, with accurate hashing you end up being as slow as EFB to RAM anyway.

Disadvantage of all methods: Calling this function requires the GPU to perform a pipeline flush which stalls any further CPU processing.

You wrote that didn't you . What kind of developer writes comments in their code that actually explains stuff!?!?!

Edit: Cleaned it up a bit and made it easier to read.

(01-27-2012, 05:31 AM)neobrain Wrote: [ -> ]That's not completely true; actually regular builds use a hybrid approach to EFB copies even if only EFB to RAM is selected (i.e. cache disabled).

This ^^ is what I was talking about

(01-27-2012, 07:34 AM)NaturalViolence Wrote: [ -> ]You wrote that didn't you . What kind of developer writes comments in their code that actually explains stuff!?!?!

Ya

Anyway, I posted the wrong link before.. I edited my previous post which now links to a more up-to-date version of the explanation. The old one had a few mistakes in it, so you'll maybe want to read it again...