Closed thedax closed 9 years ago
What do tools say your VRAM usage looks like when this happens? It doesn't happen at 3x, right?
-[Unknown]
GPU-Z reports 340MB usage, but I also have a web browser and VLC open (and Aero Glass turned on), and my GTX 670 has 2 GB of video memory.
It happens at 5x and higher. 4x and below are fine.
Maybe the framebuffer size estimation is guessing 1000+ and your card won't do > 4000x4000 or something? At least I just saw a game where it was guessing ~900 for 1x. I don't know what the w/h limits would be.
-[Unknown]
Not sure if it's that, either. I ran a few other games at even higher resolutions, and they seemed to have all of their graphics intact:
Would there be a more definitive way to check what my GPU's limits are?
Throw in some checks in the code that makes sure it doesn't try to create framebuffers above 4096x4096 or something, and see if they trigger.
I'd reckon that an ultra modern card like the GTX 670 shouldn't have any issues with up to 16384x16384 sizes like older cards have. Even my 4670 HD supports up to 8192x8192 sizes.
Anyway, I think this issue is somewhat related to the disappearing HUD issue in another game (GTA Chinatown Wars). In that game the HUD disappears if the rendering resolution is set to 3x or higher, with both Buffered or Non buffered rendering.
2x Rendering Resolution
3x Rendering Resolution
Are these things still happening with the new framebuffer size estimation?
If you use the GE debugger, what size is the framebuffer (right larger preview), especially for the black elements?
-[Unknown]
I'll check momentarily.
It's still happening. At 5x it's using 2400x1360 as the framebuffer size for the black items. Should I gather up the info from the tabs?
Hmm, so that's standard size. And it doesn't log creating any additional FBOs at larger sizes (like for effects)?
-[Unknown]
When looking at the info log, no, it just seems to create them in this size when stuff begins to disappear:
59:54:634 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1970 Destroying FBO for 00000000 : 480 x 272 x 1
59:54:634 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1970 Destroying FBO for 00044000 : 480 x 272 x 1
59:54:634 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1970 Destroying FBO for 000d4000 : 64 x 64 x 0
59:54:634 idle0 I[SCEGE]: GLES\Framebuffer.cpp:1970 Destroying FBO for 000cc000 : 128 x 128 x 0
59:54:663 user_main I[SCEGE]: GLES\Framebuffer.cpp:962 Creating FBO for 00000000 : 480 x 272 x 1
59:54:664 user_main I[SCEGE]: GLES\Framebuffer.cpp:962 Creating FBO for 000d4000 : 64 x 64 x 1
59:54:665 user_main I[SCEGE]: GLES\Framebuffer.cpp:962 Creating FBO for 000cc000 : 128 x 128 x 2
Should I grab a debug log?
I don't think a debug log is gonna tell us anything, unfortunately.
At 5x, do you see it rendering the minimap in the GE debugger? I recommend doing it at 1x or something, and noting the texture address, and then breaking on that texture address at 5x. I'm guessing the texture will be blank?
-[Unknown]
I don't have that Grand Theft Auto game, so I'll have to check with Outrun.
Yes, I see it rendering the speedometer, as in, the red square from the GE debugger moves to the position the speedometer is in, but it draws it as blank. However, the preview window on the left is not blank.
Hmm, and it's a regular texture, not render-to-tex. Guessing texture scaling is off.
Does it have mipmap levels defined?
-[Unknown]
How can I tell?
In the latest version, it will have "Level +" button. Also, there will be addresses for the Texture L1 addr, etc. values under Texture.
Possibly, it has set a texture level incorrectly, and it would normally never be used so it doesn't matter, but at 5x it's getting used... or something? Although, it ought to be magnifying... maybe it's a max lod or something issue.
-[Unknown]
@unknownbrackets: The speedometer texture has 5 levels defined (though the level -/+ buttons are greyed out):
Texture L0 addr 09508070, w=128 Texture L1 addr 09558630, w=32 Texture L2 addr 09558730, w=32 Texture L3 addr 095587b0, w=32 Texture L4 addr 095587f0, w=32 Texture L5 addr 04131880, w=16 Texture L6 addr 00000000, w=0 Texture L7 addr 00000000, w=0 Texture L0 size 128x128 Texture L1 size 32x16 Texture L2 size 32x8 Texture L3 size 32x4 Texture L4 size 32x2 Texture L5 size 16x2 Texture L6 size 1x1 Texture L7 size 1x1
The same error occurs on D3D9 even at lower resolutions (2x, ingame and game menu, on a Nvidia 9600M GT).
Fixed, and with https://github.com/hrydgard/ppsspp/commit/eaa1f0c23d3af5a6b2ca9f206f31e737588228e3 the skies work better.
Still happens for me on the latest build, 0.9.9-1571-g19b92a3.
Edit: Sorry for the lack of info. I'm still using my Geforce 670 2GB, with driver 347.09, Windows 7. I wonder if this is just another case of only me experiencing it..
Does this still happen for higher render resolutions than 5x? It's possible that it may have been viewport related, especially if it affected different devices more than others (e.g. not @hrydgard.)
-[Unknown]
No, it's fixed for me now. The viewport changes were the solution.
If the rendering resolution is set to 5x or higher, the following two problems occur:
How it's supposed to look:
How it's supposed to look:
As reported on the forums.