Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

God of War speed issues #862

Closed
hrydgard opened this issue Mar 4, 2013 · 24 comments
Closed

God of War speed issues #862

hrydgard opened this issue Mar 4, 2013 · 24 comments

Comments

@hrydgard
Copy link
Owner

hrydgard commented Mar 4, 2013

Both games currently have display list sync/interrupt issues, and as a result appear to draw every frame a large number of times. For example, Ghosts of Sparta currently pushes half a million vertices/frame in 9000 draw calls at the title screen, which is clearly absurd.

Also, it seems that it aggressively streams textures from RAM into VRAM like a PS2 game. This causes us to redecode tens of textures every frame...

@hrydgard
Copy link
Owner Author

hrydgard commented Mar 4, 2013

I had a go at trying to merge #322 to see if it would help, but it "blocks the thread on drawsync". I could have made some mistakes though, there are quite a few conflicts now...

@unknownbrackets
Copy link
Collaborator

It did that for me a lot too. It must be blocking in cases it shouldn't...

-[Unknown]

@hrydgard
Copy link
Owner Author

hrydgard commented Mar 4, 2013

Btw, i looked at some logs and saw that it indeed is drawing everything ~8 times per frame, which would explain the speed issue quite nicely :P

@unknownbrackets
Copy link
Collaborator

Heh, that would. I don't have this game, I just meant the dlist-rewrite.

I think the dlist-rewrite will probably matter a lot, once we get syncing working right. We might also need to time the interrupts correctly - e.g. trigger them based on # of cycles executed * gpu freq + unstall/continue time. It might be rendering so much just because the interrupts are signalling so often.

Ultimately we probably need to do that anyway - GPU on its own thread or not, if it's faster than the PSP's it may cause issues like this. But it shouldn't matter if it renders faster as long as the cpu doesn't know until it should've finished... unless the game is really evil...

-[Unknown]

@hrydgard
Copy link
Owner Author

hrydgard commented Mar 5, 2013

How about this: When a DL is sent (or stall address updated) we immediately execute it but also keep track of some sort of simple estimate of how long it took (say 1 cycle for state updates, then 10 cycles per triangle or whatever). We then schedule an event in that amount of time into the future, and when that happens we mark the DL as done etc. If signals happen in the DL, we schedule events for them too, at their estimated times.

Btw, if you want to see what the PSP can do graphically, get God of War - Ghost of Sparta. It looks like some of the best looking PS2 games, they're really maxing the thing out :)

@unknownbrackets
Copy link
Collaborator

Yeah, that's what I was thinking. I hope it doesn't hurt displaylist processing speed too much, though...

Heh, yeah, it's not an RPG but it must be popular for some reason, heh. The screenshots do look pretty good.

-[Unknown]

@unknownbrackets
Copy link
Collaborator

When you say per triangle, do you mean count * 10 in GE_CMD_PRIM? Also, any idea how cycles might match up the the CPU clock, especially when its frequency is changed?

I think we could just add a parameter to __GeTriggerInterrupt() or similar and schedule an event.

Also, does God of War use any signals like wait or pause? If it doesn't, then it's probably based on ListSync or DrawSync. If it does, it could be either or both.

-[Unknown]

@hrydgard
Copy link
Owner Author

hrydgard commented Apr 2, 2013

Yeah, exactly. Of course 10 cycles / triangle is just a wild guess and I'm sure we could do a better approximation (for example, we could add more cycles for every light that's enabled, etc).

I think it's based on drawsync but I'll check again later.

@unknownbrackets
Copy link
Collaborator

Partially fixed/improved now, but could probably use more fine tuning, and there's probably more performance gains to be had.

-[Unknown]

@KingPepper
Copy link

Yes thanks for the improvements has made quite a difference, in the actual game play, but in places the game seems to slow right down, as in the logos right at the beginning and cut scenes which are mostly black screens but with writing that seem to flicker, running between 8-13 VPS, then as soon as the cut scene finishes shoots back up to 60 VPS again.

Edit: Here is the latest complete Log from Start to Freeze.....http://www.mediafire.com/download.php?i9z8km55c525m53

@unknownbrackets
Copy link
Collaborator

For the record, I tried timing and adding cycle delays to a bunch of the functions Fat Princess (which I think has the same basic problem) was calling to try to make it not draw as frequently, and it did not help, not even slightly. It seems completely bound by the GE waits...

I think we need to add additional delays to certain GE ops like block transfers maybe. It'd be helpful to know which commands are most common in games with this problem...

