Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simulating fluids, fire, and smoke in real-time

andrewkchan.dev

Post reply on HN
Print view View original

31–40 of 174 posts

Re: Simulating fluids, fire, and smoke in real-time

#31

Post by vlovich123 »

softfalcon wrote: post #27
bee_rider wrote: post #25

Earlier quoted context omitted.

It looks like the GPU is doing most of the work… from that point of view when do we start to wonder if the GPU can “offload” anything to the whole computer that is hanging off of it, haha.

> It looks like the GPU is doing most of the work Yes. The GPU is doing most of the work in a lot of modern games. It isn't great at everything though, and there are limitations due to its architecture being structured almost solely for the purpose of computing massively parallel instructions. > when do we start to wonder if the GPU can “offload” anything to the whole computer that is hanging off of it The main bottl…

I’m pretty sure CPUs destroy GPUs at sequential programming and most programs are written in a sequential style. Not sure where the 90/10 claim comes from but there’s plenty of cloud servers with no GPU installed whatsoever and 0 servers without a CPU.

Re: Simulating fluids, fire, and smoke in real-time

#32

Post by kqr »

llm_nerd wrote: post #8

Page is basically unusable on my Intel MBP, and still a beastly consumer on my AS Mac. I presume simulations are happening somewhere on the page, but it would be a good idea to make them toggled. Ideally via user interaction, but if one insists on auto-play when scrolled into the viewport.

Same thing on a modern flagship smartphone.

Re: Simulating fluids, fire, and smoke in real-time

#33

Post by TillE »

bee_rider wrote: post #25
softfalcon wrote: post #24

Earlier quoted context omitted.

> Something I’ve never understood, if these effects are to run in a game, isn’t the GPU already busy? Short answer: No, it's not "already busy". GPU's are so powerful now that you can do physics, fancy render passes, fluid sims, "Game AI" unit pathing, and more, at 100+ FPS. Long answer: You have a "frame budget" which is the amount of time between rendering the super fast "slide show" of frames at 60+ FPS. This give…

It looks like the GPU is doing most of the work… from that point of view when do we start to wonder if the GPU can “offload” anything to the whole computer that is hanging off of it, haha.

A game is more than just rendering, and modern games will absolutely get bottlenecked on lower-end CPUs well before you reach say 144 fps. GamersNexus has done a bunch of videos on the topic.

Re: Simulating fluids, fire, and smoke in real-time

#34

Post by softfalcon »

MaxBarraclough wrote: post #26
teh_infallible wrote: post #22

Earlier quoted context omitted.

Maybe in the future, personal computers will have more than one GPU, one for graphics and one for AI?

Many computers already have 2 GPUs, one integrated into the CPU die, and one external (and typically enormously more powerful). To my knowledge though it's very rare for software to take advantage of this.

In high performance scenarios, the GPU is running full blast while the CPU is running at full blast just feeding data and pre-process work to the GPU.

The GPU is the steam engine hurtling forward, the CPU is just the person shoveling coal into the furnace.

Using the integrated GPU heats up the main die where the CPU is because they live together on the same chip. The die heats up, CPU thermal throttles, CPU stops efficiently feeding data to the GPU at max speed, GPU slows down from under utilization.

In high performance scenarios, the integrated GPU is often a waste of thermal budget.

Re: Simulating fluids, fire, and smoke in real-time

#35

Post by kqr »

softfalcon wrote: post #27
bee_rider wrote: post #25

Earlier quoted context omitted.

It looks like the GPU is doing most of the work… from that point of view when do we start to wonder if the GPU can “offload” anything to the whole computer that is hanging off of it, haha.

> It looks like the GPU is doing most of the work Yes. The GPU is doing most of the work in a lot of modern games. It isn't great at everything though, and there are limitations due to its architecture being structured almost solely for the purpose of computing massively parallel instructions. > when do we start to wonder if the GPU can “offload” anything to the whole computer that is hanging off of it The main bottl…

This is somewhat reassuring. A decade ago when clock frequencies had stopped increasing and core count started to increase I predicted that the future was massively multicore.

Then the core count stopped increasing too -- except only if you look in the wrong place! It has in CPUs, but they moved to GPUs.

Re: Simulating fluids, fire, and smoke in real-time

