Discussion CPU instruction set explanation thread

[Moonstick2]

Now you have to explain that you lied and they weren't really triangles, after all. Don't simplify to the point where your answer is a lie.

Calling posts lies is needlessly antagonistic in a thread that's otherwise been good-natured from what I've seen.

Virtually every discussion of GPU tessellation (example and one of many) introduces it with the basic concept of a coarse triangular mesh being converted into a finer mesh before going into the technicalities of the implementation. If it's good enough for the names on that presentation then it's good enough for me. I labelled it a simple answer and provided a link to a longer (yet still not too complicated) one.

If you think there's a better way to answer the question "what exactly is tessellation" it's probably more constructive to provide it.

 

[Order 66]

Calling posts lies is needlessly antagonistic in a thread that's otherwise been good-natured from what I've seen.

Virtually every discussion of GPU tessellation (example and one of many) introduces it with the basic concept of a coarse triangular mesh being converted into a finer mesh before going into the technicalities of the implementation. If it's good enough for the names on that presentation then it's good enough for me. I labelled it a simple answer and provided a link to a longer (yet still not too complicated) one.

If you think there's a better way to answer the question "what exactly is tessellation" it's probably more constructive to provide it.

I think you both make fair points, however, I wouldn't have known that it was more complex than what you said.

 

[bit_user]

Calling posts lies is needlessly antagonistic in a thread that's otherwise been good-natured from what I've seen.

What I said about the post is that part of it was "misleading". Being good-natured doesn't mean we can't disagree or say what we mean.

My usage of the term "lie" was in reference to the general tactic of explaining difficult subjects. Sometimes, you have to give an explanation that's a workable approximation. For instance, teaching kids about Newtonian physics, even though it's been superseded by General Relativity. That's okay, because the former has excellent predictive power and utility in most practical domains, is computationally much simpler, is pretty much at the level of what students in secondary school can handle, and provides a good example of how mathematics ties into physics, thus providing a useful motivation for studying calculus.

However, the amount of misrepresentation should always be minimized. I think this case is an excellent example, because the superficial explanation of describing the input as "triangles" fails to provide a motive. It's not a sufficient explanation, even at that level. Furthermore, there's really no reason you can't just tell someone that it's a technique for rendering curved surfaces. Anyone capable of understanding how polygon rendering works should be able to grasp that explanation. It's a better answer, since it immediately tells you the motivation, and doesn't require going over their heads.

Virtually every discussion of GPU tessellation (example and one of many) introduces it with the basic concept of a coarse triangular mesh being converted into a finer mesh

First, who is the author and why should we believe their explanation is competent or authoritative?

Second, the basis for Tessellation (in modern graphics APIs) isn't triangles. It's triangular patches. Yes, at the coarsest level, you can approximate them as triangles. This is useful for demonstrating LoD. Still, it's not triangles that you're subdividing. Furthermore, patches can also be quadrilaterals.

If it's good enough for the names on that presentation then it's good enough for me.

That's fine if you like your explanation. I don't. You're not trying to force me to agree, are you? Am I allowed to have my own opinion on things?

If you think there's a better way to answer the question "what exactly is tessellation" it's probably more constructive to provide it.

I stand by what I've provided in my prior posts. I trust you've read them, since I'm sure you wouldn't engage me on a topic without having first taken the time to understand my position, such as I've represented it.

 

[Order 66]

What I said about the post is that part of it was "misleading". Being good-natured doesn't mean we can't disagree or say what we mean.

My usage of the term "lie" was in reference to the general tactic of explaining difficult subjects. Sometimes, you have to give an explanation that's a workable approximation. For instance, teaching kids about Newtonian physics, even though it's been superseded by General Relativity. That's okay, because the former has excellent predictive power and utility in most practical domains, is computationally much simpler, is pretty much at the level of what students in secondary school can handle, and provides a good example of how mathematics ties into physics, thus providing a useful motivation for studying calculus.

However, the amount of misrepresentation should always be minimized. I think this case is an excellent example, because the superficial explanation of describing the input as "triangles" fails to provide a motive. It's not a sufficient explanation, even at that level. Furthermore, there's really no reason you can't just tell someone that it's a technique for rendering curved surfaces. Anyone capable of understanding how polygon rendering works should be able to grasp that explanation. It's a better answer, since it immediately tells you the motivation, and doesn't require going over their heads.


First, who is the author and why should we believe their explanation is competent or authoritative?

Second, the basis for Tessellation (in modern graphics APIs) isn't triangles. It's triangular patches. Yes, at the coarsest level, you can approximate them as triangles. This is useful for demonstrating LoD. Still, it's not triangles that you're subdividing. Furthermore, patches can also be quadrilaterals.


