Make error, nobody lists it anywhere.

[klauss]

Or, come up with a database of chipsets and settings that work on them, and use a simple script that queries the OGL for the chipset's name and checks agianst such database.

[safemode]

yea, but it's more than just a chipset that makes up the settings that are used. You need to consider cpu speed, ram, video ram.

That quickly becomes a complicated database. And then it becomes completely user-contrib reliant. What i'd like to see is a python scripted mission file that starts off by creating the worse case scenario for VS (5 simulated systems , shit ton of ships and planets and bases in the active system, fighting and warps going on). Highest settings are used here for everything. framerate is measured and then the script starts removing things in an orderly fashion until framerate rises to acceptable. First thing it does is reduce number of simulated systems, if this has no effect, it reverses the change and moves to another such as reducing the number of units or shader level. If no amount of reduction to minimum levels can bring the framerate above acceptable then it fails with a message to try reducing the resolution and start again or the hardware just can't play the game at acceptable levels. It'll still let the user play, but they do so knowing their computer sucks and so expect the performance to suck.

[klauss]

But that's even more work than the database, and very difficult to pull off.

Because there are way too many factors involved - system load not the least of them.

With the database, you attack each aspect separately. Figure out the amount of RAM on the GPU, and tweak textures accordingly. Figure out the chipset's capabilities, and tweak shaders/LODs accordingly. Figure out the chipset's muscle and tweak screen resolution accordingly. Etc...

Then the same for CPU: figure out the amount of system RAM and tweak... ram-related parameters accordingly. Figure out the CPU's muscle and tweak physics parameters accordingly. Etc...

It's by far easier to get right than doing one benchmark that does it all.
And people will contribute to the database... whereas they won't contribute to the benchmark.

[chuck_starchaser]

I think all that's needed is to query the brand and model of the chip, and if it's garbage, to politely say to the user "you're either a cheap bastard or a basket case idiot. [OK]", and exit(-1). Why do we have to "support" Intel? Do they support us? I mean, what do we have to gain from supporting garbage hardware? The game is going to look like crap AND/OR be unplayably slow; and then many morons will blame us for it. Why? Just educate people, instead.

[klauss]

Come on chuck... I do think intel is without shame for shipping that crappy chipset and calling it a GPU, which it is not by modern standards.

But we're not supporting intel. We're supporting our players, those who happen to be stuck with intel chipsets. Like laptops, for instance.

I know we can do better on the GMA than we currently do. I'm not so sure we can get to playable levels without major artwork assets (LOADS and LOADS of LODs - no typo there).

If it turns out to be too much work supporting it in full, at least we can do our best. And setting up a database of vegafig settings that work on X and Y hardware isn't that much work. I'm not proposing loads of engine changes, only using our current LODding capabilities to perform better on crappy hardware.

[shenle]

We're supporting our players, those who happen to be stuck with intel chipsets. Like laptops, for instance.

Precisely. I applaud this attitude.

I was recently in the market for a laptop. On a budget, too. I was lucky to find a sub-$400 one with something better than an intel chipset - but there aren't many, if any others at all. You gave to get to machines in the $7-800 range to get better, and over $1000 to have real choice. For someone who is a casual gamer like me spending this amount of money just to get a better video chipset is, however desirable, impractical.

[safemode]

all chipsets experience a slowdown when a base or planet fills the majority of the screen. I suspect this is either a problem with our gl configuration interacting with our models. Either due to the size of them or due to not culling correctly or issues with the models themselves hidden from the naked eye but causing gl to flip out. perhaps it's something else related to maybe having too small of a sim frame and calling draw much more rapidly in that situation than normal.

though with my 6600, i avg in the 100+ range in empty space, and will slow down to roughly 30 close to bases and planets, and depending on what is going on, possibly dip lower.

[chuck_starchaser]

It makes perfect sense there'd be a slowdown looking at something up-close. It increases overdraw by 1.0 versus looking at empty space. Klauss would know better than me what the current, average overdraw is, but I would suspect it's probably around 2 to 2.5 without looking at anything, and so it would go to 3 to 3.5 with a planet or station extending over the screen.
And if the planet has a second sphere mesh for atmosphere, that would increase overdraw by 2.0, to around 4 to 4.5. Way too high, IMO.
Having said that, fps dropping from 100 to 30 would indicate the problem is more than just overdraw (frame-buffer band-width) and possibly related to texture fetch bandwidth, or...
Question: What's your FSAA setting? Are you perhaps forcing FSAA in the driver? If so, try turning it off and see if the problem persists. I think I remember the 6600 being slow with FSAA.

[klauss]

@chuck: your overdraw numbers are pretty much right, but they don't vary that much with object distance. Thing is, there's a fixed 3x overdraw (IIRC) because of the triple-stage drawing loop: clear the z buffer, render the background (1x draw), render planets (2x draw if they're full screen), clear z (2.1x draw - z clears are fast), render far ships (usually nothing), clear z (2.5x draw), draw near ships (3.0x draw if you're near a station), clear z (3.1x draw), draw cockpit (none usually, but 4.0x draw worst case)

So, worst case is 4x overdraw.

The TNT could handle that amount of overdraw, so I'm not worried. Overdraw is a problem when it gets to much higher levels, 10x or 20x, which happens with techniques like stencil shadows, or perhaps badly abused transparency (rendering in painter order).

