I've found some launch options that you peeps might want to test:

-nosrgb : disables SRGB (limits variety of colors) results in flatter/smoother colors, and brighter lighting
-nouserclip : disables user clip planes and enables fast clipping (I experienced a fps boost with this)
-nops2b : uses pixel shaders 2.0 instead of 2.0b, reduces fps impact of some shaders
-softparticlesdefaultoff : disable depth blending for particles and sprites

Please don't use these settings with my config. I already set these to optimal values in my main config and maxframes.cfg.

Main offenders: r_lod 2 (sets all models lod 2, even if they can go down to a lower lod, use r_rootlod 2 instead and set r_lod to -1), blink_duration 0 (doesn't do anything except divide by zero and possibly cause some errors/memory leaks), g_ragdoll_fadespeed 0 (this is the rate at which the ragdoll fades out, if it is 0 then it just takes up memory trying to do the impossible fade task per frame, though this might have been fixed in Tough Break), and I thought violence_hgibs 0 enabled low violence mode, which is worse for performance.

It is better to remove any extra configs you have for graphics and just suggest values to me. They might be ruining performance.

I know, but most ragdolls disabling configs get a value wrong and cause a memory leak (possibly fixed in Tough Break). I wanted to make sure what values they were using.

How did you remove gibs and ragdolls?

What is LOD tweak?

And I recommend using the highest dxlevel supported by your card. But it comes down to what the benchmarks say, and personal preference. There are some things in dx8 that hurt performance depending on your specs. It makes up for it by disabling some effects not supported by it, but I think most of the important effects can be disabled in dx9 anyway.

Hm, so I guess it comes down to benchmarking it with some perf tool.

Yeah, it was frustrating, but I'm glad it was sorted out. Sorry about that whole social drama thing in #111, I was just kind of frustrated from our conversation.

Anyway, the thing I was asking was the StackOverflow post's claim about fast clears, saying that glClear actually saves write and read time, on any GPU, not just Maxwell and Pascal.

Oh ok, sorry. I see. You're right then. I'd like to thank you for walking me through it. I was missing the deferred vs immediate mode bit and why it would matter.

Could you explain this too? https://stackoverflow.com/questions/37335281/is-glcleargl-color-buffer-bit-preferred-before-a-whole-frame-buffer-overwritte/37336947#37336947

Excuse you, I have a Hale's Own Text Editor and I'm proud!

Setsul, this isn't going to be worth my time if you aren't willing to understand what I say, nor if you are going to discuss these things in a non-pretentious manner. But, that's not what I meant. Here's the source I meant: http://www.seas.upenn.edu/~pcozzi/OpenGLInsights/OpenGLInsights-TileBasedArchitectures.pdf (23.3 on page 5 or 326 and 23.4 on the next page)

I've tried to remain as friendly as possible but Setsul's behavior and discussion habits makes it quite hard.

Thanks! I'm not a guy though :(

I've been saying the same thing over and over, just in different ways so you could understand.

Drivers skip reading all buffers if you use glClear. And it might take a bit to find the link, I'm trying to figure what keywords to use. It might also be on ASM or IEEE so I'll have to look there too if I don't find it from googling it.

I believe it is in materials\sprites\crosshairs.vtf in the textures vpk.

Stencil and depth buffer don't need to be dealt with for the driver to understand that it can skip reading buffer.
It is faster and does this only on tiled renderers because the write is faster on GPUs with tiled rendering.

I'm trying to find the link, but you are obviously misunderstanding what I'm saying.

Let me give you a simple example before I find the link. Let's say you are rendering a simple UI. That UI has a few buttons, and something just triggered a hover effect on one of the buttons. So you would update that part of the UI. The GPU has to read the previous buffer to draw the rest of the UI that you didn't update.

But lets say your draw is covering every pixel. The GPU doesn't know that this draw will cover every pixel, so it will still read the previous buffer, assuming that you won't update every pixel and expect what you drew last to stay there. If you call glClear, the GPU knows that it won't have to read the previous buffer because you've cleared the color buffer. This writing to the color buffer will be faster than the read.

It has a maxframes addon which gives similar poor visual quality like Comanglia's and better FPS. Though I think it looks better than Comanglia's even with the maxframes addon.

Sorry, but what you just refuted was not at all what I said. You're skipping crucial information, one of the most important is that the driver will preemptively load the previous buffer because it doesn't know if your next draw is going to cover every pixel. I never said the driver knows where things will be rendered, I am saying because it doesn't know, it does this. Also, you seem to be confused where the clear takes place. You're clearing for the next frame, to prevent the driver from reading the buffer from the previous one. The write that clearing does is faster than reading the previous frame on the modern hardware.

Initialize a buffer? You can only clear present buffers. I think you're misunderstanding what buffer clearing does.

AFAIK, there is no Source cvar that makes it invalidate the buffer per frame (with some instruction like glInvalidateFramebuffer, don't know what the DirectX equivalent is).

Never said that. What I was saying is that GPU drivers will expect certain things with the information they have. And what you said is exactly why tiled renderers have to do this. The GPU won't know if you're going to be drawing on every pixel, nor what tiles you're going to cover. Now, I'm not a graphics driver programmer, so I'm not sure exactly about the inner workings of how/why they expect a certain different behavior on tiled rendering, but I know for a fact that the driver does act this way, and that's all I need to know for this config.

How is it worse than Comanglia's? It gets better FPS as shown in the maxframes benchmarks.

It is set to 0 for maximum frames, though I agree it makes things inconvenient. I'll try a lower value than in the main config, but something that will still allow for loading item panels. I've just found it decreases FPS when you're spectating someone.

EDIT: updated maxframes config with 0.00007, but didn't have time to test it.

Sure, but it will more optimal if it was system specific. However, I like your idea of using a default value for min heap size of 196, since that's still larger but not too large.

Sorry if my wording was confusing. I meant I wanted it to fade since it will be basically invisible at like 4000 or something, which reduces clutter. With 5000 to 5000, it will still be opaque at 4000, and disappear at 5000.

The driver will see if you call a clear on the color buffer for that frame, and if so, then it won't read what you last drew to the buffer again.

On modern hardware, clearing the color buffer is faster than the read. Sure, it would be most ideal to tell the driver to just invalidate the last buffer, but as far as I can tell, the Source Engine wasn't written for that.

Because in order to stitch tiles together efficiently, the GPU has to have a different understanding of the final scene for the next frame. It doesn't know if the draw this upcoming frame will draw on every pixel, so it preemptively reads from the last buffer.