#37

Post by softfalcon »

vlovich123 wrote: post #30
softfalcon wrote: post #24

Earlier quoted context omitted.

> Something I’ve never understood, if these effects are to run in a game, isn’t the GPU already busy? Short answer: No, it's not "already busy". GPU's are so powerful now that you can do physics, fancy render passes, fluid sims, "Game AI" unit pathing, and more, at 100+ FPS. Long answer: You have a "frame budget" which is the amount of time between rendering the super fast "slide show" of frames at 60+ FPS. This give…

> No one is using the iGPU for anything. It's completely ignored because it's usually completely useless compared to your main discrete GPU. Modern iGPUs are actually quite powerful is my understanding. I think the reason no one does this is that the software model isn’t actually there/standardized/able to work cross vendor since the iGPU and the discrete card are going to be different vendors typically. There’s also…

I agree the incentives aren't there. Also agree that it is possible to use the integrated GPU for light tasks, but only light tasks.

In the high performance scenarios where there is all three (discrete GPU, integrated GPU, and CPU) and we try and use the integrated GPU alongside the CPU, it often causes thermal throttling on the shared die between iGPU and CPU.

This slows the CPU down from executing well, keeping up with state changes, and sending needed data to the keep the discrete GPU utilized. In short, don't warm up the CPU, we want it to stay cool, if that means not doing iGPU stuff, don't do it.

When we have multiple discrete GPU's available (render farm), this on-die thermal bottleneck goes away and there are many render pipelines that are made to handle hundreds, even thousands of simultaneous GPU's working on a shared problem set of diverse tasks, similar to trying to utilize both iGPU and dGPU on the same machine but bigger.

Whether or not to use the iGPU is less about scheduling and more about thermal throttling.

Re: Simulating fluids, fire, and smoke in real-time

#38

Post by pdabbadabba »

llm_nerd wrote: post #8

Page is basically unusable on my Intel MBP, and still a beastly consumer on my AS Mac. I presume simulations are happening somewhere on the page, but it would be a good idea to make them toggled. Ideally via user interaction, but if one insists on auto-play when scrolled into the viewport.

Interestingly, no noticeable performance issues on my M2 MacBook Air. Maybe he's already made some of the changes you recommended?

Re: Simulating fluids, fire, and smoke in real-time

#39

Post by softfalcon »

TillE wrote: post #33
bee_rider wrote: post #25

Earlier quoted context omitted.

It looks like the GPU is doing most of the work… from that point of view when do we start to wonder if the GPU can “offload” anything to the whole computer that is hanging off of it, haha.

A game is more than just rendering, and modern games will absolutely get bottlenecked on lower-end CPUs well before you reach say 144 fps. GamersNexus has done a bunch of videos on the topic.

You are not wrong that there are many games that are bottle-necked on lower end CPUs.

I would argue that for many CPU bound games, they could find better ways to utilize the GPU for computation and it is likely they just didn't have the knowledge, time, or budget to do so.

It's easier to write CPU code, every programmer can do it, so it's the most often reached for tool.

Also, at high frame rates, the bottleneck is frequently the CPU due to it not feeding the GPU fast enough, so you lose frames. There is definitely a real world requirement of having a fast enough CPU to properly utilize a high end video card, even if it's just for shoving command buffers and nothing else.

Re: Simulating fluids, fire, and smoke in real-time

#40

Post by mckn1ght »

cherryteastain wrote: post #17
jwoq9118 wrote: post #12

Earlier quoted context omitted.

Was the PhD worth it in your opinion?

From a purely economic standpoint, difficult to say. I was able to build skills that are very in demand in certain technical areas, and breaking into these areas is notoriously difficult otherwise. On the other hand, I earned peanuts for many years. It'll probably take some time for it to pay off. That said, never do a PhD for economic reasons alone. It's a period in your life where you are given an opportunity to bu…

I feel this comment. I did a masters with a thesis option because I was not hurting for money with TA and side business income, so figured I could take the extra year (it was an accelerated masters). Loved being able to work in that heady material, but disliked some parts of the academic environment. Was glad I could see it with less time and stress than a PhD. Even so, I still never say never for a PhD, but it’d have to be a perfect confluence of conditions.
Post reply on HN