Racer's graphics engine/graphics generally + memory

I'm not sure generally or specifically these days but how do modern API's work with regards to graphics memory?

Ie, say I have a large track with 500meg of textures, do they get loaded into RAM/virtual memory at track load, but only accessed by the GPU memory when the render call is made?

Or does the GPU load in as much texture data as possible at track load, and then store it resident on the card?

Or does it manage it intelligently somehow?

Can we for example have a track that is 10km long, and in the first 5km we have 500meg of textures for a desert landscape, then we hit a tunnel, and when we come out the other side there is 5km of city scape with 500meg of textures there.

The GPU isn't going to try load 1gig of textures into it's memory is it?

Obviously the GPU keeps:

Current stored frames, say 20meg, but with triple buffering that might be 60meg in frame buffer alone
Shadow maps, there are 4 x 1024px iirc, so that is ~ 35meg I think
HDR envmap is probably a big user of memory so 512px at 16bit floating point, 4 meg... 32bit would be 8meg.

So right off just straight up running Racer is using about 100meg of GPU memory just to store envmap, shadow maps, frame buffer etc.

So I'm confused, how much video memory can we use up?

Can I author with 1gig of textures but manage the scene in such a way that only 512meg are seen and used by the GFX card at any time (frame), thus I can have plenty of variance across a large track?

Or am I needing to ideally keep all my textures for the entire track in the 512meg, meaning either lower res or less unique textures etc?

In the old days we got AGP to speed texture calls from system RAM to the GFX VRAM so we could basically have faster graphics and nicer graphics too, since old PCI at the time was very slow to access system RAM in the volumes graphics were needing.
So AGP used system memory to speed graphics.
But is that still the same today via PCI-E?

Are there ways to prioritise certain texture data into GPU ram and other into system ram?

Just trying to get a figure on how much memory I have to play with in total... final speed will be determined via actually rendering it to see what the FPS are :D

I guess I can test this by putting loads of 8192x textures (gigs worth so they easily fill my GPU memory) on some boxes and then hide them with LOD, and have the boxes only appear one at a time as I drive along... hmmmm...


Hmm, I'm not sure about the Racer's graphics engine, but I think all textures are loaded to the GPU ram at track loading time. Racer uses OpengGL, and only one texture can be used at a time (well, if multi texturing is used, then more) when rendering something.

I do not know what happens in Racer, if you fill out the GPU ram with textures. Perhaps Racer crashes or perhaps it just loads as many textures as possible and the rest is blank.

Huge open world games like GTA use real time asset loading systems, where assets (meshes, textures etc) are loaded and unloaded dynamically and asynchronously.

As far as I know, you always must "upload" your textures and meshes to the GPU, if you wish to render them.
Hehe, just set up 1gig of textures x 3.

I'll run the first set on a cube near the start point, then the next set on a cube 2km away, and so on.

Then I will turn the cubes off at 500m LOD...

That way I can see the FPS hit when they are in shot, when they disappear, then when the next one appears etc.

OK, well the results are:

Racer.exe in above normal priority.

Racer.exe process uses 120meg of memory.

System memory goes up about 2.5-3gig when I load Racer and my 'mega track' hehe...

Auto exposure off.

Still getting the weird surges in FPS, but above normal seems to reduce the impact of them on FPS. Ie, dips are 50% reduced.

4 planes, each with a 256meg 8192x texture, all visible, another 8 planes with textures hidden by LOD.
4 planes actually visible in view.
110fps, dips to 60fps.

8 planes visible, 4 hidden by LOD.
4 planes actually visible in view.
110fps, dips to 50fps.

12 planes visible, none hidden by LOD.
4 planes actually visible in view.
100fps, dips to 50fps.
8 planes actually visible in view.
90fps, dips to 45fps.
12 planes actually visible in view.
80fps, dips to 40fps.

So it looks like system memory is used to load the textures, and they do go through the system bus to get to the GPU memory at render time, just like back in AGP days, but obviously a LOAD faster.

I'm using 256meg textures but only 3 channels at render, but still even with 2.25gig of texture being actually read/calculated that is 80fps at 1920x1080...

The dipping is really noticeable though, but I guess that is still CPU/process issues at Ruud's end still!?

Generally though you can have loads of texture loaded, but not seen, on models LOD'd off, and it doesn't appear to be costing you much except track folder size and track load time.
There is possibly also a cost to the dipping size for now but I wouldn't want to say that might not just go away with a Racer.exe update at some stage... the GPU/system ram stuff on an i5 2500k and 8gig of system ram with GTX275 1gig seems pretty capable.

Lets put it this way, I suddenly don't feel bad having 512meg of textures for my entire track, with maybe only half that visible at any given time due to LOD or culling of entire blocks of shader!


OK, changed them all to 512x512 tex's...

System ram footprint is now tiny.

FPS dips are about 10fps, and total fps up about 10fps.

So 120fps/110fps range now.

Perhaps the dipping is when what is essentially like system swap filing is going on, but it's the GPU reading data from system RAM?

But that isn't ideal because I've got it on tracks with about 150meg of textures sometimes.

Hmmmm, it'll be interesting to see what happens with the dipping issue. Perhaps it's a sign of bad memory management on the GPU due to Racer.exe!??! or bad memory management by Racer to the system memory!?!?

No idea, but they are interesting results at the extremes haha.

I still think I will generally aim for having 512meg for the entire course but only 256meg rendered at any given frame... then it all fits nicely inside the GPU memory for 756meg+ cards (including shadows, envmap, buffers etc)



RaceDepartment Store

  • Featured
The Podium Hub is the premium core component for the Fanatec® modular steering wheel system. Buy now from Fanatec.com for EUR 199,95 Features Gold anodised aluminium monocoque Ultra sturdy and lightweight space frame design Two connectors for the Podium Advanced Paddle Module (4 buttons + 2...
  • Featured
5.00 star(s) 1 ratings
The ClubSport Steering Wheel Formula V2.5 X is the perfect size and shape for all formula-style and single-seater race cars. Buy now from Fanatec.com for EUR 369,95 Features Officially licensed for Xbox One® and Xbox Series X|S Formula-style steering wheel with a compact diameter of 270 mm...
Monitor Mounting Screw and Spacer Kit includes: M4 x 14mm Hex Screw x 4 M5 x 14mm Hex Screw x 4 M6 x 16mm Hex Screw x 4 M8 x 20mm Hex Screw x 4 M8 Flat Washer x 4 M6 Flat Washer x 4 Rubber washer/spacer x 8 Official Racing Simulator of Alpine F1 Team and Official Flight...
Brake with consistency and confidence with the CSL Pedals Load Cell Kit. You’ll be smashing your personal best laps in no time. Buy now from Fanatec.com for EUR 119,95 FEATURES Load cell brake upgrade for CSL Pedals Heavy steel construction (excluding pedal face) Pedal position can be...
  • Featured
Developed together with BMW M Motorsport, the Podium Steering Wheel BMW M4 GT3 is the actual wheel made for the 2022 BMW M4 GT3 race car. Buy now from Fanatec.com for EUR 1499,95 It doesn’t get more authentic than this. For the first time in sim racing history, a steering wheel has been...
Trak Racer black anodized aluminium add-on side arms for an existing single monitor stand (80mm high x 40mm wide). For monitors and TVs up to 45"" Trak Racer monitor stands suit most monitors on the market with VESA mounting points (75/100/150/200mm), and come with a 3-year warranty. FEATURES...