Default XMP profile? I meant without XMP profile.
Anyway if it doesn't happen anymore you can obviously go back to full CPU and RAM speed.

Bottlenecks don't really work like that.

Also the problem is there always has to be a limiting factor, otherwise you'd be getting infinite fps.
In TF2 you'll be CPU limited like everyone else (except with stupidly high settings, see #21), but in most other games if you're not on the absolute lowest settings you'll be GPU limited. Look up benchmarks for a few examples and you'll see.

No, only the colour buffer. Can't skip the others unless GL_DEPTH_BUFFER_BIT, GL_ACCUM_BUFFER_BIT, and GL_STENCIL_BUFFER_BIT are all set.

Anyway how hard can it be to remember a single word?
I've had to guess so much since apparently it's impossible. That's why I asked

Do you mean the tile cache?
Because mobile/low power/low bandwidth tiled renderers have on chip buffers for colour and depth so writing to them is faster than reading from memory, because you share that with the CPU cores and can count yourself lucky if you get double digits GB/s bandwidth.

Makes perfect sense, the "on modern hardware it's faster" confused me because this has been a thing for 20 years.

It also explains why it only affects tiled renderers.

Except Maxwell/Pascal have neither that bandwidth problem nor a tile cache. They are vastly different from e.g. ARM Mali or even TBDR like PowerVR.
Also even just googling "tiled renderer glclear" gets you a source https://community.arm.com/graphics/b/blog/posts/mali-performance-2-how-to-correctly-handle-framebuffers at the top of the page.
So tell me:
Is this what you meant?
Why do you not know the term "tile cache"?
How basic was your research that you didn't realise that Maxwell/Pascal are vastly different than mobile low power GPUs?

XMP profile I guess? Go back to JEDEC spec. You never know.

I'm guessing it's version 2117, nice coincidence.

Seriously?

Look at the title.

OP wanted to compare these CPUs so I did.

I've worded that pretty clearly. It narrows it down to the i3.

I didn't say only solution, I said it's the better solution.
Considering OP seems reasonable and fairly well informed I assumed they would not choose the CPU with more threads only to use NVENC anyway. If they want to use CPU encoding that is their decision, not mine and not yours. But apparently NVENC is the only solution.

I only stated which is the better choice for each case. I don't judge people based on what they want to use their CPU for. Apparently you do. Because NVENC is the only solution.

Oh, we agree.

Wait nevermind, the "NVENC is the only solution"-robot is back.

Same quality != acceptable quality.
But reading is overrated, right?

Like I said multiple times this is all pointless because of Coffee Lake, yet you must make sure that everyone uses NVENC because the advantages are apparently the best thing since sliced bread and the disadvantages are "negligible". Stop it.
Stop derailing this thread.
You have made exactly zero effort to help OP, you're just here to push your weird agenda and at this point I've spent more time replying to your bullshit than helping OP because it's so god damn aggravating.

So RandomName, wait and see how Coffee Lake performs, especially the i3-8100, i3-8350K and the i5-8400, should it be <200$.
Now close this thread please.

Frankly I don't think so. You come up with the incredibly specific advice "i3 or i5" and then ignore their question.

This is clearly not about helping them. It seems to be a pissing contest to "prove" that your decision to use NVENC is the only acceptable choice.

I've answered the questions in #1 and I've mentioned that Coffee Lake might be the better choice.
Then added the bit about streaming.
Then you posted about NVENC.
I wasn't going to argue about the decision to use CPU encoding one month before anything will happen when the situation will probably change. I already know that if there's a quadcore i3 or hexacore i5 with decent clockrates under 200$ so they can afford it it'll be the obvious choice. I can also take a guess that if that doesn't happen they'll choose the 1500X regardless of everything else.
Anyway, I tried to clarify it, worse quality with NVENC, but should they choose to use it the i3-7320 or 7350K would be the way to go. Still Coffee Lake would probably be a better choice.

I'm trying to help and you somehow feel personally threatened by this?
If you have to try this hard to defend your choice to use NVENC it might be time to reevaluate it.

Oh shit it's an argument from authority. Better ignore MSE, PSNR and SSIM from now on.
Everything is more than acceptable if you lower your standards (or resolution or framerate) enough.

NVENC also needs 10-25 Mbit/s to get the same quality, which is not an option for streaming.
Also the i5-7500 still wouldn't be better. With no load for streaming on the CPU an i3-73x0 will be faster.

And again, Coffee Lake is a thing.

Yes. For streaming the situation is reversed and the 1500X wins easily.

Either way you're going to buy after the Coffee Lake launch so compare it with that before you buy.

4.0 should be doable with the stock cooler. Keep in mind that it can boost to 3.7 already so probably +10% absolute best case.

The difference between the i5-7500 and an overclocked 1500X should be negligible.
Yes, for anything that uses <=2 cores the 7350K (or even just a 7300) on stock clocks will be faster than either and will just shit on them overclocked.

Frankly I'd expect you to run into the GPU limit in any other game way before the CPU starts to matter.
For TF2 the 7300/7320/7350K win easily. A 7350K + Z270 mobo + cooler would probably cost more, but a 7320 is definitely within budget.

It's all rather irrelevant though since by then Coffee Lake should have been launched and buying old dual core i3s seems rather stupid when the new ones are quad cores (at least that's what the slides say).

I'm guessing you don't have a spare PSU lying around.
Did you update the BIOS?
CPU running at stock now, RAM too?

Well it means you can only skip the color buffer.
Anyway, why is the write faster on GPUs with tiled rendering.
I think I finally figured out what you mean (which could've been explained in one sentence), but considering how easy it is to explain and to realize why it doesn't work on Maxwell/Pascal I'm going to wait for a link to make sure you didn't just keep randomly guessing.

It still does nothing for the stencil and depth buffer.
You still have to do the write. Why would a forced write be faster than rdm on demand?
And we're talking about micro seconds that it takes to read the buffer.
And you still haven't named a single reason why this would affect tiled renderers differently.

I have no idea you think this works.

You always draw over the previous buffer unless it's invalidated. glclear does not invalidate buffers.
The driver will preemptively load the previous buffer to where?
Where do you think the solid red or whatever you set for glclear comes from? Every pixel that won't be overwritten needs to have that value.
And still most importantly, what would change if you do tiled rendering?

Really, just link where you got this from.

It doesn't matter what you want to call it. To set the colour in the colour buffer you have to write to it. Quoting the official documentation from khronos:

Yes, there is no cvar for it because you don't need to do it. gl_clear doesn't do it either.

Please just give me a source for this. Because either you misunderstood completely or can't explain it.
Everything you said so far about the behaviour of tiled renderers and gl_clear is wrong.
Yes, if you invalidate a buffer you don't have to read it.
No, glclear doesn't do it.
No, this doesn't affect tiled renderers differently. Any renderer has to read (read-modify-write actually) valid buffers and can ignore invalid ones.
No, clearing or even invalidating a buffer will not tell you where there will be triangles in the next frame.
No, you can't skip tiles just because you invalidated the buffer.
The whole point of rasterisation is to figure out where the triangles are. Before that you don't know it. You can't know it. And you don't need to know it. Clearing the buffer adds no information. If you write into an existing buffer you write to it. If you write into a new buffer you don't have to pull in cache lines for rmw because everything you don't write will automatically be zero. That's it.
So please, show me a link.