(09-21-2011, 05:45 AM)NaturalViolence Wrote: And a 1MB edram buffer for holding a texture, called the etb (embedded texture buffer).You usually just call that thing TMEM (texture memory). It acts as an automatic cache: Textures are actually stored in RAM as well and moved to TMEM once they're going to be accessed soon by the GP.
(09-21-2011, 05:45 AM)NaturalViolence Wrote: But the GC/Wii also stores a copy of the efb contents in main memory, the developers of dolphin refer to this as the "efb copy".The GC/Wii don't "store" a copy of the efb contents. Actually, applications may request the GP (graphics processor) to copy a rectangle (or just the whole area) of the EFB contents to a texture stored in RAM (this will also convert the EFB data to the requested texture format). Also, it's not only "us" who refer to that as "EFB copies"
Applications can request multiple of these EFB copies, so it should've been "copies" instead "copy" within your whole post (just btw ).
(09-21-2011, 05:45 AM)NaturalViolence Wrote: If the efb copy setting is disabled in dolphin then dolphin does not emulate the efb copy. If a game does not use the efb copy for anything than this will have no affect on the game.And neither will it have any effect on the performance if it's not used..
(09-21-2011, 05:45 AM)NaturalViolence Wrote: If the efb copy setting is virtual in dolphin then dolphin emulates the efb copy by storing a texture in video ram with a copy of the efb contents. In a PC the video ram can only be accessed by the GPU, the cpu can not access the contents of the video ram. Video ram is much faster than main memory. This allows us to emulate the efb copy in a very fast way on most systems.The main reason for virtual EFB copies (aka copies to texture) being faster than copying them to RAM is not RAM/VRAM speed. If you look at the steps necessary to emulate EFB copies to RAM:
a) Encode the source EFB rect to the requested target texture format (done on the GPU using pixel shaders, everything happens within VRAM so that's fast...)
b) Wait until the GPU has flushed its pipeline so that we can progress to step c (shouldn't be too much of a problem with a decent GPU though)
c) download the encoded texture from VRAM to RAM (slow)
d) Once the target texture gets used again for rendering, we'll need to decode the target texture from RAM (our texture decoder is pretty fast these days though; everything happens within RAM as well, so this step is fast as well)
e) upload the decoded texture data from RAM to VRAM (slow)
However, if we emulate EFB copies via GPU objects (i.e. D3D/OpenGL textures), it boils down to:
a) Encode the source EFB rect to the requested target texture format (done on the GPU using pixel shaders again)
b) no need to wait until the GPU is done because step c isn't necessary
c) isn't necessary
d) Once the target texture gets used again for rendering, we just need to make sure the application didn't modify the texture. If that's the case, we can simply tell the GPU to use the texture it just decoded. If the application did modify the texture, we need to decode it again
e) IF the application did modify the texture data (and only then), we need to upload the decoded texture data from RAM to VRAM again.
I.e., with virtual EFB copies, we don't need to deal with step b,c and e in the ideal case.
(09-21-2011, 05:45 AM)NaturalViolence Wrote: Shaders are used by dolphin to have the GPU modify the contents of the efb copy. Most GC/Wii games only use the GPU to modify the contents of the efb copy so this option is fine for most games.1. There's no "single EFB copy which is always stored in RAM", like I explained above.
2. The shaders aren't used to modify the EFB copy contents. They're actually used to create the EFB copy contents (i.e. for color conversion).
(09-21-2011, 05:45 AM)NaturalViolence Wrote: However some GC/Wii games sometimes use the cpu to modify the contents of the efb copy (for example to produce the spinning coins affect in new super mario brothers the game engine uses the cpu to modify the efb copy). Since on a PC the cpu can not access video ram the virtual setting will not be able to emulate anything that relies on the cpu modifying the efb copy.That's only part of the problem (it would be possible to let the CPU access VRAM, it's just damn slow). The more important problem is that we can't even track when the CPU modifies textures, since textures can be stored almost anywhere in RAM (and we can't check for each CPU write instruction if it modifed a texture )
(09-21-2011, 05:45 AM)NaturalViolence Wrote: If both the ram and virtual settings are enabled then dolphin will store two efb copies. One as a texture in video memory and one encoded the same way as the real hardware in main memory. Dolphin will check the ram copy for changes at regular intervals and as long as the cpu does not modify the ram copy dolphin will keep using the faster and possibly high resolution texture copy."at regular intervals" is kinda misleading. We check that each time the copy target texture is used.