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

Finding your home in game graphics programming

alextardif.com

Post reply on HN
Print view View original

61–70 of 128 posts

Re: Finding your home in game graphics programming

#61

Post by pjmlp »

ginko wrote: post #39
ridiculousthrow wrote: post #15

Graphics Programming needs to be restructured. There’s a lot of focus on API driven learning. Vulkan, D3D12, 11, etc. Wrong approach. Learn fundamentals of what the hardware is capable of. For each feature, write down a few ideas of how you could use it by itself. Write down a few ideas of how you could combine it with other features. Think of “I want to do X. What features can allow me to do that?” The APIs, althoug…

>The APIs, although they are not easily interchangeable, use the same hardware and can often do the same things with a bit of effort. Actually it's the other way round. GPU architectures can vary wildly especially when you include mobile GPUs which are tiling architectures. Graphics APIs are the least common denominator interface that makes targeting all of them possible.

Not at all, hence why AAA game engines have all been based of plugin architecture for their backends, which allows them to take the best advantage of each hardware, no need for least common denominator interface.

Those that try to target everything with a single API are fooling themselves, hence why in the end they all end up with extension spaghetti and multiple code paths, while pretending to still use a single API.

Re: Finding your home in game graphics programming

#62

Post by Gene_Parmesan »

justastudent wrote: post #38

I've heard that the salary for game programmers is pretty low compared to other fields. Is this also true for graphics programmers in general? E.g. jobs in AR/VR.

The reason salaries for game programmers are so low is that there is an effectively endless supply of new crops of graduates who have told themselves since they were 12 that they want to make video games for a living. Classic supply and demand dictates that, with such a high supply, big studios can get away with paying very little (and can extract additional "benefits" as well, such as demanding insane hours and so on).

Re: Finding your home in game graphics programming

#63

Post by happyweasel »

With "standardized" game engines such as Unreal Engine and Unity and somewhat standardized asset creation pipelines (PBR texturing) a team can start building a great looking game with good graphics and probably good performance by just using "gameplay programmers". Back in the day it was impossible to create good looking games at all without a "game graphics programmer". Maybe on mobile that is different. I would focus on graphics programming in a more broader sense, and maybe consider going into (medical) or CAD visualization fields.. And there I guess targeting OpenGL / Vulkan is a much better platform to be "efficient in".

What I am trying to say is that trying to make "_game_ graphics programming" your home is maybe not the best career choice for a graphics programmer.

Re: Finding your home in game graphics programming

#64

Post by autograd »

Waterluvian wrote: post #19
colordrops wrote: post #18

Earlier quoted context omitted.

It's hard or impossible to know that delta. The amount of complexity that goes into rendering a modern scene is beyond what could be formally specified without putting nation-state level resources and decades of time into it. Even then, you'd have to go through a massive amount of analysis and development to find the most optimal implementation for a particular problem, and it would only be a local optimum, not guara…

Appreciate the response. That’s in line with my amateur musings. It’s funny how it might be impossible to quantify but it’s often trivial to qualitatively know, “this ought to be way faster…” (but also the biases that make us think that given we don’t appreciate what some games have to do to render that state…)

It's easy to "trivially know" because it's really expensive to disprove the statement, so you continue believing in your original one.

I am not in game development, but was recently looking in some deep learning networks. A lot of compute, bazillion layers of abstractions (erm python), but at the end of the day, 98% of the time was really spent calculating the matmul. I had luck that it was easy to check it and estimate the abstraction cost (not into great detail), and disprove my original thought.

Had i not checked it, I'd still trivially know that far more perf loss happened because of abstractions.

Re: Finding your home in game graphics programming

#65

Post by Narann »

happyweasel wrote: post #63

With "standardized" game engines such as Unreal Engine and Unity and somewhat standardized asset creation pipelines (PBR texturing) a team can start building a great looking game with good graphics and probably good performance by just using "gameplay programmers". Back in the day it was impossible to create good looking games at all without a "game graphics programmer". Maybe on mobile that is different. I would foc…

I agree with you. 90% of making things is mainly knowing the “general workflow” of dedicated tools and iterate as fast as possible by building a dedicated pipeline.

Low level graphic programing is still a thing and it would be a lie to say it's gone, but it's highly specialized. A low level graphic developer would spend it's days focusing on low level things. Before the Unreal/Unity era, even big game companies tries to share those dev between developments.

Re: Finding your home in game graphics programming

#66

Post by flohofwoe »

pixelpoet wrote: post #46
boppo1 wrote: post #44

Earlier quoted context omitted.

What should the article have included about ray tracing to be complete?

Not only is ray tracing the future of rendering, it's by far the best way to learn basic graphics programming theory, in 100% your own tiny code. I've literally taught a 12 year old this way from absolute scratch, and have been teaching it this way for over 20 years now; it's a bajillion times more upfront complexity to do a rasterisation engine from scratch, so in practice almost nobody does this, and we're back to…

Raytracing is one of those promised techniques that has always been "the future", just like fusion power. The actual future will most likely be various hybrid solutions that (among other things) also make use of the raytracing support in modern GPUs. The triangle rasterizer most likely won't go away, it's a too obvious optimization method, it will just be augmented with other specialized hardware units (like texture sampling and raytracing).

Re: Finding your home in game graphics programming

#67

Post by bigcheesegs »

Const-me wrote: post #57
captaincrowbar wrote: post #36

Earlier quoted context omitted.

