Dolphin, the GameCube and Wii emulator - Forums

(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.

Hi again NaturalViolence and Neobrain.

Quote:Oh jeez it's kind of a long story since you have to understand the basics of the GC/Wii architecture first. I'll try and summarize as best as I can....

and you explained it wonderfully. I understood everything. Thanks.
And thank you for your input as well Neobrain.
Having a greater understanding of the emulator allows me to really utilise it to the best of my ability and bring out the best in the game within the confines of my system's capabilities.

I went home last night and changed the audio settings to Xaudio2 and the audio has improved remarkably! Yes, there is the odd snap crackle and pop, and slowdown on the occasional group shadow attack, but on the whole, I can enjoy the game in its full audio glory.

Here is a picture of my current settings (yet to be optimised further) that have really helped...(thanks to you folk)

I have circled things that helped improve my gameplay.



Notice DX11 as being selected? Funny thing is, for my particular system (i think) I am getting better results with DX11 (average 27-31fps) with lovely bloom.

For an odd reason, just like LReyomeXX, I am obtaining better results with DX11 as opposed to DX9.

I have uploaded the following for anyone who may find these interesting.

Here are some examples and the respective settings:


and

and


As one can see, for me, with DX9 selected and both Virt and RAM selected as On for EFB copies, I obtain a bloomless environment, with a sharp staccato map more suited for a game like MGS.

On Dx9 With virtual turned off this time, the bloom returns, at the expense of fuzzy textures and a 'broken' map.

However, for me (I guess not for all) Dx11 fixed it with virt on and ram off (ram on brought stuttering and lower framerates).

Though it may seem blurry and less 'sharp' as opposed to DX9, Dx11 yielded good results, while maintaining the bloom. Also, the map has that softness that is well suited for the RPG as was there originally on the GC.

So, for me personally, Direct3d11, EFB Copies - Virtual:On RAM:Off worked wonders.

Thank you again for your help.

Here are some closing fun pics:

Her pastiness, princess Zelda (DX9, EFB Copies - Virtual:ON RAM:ON)


And the babe with a nice radiant glow to her face after a grand shafting up the ass by Link (Direct3d11, EFB Copies - Virtual:On RAM:Off):


Thank you all again for your help.

I will go ahead and enjoy that which I once enjoyed years ago on my GC.
Will be back if anything plays up.

CG

texcache-rewrite builds are faster with D3D11 since texture palettization is done using the GPU there, while D3D9 still uses the CPU for that (iirc).

(09-21-2011, 08:28 PM)neobrain Wrote: [ -> ]texcache-rewrite builds are faster with D3D11 since texture palettization is done using the GPU there, while D3D9 still uses the CPU for that (iirc).

That my explain as to why I am obtaining better results with D3d11 over D3d9....Or results that I desire.

CG

Quote:On Dx9 With virtual turned off this time, the bloom returns, at the expense of fuzzy textures and a 'broken' map.

That fuzziness as you describe it is the low internal resolution that comes with only using a ram copy.

Excellent thread friends!

I am about 65% of the way through and even with the ZTP hack I only get about 20 FPS in Hyrule (My HW should be able to eat this up... I think). My reason for posting is that I am getting 2 types of "lock-ups" (no error messages, just a permanent freeze of Dolphin):

1) Howling Stones. No matter what I do: MMU, LLE, DirectX/OpenGL: It freezes on almost every howling stone (it even froze once as I approached it as human Link).

2) Random freezes. No rhyme or reason, never the same spot, time of day, etc. I am using 3.0, although I did use 6054 (I think that was the revision) with the settings posted in the beginning of this thread and the wiki. Same results with both.

HW:
i5-2500K @ 4.5GHz
4 GB GSkill 1600 DDR3
ATI Radeon 6970 2GB
Gigabyte Z68-UD3
Corsair H-100
Windows 7 32-bit (Updated DirectX and Microsoft Visual C++ 2010 Redistributable about a week ago per the FAQ)

I think my hardware is beefy enough to handle this game. I can post my existing settings but I have changed many different things in an effort to fix this to no avail (plus I am at work and cant post them until at home anyway).

I have read all 190+ pages of this thread in hopes of finding something, but I am all out of ideas and it is disheartening.

Quote:I have read all 190+ pages of this thread in hopes of finding something, but I am all out of ideas and it is disheartening.

No offense but I have difficulty believing that. Skimmed maybe, but read, that would have taken days or weeks depending on whether or not you can devote entire days to it.

Your hardware should be able to laugh at hyrule field so without screenshots of your settings I have no idea what's wrong.

1. No idea, LLE should fix it.

2. No idea, never had this problem.

I'd go with 8 gigs of ram and windows 7 64 bit with something as powerful as a 2500k and that video card with 2 gigs of it's own ram. Don't know what to tell you, runs flawlessly on the 64 bit hardware/software. What made the most positive difference for me was giving the sound it's own thread. Ram is cheap these days... 8 gigs for 45 bucks. I just ordered another 2 sticks so I'll have 16 gigs installed. That way I'm ready in case I ever upgrade to a motherboard with quad channel memory.

http://www.newegg.com/Product/Product.as...6820231311

That ram is going in my bedroom low power system. May want this ram for your main system

http://www.newegg.com/Product/Product.as...6820231314

In any case, this is probably the most humorous part of the game I've come across thus far.

.....you do realize that if he buys more ram that will not affect dolphin in any way right?

Expect 100-400MB ram usage for 32 bit dolphin builds depending on the game. And expect 150-600MB ram usage for 64 bit dolphin builds.

Even if he had 2GB that would be more than enough for the OS + dolphin.

I have been researching this for weeks. I did alot of homework before I even began playing to ensure maximum play-ability. Crashes really get to me so I try to get all the settings in place that I can.

(09-28-2011, 12:28 PM)NaturalViolence Wrote: [ -> ]No offense but I have difficulty believing that. Skimmed maybe, but read, that would have taken days or weeks depending on whether or not you can devote entire days to it.

I understand ppl try to act like they research things, but I did as to not waste your time. Your comment was unnecessary and no offense, but your belief is not required for truth.

(09-28-2011, 12:28 PM)NaturalViolence Wrote: [ -> ]1. No idea, LLE should fix it.

2. No idea, never had this problem.

Thank you for that input. I must have a bad dump of my LLE then. I will redump and try again.

Update 1: I was playing Resident Evil 4 and got some random freezes on it as well. I KNOW my old system played that game fine with current settings, so it may not even be a dolphin issue.

Update 2: I lowered the clock settings on my graphics card to sub-normal and the freezes went away. Maybe I have a faulty card...which sucks.

Thanks for all of your help!