Performance issues.

Nestor

N
Kijarni said:
The "under deck" issue is probably a simple matter of it not being worth optimizing for. It doesn't matter if the frame rate is lower when you store your ship since you can't do anything in the dock. Why put in code that doesn't do anything
but make the FPS number larger in a situation where the player can't fly or shoot. The issue inside of the station in different. That is a place where improvements to FPS can make a big difference in the experience.

Frustum culling has advantages, although generally at a cost on the CPU side and it's not really compatable with modern GPU card design. It's also not friendly with head mounted displays since people can move their head very quickly. Better to have all the geometry already resident on the GPU ready to be drawn when the viewing direction is sent to the GPU.

GPU performance has two main bottlenecks, polyon performance or pixel performance. Culling out polygons helps with the first, but not with the second. I suspect it's not the polygon count inside the station that causes the major performance hit, but is the pixel shaders being used. Older cards were not optimised to run pixel shaders like the more recent cards. Perhaps FD could rewrite some of the shaders to be less processing heavy on older cards.
Click to expand...

They way frustum culling worked in OpenGL back in 2004 was that the geometry was pushed as vertex buffer objects straight to VRAM and waited there to be drawn. There are visibility tests to be made, but due to the architecture of octrees, getting to the leafs of the tree takes literally a handful of tests. Since the geometry is already stored in vram, there's no bottlenecking on loading/unloading geometry and textures through the PCIE bus. Ergo, slow or fast movements have no effect on the overall performance, as visibility tests are made each frame and geometry is already waiting to be drawn.

As for the 660 being an 'older card', please. GTX660 is the recommended card for GTA5. Comparison between the graphical fidelity and complexity of the two titles I'll leave to the public at large.
 

SCADVID

SCADVID
Nestor said:
Since the geometry is already stored in vram, there's no bottlenecking on loading/unloading geometry and textures through the PCIE bus. Ergo, slow or fast movements have no effect on the overall performance, as visibility tests are made each frame and geometry is already waiting to be drawn.
Click to expand...

By 2007 (FEAR is a great example of this) texture offloads would cause bottlenecks, especially when going from GPU to CPU sectors and back to GPU. It caused annoying glitches, especially when turning corners as new textures were on/off loaded.

2004 the texture sizes were like 512x512 bitmaps (no pixel shading). By 2008 they jumped to 4096x4096 for environmental maps, and 2056x2056 for character materials (now for pixel shading). Sizes like that can cause on and offload jitter -- try loading WoW without a SSD drive with WoD and the new file system, texture loads are painfully slow (the geometry is there, but the game is still loading the textures 15 seconds later...the garrisons are horrible with it).
 

Nestor

N
Of course, but you don't have to slap 4k textures on everything. In fact, with large scale models, like the space station, where you actually very rarely look at stuff from a close distance, you can use low res textures and they still look very nice from the distance.

But that's beside the point. Right now we can all agree that the whole station, with its textures is loaded. And it's drawn. What I'm looking for, is that it is not being drawn while invisible (occulded by the bay's door). There's no point in unloading it. We're not trying to optimize memory usage, but the GPU load in players' idle time.
 
You must log in or register to reply here.
Back
Top Bottom