The term you're looking for might be "abstraction penalty". For tools that can identify where the bottlenecks are, I recommend watching Emery Berger's talk "Performance Matters" from CppCon 2020 (either of the two links below should work). He introduces some innovative new profiling tools for this sort of analysis. https://www.youtube.com/watch?v=koTf7u0v41o https://www.youtube.com/watch?v=VzyhpbrC2Bs

The guy is unconvincing. I don't believe RAM layout is that important. Of course it can affect perf, but slightly, not by 40%. For instance, Windows has ASLR (address space layout randomization) for security reasons, enabled by default. Microsoft would not do that if it would cost 40% of performance at random. However, there're quite a few random factors. Random choices made by C++ optimizers can contribute about 20%…

> I don't believe RAM layout is that important. [...]

ASLR has nothing to do with the type of memory layout discussed here. ASLR only impacts compiled code/data, and only entire shared objects/executables at a time.

A bad memory layout can have a huge impact on perf. A simple example is iteration order of a 2d array, where not doing sequential access can result in a ~5x slow down.

> Computer thermals when running the test can contribute 40%.

Only if you forgot to apply thermal paste.

Re: Finding your home in game graphics programming

#68

Post by bullen »

t8y wrote: post #60
bullen wrote: post #45

I disagree, if you stop chasing infinite progress it's very managable. As hardware peaks now it's the perfect occasion to settle on something older and make a stand there. They can deprecate it all they want they wont be able to remove it, in fact they will probably maintain and improve it for eternity. I have choosen OpenGL (ES) 3 and I'm making my 3D action MMO client on top of that. Metal, Vulkan and DX12 bring no…

The game I'm working on uses compute shaders for pretty much all the gameplay. These APIs are just to control the GPU, they are just complicated to give developers flexibility. Just because you can't think of uses for these features for gameplay doesn't mean they don't exist. Perhaps I'm misunderstanding "The fragmentation is a sign of desperation" but Metal, Vulkan and DX12 have very clear reasons they exist: -Metal…

Compute shaders are trying to fit an elephant on a scooter. The reason Unity has poor animation performance with Mechanim is that they use compute shaders for skin mesh animation so they can apply shaders across assets but that forces them to send all model data every frame, sealing the fate of that engine to the scrap heap.

I think the path forward will be massively parallel microcontrollers with some new memory management replacing the MMU in CPUs allowing for the CPU and GPU to merge. Look at the RP2040 microcontroller for how that is progressing, it will take decades if it ever happens.

GPUs will never do general purpose computing as well as CPUs, they don't handle branching the way you need so the only way to solve this problem is to make the GPU more like a CPU but then manage to scale the memory access.

The VAO was the last meaningful feature added to OpenGL, companies are desperate to always develop new things because that is how our economy works now, but eventually our stored energy is going to deplete and we will have to settle on things long term.

I mean with the newest API you are throwing alot of still very performant hardware on the junk pile... I'm targeting Raspberry 4 for my lowest performance device at 5W single CPU core and GPU maxxed out...

Re: Finding your home in game graphics programming

#69

Post by flohofwoe »

Const-me wrote: post #57
captaincrowbar wrote: post #36

Earlier quoted context omitted.

The term you're looking for might be "abstraction penalty". For tools that can identify where the bottlenecks are, I recommend watching Emery Berger's talk "Performance Matters" from CppCon 2020 (either of the two links below should work). He introduces some innovative new profiling tools for this sort of analysis. https://www.youtube.com/watch?v=koTf7u0v41o https://www.youtube.com/watch?v=VzyhpbrC2Bs

The guy is unconvincing. I don't believe RAM layout is that important. Of course it can affect perf, but slightly, not by 40%. For instance, Windows has ASLR (address space layout randomization) for security reasons, enabled by default. Microsoft would not do that if it would cost 40% of performance at random. However, there're quite a few random factors. Random choices made by C++ optimizers can contribute about 20%…

ASLR only randomizes a handful base addresses of code and data sections, heap, stack etc..., but it doesn't change how data items or functions are located relative to each other.

Memory layout is most definitely important just because memory accesses have such a high latency. This cost may be hidden by prefetching and the cache hierarchy, but keeping the caches well fed is exactly why memory layout matters.

Re: Finding your home in game graphics programming

#70

Post by Const-me »

bigcheesegs wrote: post #67
Const-me wrote: post #57

Earlier quoted context omitted.

The guy is unconvincing. I don't believe RAM layout is that important. Of course it can affect perf, but slightly, not by 40%. For instance, Windows has ASLR (address space layout randomization) for security reasons, enabled by default. Microsoft would not do that if it would cost 40% of performance at random. However, there're quite a few random factors. Random choices made by C++ optimizers can contribute about 20%…

> I don't believe RAM layout is that important. [...] ASLR has nothing to do with the type of memory layout discussed here. ASLR only impacts compiled code/data, and only entire shared objects/executables at a time. A bad memory layout can have a huge impact on perf. A simple example is iteration order of a 2d array, where not doing sequential access can result in a ~5x slow down. > Computer thermals when running the…

> A bad memory layout can have a huge impact on perf. A simple example is iteration order of a 2d array, where not doing sequential access can result in a ~5x slow down.

I know all that stuff, but the presenter doesn’t talk about RAM layout of data structures. They talk about a few [kilo]bytes offset caused by differently sized environment variables, and layout differences caused by linking order.

> Only if you forgot to apply thermal paste.

Try benchmarking a single-threaded code in 2 cases, in cold state, and when the rest of the CPU cores are running something like CPU stress test (but not accessing IO or L3 cache, i.e. not directly consuming any shared resources). You will easily get above 40% difference, despite the thermal paste.

Post reply on HN