Planets with atmospheres (not many atm) right now are adding 1x overdraw, and it may be bigger than what's visible.

It's possible that when you get really close, the atmosphere's cone (it's a cone right now, will be a sphere with my shader) the atmosphere redraws the entire screen.

@safemode: In any case, the slowdown comes from the CPU, not the GPU. I've profiled it.
I'm attaching the profiling results. That one is a sampling from me staring at a station from up close. If I go farther, CPU load decreases, and profile output stays away from GL libraries. The closer I get, the more the GL library struggles. Which makes NO sense, it's the GPU the one drawing more pixels, the GL library should be doing the exact same amount of work, so I bet something we think is being done in hardware is actually being done by the CPU - I'm thinking, perhaps primitive clipping.

It could be the case that the shield bubble is being rendered at all times, not only when it's necessary, because the shield bubble is far bigger than the station and would start clipping triangles earlier, if clipping is done on the CPU, then it would start loading the CPU more and more. Furthermore, shields are spheres, and spheres have LODs, so the closer I get, the more triangles the shield sphere gets. So I'll test my hypothesis and fix the bug if it proves right.

[chuck_starchaser]

Very interesting, that profiling result (though I don't understand the attached file; well, I don't know what all those libs are).

@chuck: your overdraw numbers are pretty much right, but they don't vary that much with object distance.

Well, overdraw would vary with distance in the sense that an object occupies a larger % of the screen as you get closer.
Suppose you're looking down on a station close enough that it takes up the whole screen, and behind the station there's a planet, with an atmosphere which would also span the whole screen if the station wasn't blocking your view. There you've got an overdraw incremental of 3, for a grand-total of 5 or 6.

So, worst case is 4x overdraw.

The TNT could handle that amount of overdraw, so I'm not worried. Overdraw is a problem when it gets to much higher levels, 10x or 20x, which happens with techniques like stencil shadows, or perhaps badly abused transparency (rendering in painter order).

Well, I read somewhere that a good magical number to aim for was 3 or less, for overdraw; but I'm not sure what the rationale was.
It probably depends on other factors; foremost the kind of overdraw, meaning with or without z test, with or without blending.
BTW, if we're doing planets in front-to-back order, I think we might gain by reversing the order and turning of z-testing, as there would probably NEVER be a large view of a planet painted over a large view of another planet. Turning off z-tests would make planet rendering fly.

Planets with atmospheres (not many atm) right now are adding 1x overdraw, and it may be bigger than what's visible.

Possibly. I know the billboards that stars are painted on are like 3 times larger than they need to be.

It's possible that when you get really close, the atmosphere's cone (it's a cone right now, will be a sphere with my shader) the atmosphere redraws the entire screen.

That's what I would expect. We should really either render planets, atmos and all, onto a single sphere, or make them into impostors, IMO.

[klauss]

Very interesting, that profiling result (though I don't understand the attached file; well, I don't know what all those libs are).

Probably system libs... openal is competing with opengl in terms of cpu usage too, which is shocking
But it doesn't seem to contribute to slowness (there's a background thread loading music tracks, I bet that openal library there comes from that thread).

So, worst case is 4x overdraw.

The TNT could handle that amount of overdraw, so I'm not worried. Overdraw is a problem when it gets to much higher levels, 10x or 20x, which happens with techniques like stencil shadows, or perhaps badly abused transparency (rendering in painter order).

Well, I read somewhere that a good magical number to aim for was 3 or less, for overdraw; but I'm not sure what the rationale was.

Probably wishful thinking
And probably for applications that don't need our multistage rendering methods, which add considerable overdraw (but considerable quality just as well).

It probably depends on other factors; foremost the kind of overdraw, meaning with or without z test, with or without blending.
BTW, if we're doing planets in front-to-back order, I think we might gain by reversing the order and turning of z-testing, as there would probably NEVER be a large view of a planet painted over a large view of another planet. Turning off z-tests would make planet rendering fly.

It was like that before, it doesn't work... rings are impossible to render correctly like that.
Besides, in the future, when planet shaders are more complex, having a z-write pass will help keep shaders at bay.

It's possible that when you get really close, the atmosphere's cone (it's a cone right now, will be a sphere with my shader) the atmosphere redraws the entire screen.

That's what I would expect. We should really either render planets, atmos and all, onto a single sphere, or make them into impostors, IMO.

Yep, totally. But that requires a lot of engine support.

[safemode]

klauss, your profile output is confusing... why are you in kernel mode 39% of the time ? that's very weird. Almost like we are polling for interrupts rapidly and context switching like a mofo

What happens when you enable vsync ?

edit: you will notice a slowing down of startup with vsync, as we use GL to load up dds textures and vsync slows down access to the card considerably last time i checked ...

[klauss]

Hm... I could make it not update the status text so often, so that with or without vsync loading is fast

BTW: spending too much time in kernel land may be a driver issue. Texture thrashing, for instance... but I have no reason to think there might be texture thrasing, it was a rather simple scene.

It may be made all the more confusing by the fact that I couldn't get oprofile to work with true performance counters, so it's working with timer interrupts. That's way too imprecise, but I had to manage.