(06-10-2012, 11:29 AM)admin89 Wrote: [ -> ]E5300 @ 3.6Ghz (i could oc to 3.9Ghz but the game run more than full speed at 3.6Ghz so i don't need to go any further)
3x IR (1080p) , no AA , 16x AF
Metroid Prime : 35-60FPS (EFB to Ram)
Metroid Prime : 40-60FPS (EFB to texture)
I think you should oc your CPU
I need to get a better cooling solution for my rig before I even consider overclocking.
Quote:It's because of SETI@Home and poclbm, programs I run continuously in the background that use the graphics card to perform calculations, specifically because the graphics card does it much, much faster than the cpu does.
I didn't consider them as possibly being at fault earlier because they automatically suspend themselves when the card is being used for its actual purpose, so I assumed they they did so when Dolphin was run as well.
poclbm does not suspend its activities when Dolphin is running, so when Dolphin and poclbm are both running, they are fighting for control of the graphics card, and poclbm wins. I do not know why this happens. I also don't know why it's only apparent when EFB is copied to RAM, and no other settings have any effect. What I do know is that this is the only time I have seen where a graphics-intensive program (AKA game) such as Dolphin does not trigger poclbm to suspend. In any case, closing poclbm when running Dolphin, I have a framerate of ~33fps on EFB->RAM playing MPT:MP1 with the settings as in my previous post.
Simple. It's choking your memory bandwidth. Unfortunately there is no magic way to limit the amount of memory bandwidth that individual applications use.
(06-10-2012, 12:36 PM)NaturalViolence Wrote: [ -> ]Quote:It's because of SETI@Home and poclbm, programs I run continuously in the background that use the graphics card to perform calculations, specifically because the graphics card does it much, much faster than the cpu does.
I didn't consider them as possibly being at fault earlier because they automatically suspend themselves when the card is being used for its actual purpose, so I assumed they they did so when Dolphin was run as well.
poclbm does not suspend its activities when Dolphin is running, so when Dolphin and poclbm are both running, they are fighting for control of the graphics card, and poclbm wins. I do not know why this happens. I also don't know why it's only apparent when EFB is copied to RAM, and no other settings have any effect. What I do know is that this is the only time I have seen where a graphics-intensive program (AKA game) such as Dolphin does not trigger poclbm to suspend. In any case, closing poclbm when running Dolphin, I have a framerate of ~33fps on EFB->RAM playing MPT:MP1 with the settings as in my previous post.
Simple. It's choking your memory bandwidth. Unfortunately there is no magic way to limit the amount of memory bandwidth that individual applications use.
I know
that. That's obvious. What I don't know is why they aren't automagically suspending themselves when I run Dolphin, as they do when I run any other graphics-intensive program.
Don't know. We've seen many cases of video drivers not picking up dolphin as a 3D application and thus not switching to 3D clock speeds or switching to the dedicated GPU but if I recall this problem only happens with the d3d9 backend.
Does it occur with all 3 video backends?
(06-10-2012, 01:47 PM)NaturalViolence Wrote: [ -> ]Don't know. We've seen many cases of video drivers not picking up dolphin as a 3D application and thus not switching to 3D clock speeds or switching to the dedicated GPU but if I recall this problem only happens with the d3d9 backend.
Does it occur with all 3 video backends?
My specific problem? Yes, it happens regardless of which backend I use.
I'm too busy to do it myself, and I would be surprised if anyone else cared, but I'm sure it's possible to find out what causes poclbm to suspend itself and why running Dolphin doesn't do it by looking at poclbm's source:
https://github.com/m0mchil/poclbm. At a guess, I'd say that poclbm is set up to use all available (graphic card) memory, and PC games grab a specified amount at startup, so poclbm can only access what the game doesn't grab and that's why it hasn't affected my rig's performance with PC games. Which would mean Dolphin doesn't grab a specified amount and instead it too operates on what's available.
Or, when you set EFB copies to texture, it triggers the application to stop doing what it does, hence reasonable dolphin speed, but when you set it to RAM, you are using less of the GPU, so not enough to trigger the application shutting down, so it stays running, and steals all the GPU power that dolphin is wanting.
(06-10-2012, 09:30 PM)AnyOldName3 Wrote: [ -> ]Or, when you set EFB copies to texture, it triggers the application to stop doing what it does, hence reasonable dolphin speed, but when you set it to RAM, you are using less of the GPU, so not enough to trigger the application shutting down, so it stays running, and steals all the GPU power that dolphin is wanting.
Maybe. I haven't looked exhaustively at the source for either, so all I can do is guess.
(06-07-2012, 05:18 AM)eyeonus Wrote: [ -> ]The way I implemented my idea isn't the best- there's no way to make it not switch between EFB->Texture and EFB->RAM except by disabling it, but I think it's a useful idea. Possibly a developer with a better understanding of the code could implement it better.
It would prolly be better to find out to which address the "important" texture which needs efb2ram is being copied. You would check that in
http://code.google.com/p/dolphin-emu/source/browse/Source/Plugins/Plugin_VideoOGL/Src/TextureCache.cpp#270 , i.e. keep a list of texture addresses that this func is being called with and dynamically disable/enable bCopyEFBToTexture for those "important" textures (you'll need to dynamically disable/enable that in TextureCacheBase::Load then, too!). That might work, or it might not work at all, depending on whether the game actually has any "unimportant" textures.
Anyway, I guess the general developers' opinion on hacks like this has been elaborated enough in this thread, so that's all I'll help you with :p
If the hack can make todays games work better and much faster, it is the right thing to do. The best accuracy is completely useless if nobody can actually play and enjoy the games because their hardware is to slow, which applies to LLE audio by the way.
It would be so great to see games that require EFB to RAM to be playable on a real world system with a reasonable speed and efficiency should be as equally important as accuracy.