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.

I've tried to get into the habit of doing that. Sorry.

I agree that heapsize settings will be system specific so there won't really be a good default value. I'll comment the memory settings out and include better instructions on how to adjust the settings according to your available RAM.

The things it disables helps performance without affecting visuals too much. No one has reported the graphical issues you've claimed it causes, nor have I personally experienced them.

I used to have a hesitation to release it, but after several people asked me to post it to tftv, I did. Before, my logic was that I only wanted to release it when it was reasonably perfect, but now I've come to the conclusion that more publicity will get me better feedback, which will help me improve my config faster.

Sure, it is easier on rendering but I decided the rather insignificant extra rendering work that it has to do is worth it for reduced clutter by fading out to unnoticeable opacities faster. Perhaps for the max frames config, I'll set lod_TransitionDist to a value that avoids fading altogether.

I have explained it though. Non cleared buffers will be read by the driver per frame. gl_clear uses the standard clear method in the Source engine. If clearing is broken in Source, that's another problem that needs separate investigation.

Thanks, I appreciate your help in improving this config.

Do you mean exec gfx? I'll do that, but I have to make sure people don't forget to delete the autoexec.cfg in the mastercoms folder if they have their own autoexec.

A mistake. Fixed.

Nope, because people can change values. Though, I could do a better job of helping people find that host_thread_mode needs to be set to 0.

I know what bitshifting is. My point with my previous response was to tell you that it is indeed used by the TF2 client, contrary to what you had said. Anyway, you're right about the code logic. I just didn't pay much attention to it because it was such a fringe case anyway (512MB of system RAM). Sorry.

I wanted to ensure heapsize started bigger because audio cache takes up a quarter of memory. When using the async sound system, I needed to ensure that the heapsize was big enough to keep enough of the sound cache to prevent stuttering in most cases.

I don't. But it disables some things that can't be disabled normally. I haven't seen that problem.

I agree that the documentation needs to be better. But the documentation is a work in progress. I agree for consistency that the values should be different.

Because model detail is much more noticeable than some map objects that fade out of view sooner. You need to look at how that function is used. flMinDist is not going to be negative, because as I explained before, flMinDist will be 5000 + -5000, and flMaxDist will be 5000.

It clears the color buffer. I think you're thinking of gl_clear_randomcolor, which clears the buffer to a random color. Admittedly, I don't have a GPU that supports tiled rendering (stuck with a GTX660 for now :( ) so I can't test the effects of gl_clear. I should label it as an experimental CVar, then.

I've made a new preset for the config for max frames, while all benchmarks so far use my default config which does not squeeze out every last frame.

Please check back soon for benchmarks for my max frames preset!