That's fine if you like your explanation. I don't. You're not trying to force me to agree, are you? Am I allowed to have my own opinion on things?


I stand by what I've provided in my prior posts. I trust you've read them, since I'm sure you wouldn't engage me on a topic without having first taken the time to understand my position, such as I've represented it.

well said. You have an amazing ability to have debates and disagreements with people without resorting to personal attacks ( I have never seen you resort to personal attacks, anyway) Do CPUs support raytracing? I know that even GPUs without RT hardware can do it, but what about CPUs?

 

[bit_user]

well said. You have an amazing ability to have debates and disagreements with people without resorting to personal attacks

Thanks, but I can have a way of being austere. I'm aware my tone can come across as harsh, at times.

( I have never seen you resort to personal attacks, anyway)

Sometimes, I do get frustrated and make the odd slight. We all have our limits & our moments of weakness.

Do CPUs support raytracing? I know that even GPUs without RT hardware can do it, but what about CPUs?

I first dabbled with ray-tracing, using a CPU program called PoV-Ray. This was before you could even buy consumer-level 3D graphics cards for PCs!

https://en.wikipedia.org/wiki/POV-Ray
​

You can still download and start playing with it, today!

 

[Order 66]

You can still download and start playing with it, today!

I'm assuming the program has gotten significantly more demanding since you started using it, correct? Otherwise, I think my 7700x wouldn't even break a sweat running it. Also, what stops games in general from running at a higher frame rate when CPU usage is not maxed out, and GPU usage isn't either? For example, my system runs Roblox at max graphics at about 300fps at 1080p, but CPU utilization is only 20% while GPU utilization is only 40%. I'm thinking it has something to do with engine limits, but I'm not sure.

 

[bit_user]

I'm assuming the program has gotten significantly more demanding since you started using it, correct?

I'm not sure what you're getting at, but it's plenty fast if you mind the quality settings and image resolution you're rendering at. Keep in mind that modern CPUs are like 1000x faster, now. No, it's not realtime - that was never the point of it.

I'd say just give it a whirl and see what it does.

my system runs Roblox at max graphics at about 300fps at 1080p, but CPU utilization is only 20% while GPU utilization is only 40%. I'm thinking it has something to do with engine limits, but I'm not sure.

It's difficult to divide up all of the work needed for rendering a frame into the maximum number of threads. Think of it like this: it takes time for threads (i.e. the code running on the different cores) to coordinate. Within 1/300th of a second, there's only so much of that coordination overhead you can afford. Plus, some kinds of computation tasks are just plain difficult to divide up for multiple threads to share.

If a game runs fast enough on even weak CPUs, the developers won't have much motivation to undertake more aggressive multithreading.

 

[Order 66]

I'm not sure what you're getting at, but it's plenty fast if you mind the quality settings and image resolution you're rendering at. Keep in mind that modern CPUs are like 1000x faster, now. No, it's not realtime - never was.

I'd say just give it a whirl and see what it does.

Sorry, I thought it was realtime. Looks like a ryzen 7 1800x scores 3242, and a 7700 non x scores about 21380. Not sure how much better my 7700x would do vs a 7700, but I will try it tonight.

 

[bit_user]

BTW, the other thing I neglected to mention about your Roblox situation is that there's only so much work for the CPU to do. At some point, making the CPU faster will have very little effect on the frame rate. People would often say the game is GPU-botlenecked, in this scenario.

 

[Order 66]

@bit_user, I saw you mention unrolling vectorization. I didn't want to get off topic in that thread, so I'll ask here: what is unrolling vectorization?

 

[bit_user]

@bit_user, I saw you mention unrolling vectorization. I didn't want to get off topic in that thread, so I'll ask here: what is unrolling vectorization?

Loop unrolling:

https://en.wikipedia.org/wiki/Loop_unrolling
​

Vectorization:

https://en.wikipedia.org/wiki/Automatic_vectorization
​

This is a simplistic explanation, but if optimizing compilers can first do loop unrolling, then they can often vectorize the operations in the loop, so it can utilize SIMD/vector instructions (e.g. SSE, AVX, etc.). The result can be an order of magnitude (roughly 10x) performance improvement, relative to the scalar version. Even when you can't vectorize, unrolling often delivers performance improvements as I'm sure the Wikipedia article explains.

It's best if you can get the compiler to do these code transformations, since they make the code harder to read & maintain (plus are time consuming and introduce potential for bugs), if the programmer does them by hand.