Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Killzone unstable due to memory consumption?
#1
My hardware:

Dell XPS420 (Q6600 @ 2.4ghz, Radeon HD 3870x2, 4gb RAM, Windows 7 x64)

The game Killzone plays pretty much at full speed on this machine (with some *very* specific hacks), but more and more ram is allocated to PCSX2 until it reaches some limit (around 1.5gb?) and the following message appears in the console:-

microVU1: Program cache limit reached.

After that the committed memory drops suddenly by about 500mb, buts starts rising again straight away. Once the limit is reached, the same thing happens over again. Just about every time the game will crash the third time the limit is reached.

Save states don't work in-game either, with the following message appearing every time:-

"Oh noes, out of memory"

It's a real shame because I was having blast with this game right up until this level. I got the game running great and looking great so I'm pretty disappointed that I just can't get past this level.

Kind regards
Dave


PS - these are the very settings I'm using to get Killzone to work

EE settings - all default

VU round mode=positive, VU clamping mode=none otherwise default

All speedhacks enabled except fast DVD, EE cyclerate=3, VU stealing=1

Allow 8-bit textures enabled, Skipdraw=2 or 4 in GSDx settings.

(Skipdraw of 2 allows the game to run normally, but Luger's night vision effect is all messed up. Skipdraw needs to be 4 for Luger's night vision, although still messed up, to work well enough to use ingame. Either of these settings will mess up the menus a little but not so much you can't use them).
Reply

Sponsored links

#2
I'd guess from all the bug reports you've made you would know this by now but it seems you still don't get it?

1) No bug report is valid with speed hacks on
2) GSdx bug reports go in the GSdx thread.

Moved out
[Image: newsig.jpg]
Reply
#3
Congratulations for jumping to two incorrect conclusions in a single post

1. I always test with speedhacks on and off, quite often playing the game at half speed or less to see if the issue is reproducible. In fact, if you see a bug report from me its after at least a couple of solid evening's or a weekend's pure, methodical testing. Instead of trying to shoot down every bug report I file you could instead try to be more constructive?

2. How is this a GSDx bug? its a VU recompiler bug. Can you even read the code?

Regards
Dave
Reply
#4
oh gee, look I got a warning for being "obnoxious and boastful". You must have been talking to my wife ;-)

But seriously, is this the general level around here? I post a solid bug report, put hours into testing everything on two different machines, make 100% sure it is reproducible, trace the code to find out what's going on and then get jumped on by two moderators. Welcome to the community, but don't for gods sake post anything well thought out, informative or useful if it is even vaguely critical of this glorious software.
Reply
#5
Hey, dude--

I understand your frustration,
but you are definitely seeming a bit obnoxious at this point.
PMing a mod may have made a difference, but now it's too late...
(That last post was rather obnoxious.)

Do you understand how the VU relates to the GS?
Reply
#6
I'm not here to make friends, just reporting my findings.

As I understand it, the VU is a programmable floating point vector unit a bit like altivec or SIMD. VU1 is mostly used for triangle T&L (transform and lighting) - so yes, it does relate closely to the GS as it handles a major stage on the pipeline.

But, the VUs can also be used for other calculations, who knows what PS2 programmers might have made use of it for - and from an (albeit) brief glance at the code I gathered the impression that the VU recompiler, where this error message originates, is seperate and distinct from the GSDx code. Could be wrong about that though, I haven't spent much time looking at that.
Reply
#7
(04-29-2012, 07:57 PM)davew_uk Wrote: I'm not here to make friends, just reporting my findings.

That's fine,
but making friends isn't the only reason to be friendly.

Either you're asking for help, or trying to help;
I can't imagine why being friendly is a bad idea in either case...


If it doesn't seem to tie in with the GS in the code, then I see sense in what you say.

Also consider that the code could be wrong, and it's supposed to tie in.
I guess that's what I'm getting at. Smile
Reply
#8
Quote:Either you're asking for help, or trying to help;
I can't imagine why being friendly is a bad idea in either case...

Ok, you're right of course. But it gets my back up if my post is moderated without any understanding of the work that's gone into it.

With regards to the code, I think the VU recompiler code resides in the main PCSX2 executable, and GSDx is a plugin DLL. However I agree that there's any number of ways a bug in the VU recompiler could affect the GS and other code downstream because of the nature of the PS2's rendering pipeline.

[EDIT] redacted my illinformed speculation after reading some more code
Reply




Users browsing this thread: 1 Guest(s)