I also wonder if we could do a heuristic to detect this (at least to have a better idea of which games it's really affecting)? A changed framebuf of 480x272 with the same numFrames? Probably will catch special effects? Hmm...

-[Unknown]

@tamagotchi
Copy link

on mobile its still slow

@srdjan1995
Copy link

Please, make God of War games work better.. They need some sort of fixing, because even on my quad core CPU game doesn't work at full speed.. Also, i noticed that fall of VPS causes FPS to rise, and vice versa.. What can that? Soon i will upload video, and you will see what im talking about.. I have enable both VPS and FPS counters, and you will see what i'm bubling about here..

@srdjan1995
Copy link

Anyone saw my damn comment? God, i can't belive it.. U can atleast answer dudes..

@Nezarn
Copy link
Contributor

Nezarn commented Jun 27, 2013

@srdjan1995 it doesnt help the devs if you're begging and impatient, if you cant wait for them to fix it, then start learning c++ and fix it yourself, or play it on your psp or jpcsp.

@srdjan1995
Copy link

@Nezarn, i asked why no one at least answers.. [Unknown] already has performance fix, atleast he told me so, but it breaks other games.. I asked him to give me that build so i can test it, but he doesn't even want to answer me with NO if ih don't want to give it to me.. I already finished Ghost of Sparta on JPCSP, but many people ask them to fix this game.. They fixed many other games people asked, but they don't wanna fix this one. Why is that?

@Ritori
Copy link

Ritori commented Jun 27, 2013

@srdjan1995 be patient :)
they will fix it later it related to this #2010 issue
I dont know how to fix this but i think this maybe hard to be fix so be patient :)

@srdjan1995
Copy link

@Ritori I will wait, but alteast some of devs could have said something about it..

@unknownbrackets
Copy link
Collaborator

This is also mentioned in #2010, but Tales of Phantasia X hits a similar situation where it renders > 60 fps. I don't think it means to, but I'm not sure. The effect it's trying to produce doesn't render correctly anyway...

This happens when entering a battle from the map, for example. It reproduces in the demo as well. It is not improved by the workaround in #2542.

Also noted in that bug, the game seems to really render > 180 fps on a PSP, ignoring vblanks. That's a shame. But I'm not confident in my tests. I'm worried that fixing this accurately without a hack would require all HLE functions, memory operations, cache instructions, etc. to consume the proper number of cycles, and then it would still be slower than it has any good reason to be.

-[Unknown]

@srdjan1995
Copy link

I enabled force 60 FPS hack, but in game when fighting sound is choppy and VPS is not 60, but FPS is 60, and cuz of that game is still not working properly.. I don't belive my CPU is problem, i have an AMD Athlon II X4 640 3,29GHz (OC'ed).. Also, i have an NVIDIA GeForce XFX GT 240 512MB GDDR5, and in nvidia control panel I enabled Threaded Optimisation.. I realy belive my PC is not problem, but i don't know.. What do u guys think?

@unknownbrackets
Copy link
Collaborator

We now have this hack enabled by default, but I'm not sure if it's causing issues in any games (I think it is not.)

I could've been incorrect in some of my tests, or perhaps my method of testing affected it, but it seemed like this was rendering easily 120 FPS (in the menu) on an actual PSP.

This game is still very demanding, but maybe it makes sense to close this issue without any specific areas of investigation?

@srdjan1995 has the performance improved at all? I improved the hack to hopefully reduce choppiness of sound. It sounds like your CPU and card should theoretically be able to handle it, but enabling "multithreaded" may improve it for you further.

-[Unknown]

@solarmystic
Copy link
Contributor

@unknownbrackets

Certain games (like Gundam VS Gundam Next Plus, which runs at 60 FPS natively) behave erratically (strange slowdowns and jerkiness) when the "Force max 60 FPS" hack is on, it's not a good idea to have it always on by default.

Also, overall performance in GOW has declined on lower end rigs like mine for quite a bit now (since emulation of the game has been made even more accurate with added effects etc). The only great equalizer for this game is to reduce the CPU Frequency to 100 MHz or even lower which will make it run at a a lower variable internal FPS (30-60, instead of fixed 60 like it does).

TL:DR
Both Force max 60 FPS and Changing the CPU Clock to x<111 MHz are still required to run this game smoothly on lower end machines like mine (Core 2 Duo 2.8 GHz, ATI Mobility Radeon 4670). Don't even start with Android devices and phones.

@unknownbrackets
Copy link
Collaborator

It's been on by default for some time now:
https://github.com/hrydgard/ppsspp/blame/49983fa1e451060041c53e99a9ccc030ea760aa6/Core/Config.cpp#L156

Well, I'm just saying that this issue was opened with a direction: it's drawing too much. That's actionable. But the action has been taken. Now it's directionless, which doesn't make for a good bug. For sure this will always be a demanding game.

-[Unknown]

@hrydgard
Copy link
Owner Author

These games require some serious work on graphics performance, they use the GPU in very unfriendly ways, and they use it to the max. I have some preliminary designs in my head for a large reworking of the graphics system allowing us to do a lot more clever reorganization of the command stream making things friendly for modern GPUs / OpenGL, but that's a long way off and will only go so far. The PSP maxed out is pretty powerful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants