Yes, wait for Coffee Lake.
Higher clockrates as well, so if you don't plan on overclocking it'll be faster.
If you do plan on overclocking but don't think you'll need more cores/threads why get the i7-7700K instead of the i5-7600K? And in that case you could wait for the i3-8350K. Same 4 cores as the i5-7600K.

You can't have central europeans and scandinavians on 5 ping at the same time.
And to this day I have never played on a Stockholm server.

Is there anything 5 ping can't be blamed for?

You still can't explain scandinavians though, they are mysteriously good at video games.

For TF2 yes, for everything else no.
Your motherboard is too old, there are no new CPUs that fit. New motherboard compatible with new CPUs also use DDR4 RAM and CPU + mobo + RAM really isn't doable with your budget.
You can look for a used i5-3570 (or 3570K) or i7-3770(K) if that is cheaper.

Your CPU is actually a dual core. 2 cores, but 4 threads. That is a thing.

There's not enough RX 570s in stock to get below/close to 150, so the 1050 Ti is basically the best GPU (and most expensive obviously) that is still within budget.

You won't get more fps in TF2 though, because that is CPU bound. Other than that a 1050 Ti should be about twice as fast as a 650 Ti. It actually needs less power so you don't even have to check which PSU you got, if the 650 Ti worked then the 1050 Ti will work just fine.

No, FX-8350 isn't good either.
1050 is about 60% faster than a 750 Ti.

I just noticed I got 4 nerd stars now.

Sometimes. Sometimes he's sure about things that are definitely wrong though.
Some claims can simply be ignored and all others should be tested before trusting them. If you want to study the placebo effect he's your guy. I mean he tries to get it right and believes what he says, but that doesn't make it correct.

Then how did that fluid get in?
The Kraken X61 is made by Asetek. Asetek typically uses a mix of water and propylene glycol as coolant. Aqueous solutions of propylene glycol turn red when they corrode metal.
So forgive me for having some doubts here.

Anyway I would look for used parts. There are simply no CPUs/mobos that use DDR3 available anymore, with the exception of some 4 year old leftover stock from Bulldozer based CPUs/APUs (e.g. FX series, already EOL), which no one bought for a reason. You can't afford to buy new DDR4 RAM either.

No, a faster GPU will not make your CPU any faster. That's the equivalent of adding an extra arm to compensate for a missing leg. Not going to run any faster with that.

It's stabby, the guy who recommended launch options that don't exist.
You can't even afford the amount of salt you need to take his advice with.

Uhm, you know it's not a mystery fluid when you've got a liquid cooler? You might not want to use that again.
In fact if you do you will kill the next set of hardware as well.
RMA the cooler and ideally make them pay for equivalent new hardware.

Also please no FX-4300.

In an ideal world where you know and control everything yes.
In the real world you either need tile caches (for which it is basically a requirement) or there will be a lot of ifs.
So with tile caches you basically have to do it because if you just assume everything will be zero and only start reading once it's clear that a part of the tile will be overwritten you will end up wasting a lot of time. The driver assumes everyone knows what they are doing so no glclear means you think you'll need the previous buffer and it will read it.
Also when you have maybe 10 GB/s then for 60 fps just a single full read on a 1920x1080 framebuffer eats up 5% of your total read budget. When you have 200-500 GB/s you can afford to care a lot less.
With an IMR things are different so if you don't write anything nothing gets pulled into the cache at all. Of course if you overwrite everything then in theory not having to read anything does save time. But then the ifs start.

1. If you don't overwrite everything it obviously doesn't work or you have to redraw something. You might not save time/bandwidth anymore. In case of TF2 I don't think they do weird stuff with not overdrawing the HUD (and no one cares about the main menu) so we should be safe.
2. glclear can clear multiple buffers. For example clearing only the stencil or the depth buffer makes things worse because they are usually interleaved and you can't pull in partial cache lines so you end up having to read everything anyway and do a write on top of it. Again we're safe because gl_clear only sets the flag for the colour buffer and that should be seperate.
3. glclear doesn't clear to zero. It clears to whatever GL_ACCUM/COLOR/DEPTH/INDEX/STENCIL_CLEAR_VALUE is set. You can still invalidate the backing memory, but you now actually have to do a write and you can't write into nothing so you need to make room for the cache lines you write to. If the cache lines that you have to evict for that have been written to then you need to write them out to memory. That's not any faster than reading from memory and you still haven't done the on-chip write to the colour buffer. Even if you can just throw away the cache lines because they were unchanged you might need them for rendering again (there is a reason they were in the cache) so now you have to read them from memory again. There's all sorts of "smart" things the driver could be doing but I wouldn't rely on undocumented behaviour. Benchmarking it is easier and faster. gl_clear_randomcolor is obviously a debug command and clears to solid colours, but I haven't cared about source OpenGL code enough (sorry Linux fanatics, it's just not that important) to check what gl_clear will clear to. Easier to just benchmark.
4. Contrary to popular belief Valve is not run by idiots. "Smart" clearing isn't all that new, it's been the standard for a few years by the time TF2 was released. When the started "porting" source to OpenGL it was already impossible to find a GPU that would still do writes for a clear to zero. So they might already be clearing to black/zero by default and gl_clear 1 sets it to a certain colour instead. Or they might be clearing everytime it's a clear win already whereas gl_clear 1 alway forces a glclear even in for desktop GPUs disadvantageous situations to have that option for GPUs with tile caches, where it would still be a win unless there's a ridiculous amount of redraw needed.
Again probably easier to just benchmark it.
Except due to the higher bandwidth on desktop GPUs you might not be able to tell which setting is better because the difference should be smaller than the variation between runs.
I mean try gl_clear_randomcolor and see how much it changes.

#117
At this point it's a definite maybe.

Yes, that means no XMP profile (just standard JEDEC profile). Because reasons.
Other mobos label it "XMP: [off/profile #1/profile #2/...], which makes more sense.

But you might hit Kansas City, Kansas.

Ok, finally we got that sorted out.
I was in way too deep on the tiled vs deferred thing* (which has been going on for over a decade now) to realize that most are still used to tiled = deferred and the books on the subjects, which are often quite old, couldn't even know that that has changed. I guess that arguing in circles was incredibly frustrating for both of us.

So what exactly should I explain, there's still multiple things left.
-Why gl_clear 1 in TF2 isn't really a good idea without going really deep into the rendering code to check first?
-Why glclear doesn't really affect Maxwell/Pascall differently than standard desktop IMR GPUs?
-Why glclear generally affects desktop GPUs less?
-or the thing that's explained in that stackoverflow post Why GPUs with tile caches benefit from glclear?

I'll probably only get around to answering it tomorrow.

*further complicated by ARM Mali not being deferred but still using tile caches and then lead completely ad absurdum by nVidia doing tiling without tile caches and calling it "tiled caching".
https://www.techpowerup.com/img/17-03-01/f34e39b49c7c.jpg

#113
You know exactly that only this level of stubborness, persistence and "attention to detail"/autism like focus gets you good configs.

Why do you still ignore everything I say?

Maxwell/Pascal are tiled immediate mode renderers.
They don't have tile caches.
It doesn't apply.

I know the terminology is confusing, but that's how it is. For many years all tiled renderers have been deferred renderers.*
Maxwell and Pascal aren't like this. They are fundamentally different.

To quote your own source:

And now this http://www.realworldtech.com/tile-based-rasterization-nvidia-gpus/

Do you see the problem?

*Mali is actually an immediate mode renderer, but the basic structure is still the same, just the order with the depth pass and HSR are different. I know this makes it even more confusing, but that's how it is.