And what Lee says is basically where my argument "against" the 4GB patch comes in. While in development I have used extremely large textures for Spa67, sometimes over 8000 pixels wide but not as tall, that ended up with Spa67 using more than 2 gb of memory. I don't recall how much more than 2 gb, but I would think something in the ballpark area of 2.5 gb. Add to that that GPL always (!) loads an entire carset of 20 cars (player car + 19 AI) even if you are going for training mode where you are supposedly alone on track. Now I have made some calculations in our dev forums about the memory usage of the individual mods at certain tracks and basically used that as a way to determin how much memory will be available for a track with a certain mod selected. It's sort of reverse engineering to make it useable. I have used 2 gb cards as the yardstick (just happens to be the limit on my cards - honi soit qui mal y pense ...
) for the maximum amount of memory available as I think most cards nowadays have 2 gb with only a few offering 3, 4 or even 6 gb - but those are the high-high end cards mostly. However, I'd recommend anyone who is looking for a new card to get the one with more memory if the clock speeds are the same for a slightly higher price.
Anyway, back to the 2.5 gb of textures. With those 2.5 gb of track textures add the additional up to 500 meg of a car set and you're somewhere around 3 gb total. Now these won't fit into the memory of a 2 gb card (or even two - I'll explain why 2x 2gb doesn't equal 4 gb if someone is interested), but they should still fit into the 32 bit memory size of 3-4 gb that a 32 bit application should be able to address. Now while running the pre-optimized Spa67 with any carset got me occasional stuttering in certain parts of the track. Now what I reckon happens there is that GPL needs to load those textures from disk at that time, ditching others, previously loaded ones in exchange, and then transferring them to the VRAM of your graphics card. It would do the same again at other points around the track. I think I had 2 or 3 major areas where this would happen. Thinking back to the 32 bit addressable memory space one would wonder why that is - after all the entire track + cars + game executables should fit nicely into that 32 bit addressable space, but maybe that's not how GPL operates. My guess, and it is really just that as I haven't tested it yet, is that GPL does not load texture files into the system memory, but directly to the VRAM. The system memory is used for the executables and the 3d models (probably) as they are processed by the CPU, not the GPU (see one of the posts above). So the point of extending the potentially addressable space for GPL seems moot, but again, I'd gladly see reports back on what it does for GPL.
And Dave, your experiences regarding CPUs are what I have noticed as well. In any recent game, my new CPU ecclipses everything I have had before - I can now run Crysis 3 at max details and bling bling (whatever the highest setting is) with no less than 60 fps at all times, which my last CPU (i7-3820) could not, but an ancient title like GPL gets the odd framedrop, where maybe one of my previous CPUs (generally slower in overall performance, but faster in raw speed) performed better. At this time I do not feel the need to overclock it, eventhough I know I could run it crank it up to 4.5 without it breaking a sweat, but don't see the point when everything else works. Plus overclocking an i7 is a bit of a pain in the ... if you want to use the energy saving things built in.
0
