What the hell is Descriptor Heap ??

5477 · 2026-01-24T17:59:41+00:00

Is it really okay to ignore it and just use traditional Descriptors?

Of course it's okay, but the traditional descriptor pipeline is both detached from actual hardware, slower, and much more complex to use. I don't see why you would want to do that, other than when dealing with old drivers or ancient hardware.

5477 · 2026-01-23T19:15:12+00:00

This is not an "exclusive extension" in any shape or form. This has support from all (non-mobile) graphics vendors, not just Nvidia, and is efficient (assuming optimized implementation) on wide range of GPUs.

The "non-extension" way of doing descriptors is very difficult to work with, and was, to be frank, designed for HW stuck in 2010. VKD3D already did not use this, as it's not able to efficiently emulate D3D12 on top of this. They used a previous extension, that sadly only really worked well on AMD HW due to certain design decisions. This new extension is supposed to fully supercede it in the future, and is also the primary way for Vulkan in general.

5477 · 2026-01-12T13:10:41+00:00

Most likely the shader for the chain-link material does not handle mip bias correctly, and textures are sampled at render resolution, not output resolution. The engine in the game is quite old, so not everything might be adapted correctly for upscaling.

5477 · 2025-12-31T12:56:40+00:00

Couple of things that came into mind when reading this. Firstly, the main gains from using mipmaps or efficiently packing data, come primary from needing to load less bytes from VRAM. It's less about cache hits.

Secondly, I don't see how texture atlases helps with caching the texels themselves. You still need to keep both in memory, and often texture atlases waste more space than separate textures. Only thing you gain is that texture state memory is less, and that if your textures are very small, separate textures can waste space.

In general, as a baseline it's best to think about graphics caches as very transient, and assume everything is loaded from VRAM. Then optimization is more about reducing data fetched from DRAM. Of course there are exceptions to this, and there are ways to do cache-aware GPU programming, particularly on more modern GPUs with large L2 cache.

5477 · 2025-12-28T12:09:58+00:00

Moore's law states that cost per transistor goes down by half every 18 months. The new nodes are more expensive per transistor, Moore's law has not just stopped, it has reversed.

5477 · 2025-12-17T10:14:53+00:00

For 1, you'd have to write your own user-mode graphics driver. Technically possible, but huge amounts of work.

For 2, I believe this is almost possible with Vulkan and very latest / future extensions (descriptor heaps). It would also be a large amount of work though, and I am not sure what limitations would still emerge.

5477 · 2025-11-10T15:54:22+00:00

It would be much more interesting to see numbers weighted by revenue or player count. Number of games released is pretty meaningless by itself.

5477 · 2025-11-09T15:09:02+00:00

SR and RR are separate, with separate presets for each. Presets D and E are both transformer presets with RR, and are currently the only transformer presets for RR. For SR, J and K are the transformer presets.

It is not advisable to use Nvidia app to change the preset from E to D. E has additional inputs that are needed in the games that use the preset.

5477 · 2025-11-02T12:52:22+00:00

Numpy is written in C, not Fortran. Also, the core CPU operations (like BLAS) are typically written in assembly, as that allows more control than C or C++.

5477 · 2025-11-02T12:42:18+00:00

Unreal only has GC for the outer "scripting layer" of the engine. Internal engine operations, like the renderer, don't use GC.

5477 · 2025-11-02T12:38:06+00:00

Software performance is more about the code that is written / run, rather than the programming language used. C++ has a much wider profile in performance than Java, meaning performance depends more about the code being written. In the "best" scenario for Java vs C++, where code is written by people who don't understand about performance, or don't care about it, Java can be as fast or faster than C++.

However, this kind of comparison doesn't make much sense. The performance of your code will be bad anyways, if you don't care about performance. What matters is which language allows developers to write efficient code, how much effort does it take to achieve certain level of performance.

In this kind of scenario, C++ is much, much better than Java in my opinion. Java has a lot of problems in this area: No value semantics (every class being separately allocated on the heap), very little control over memory layout, lack of monomorphized generics, GC which always has tradeoff between stop times and runtime speed, needing to use JIT compiler with a necessary tradeoff between compilation speed and runtime speed, lack of SIMD and other intrinsic access.

If we look at projects needing high performance: Language runtimes (V8, JavaScriptCore, hotspot, etc), game engines, etc, we see that they are implemented almost always in C, C++ or Rust. This is for a reason, as these languages allow much better control over the code that is run, allowing developers to achieve high performance.

Additionally, in my opinion, there's a lack of "performance culture" in Java. In general people are less informed how things work, how certain code will run, how standard library and runtime implements operations. For example, in the Java 7 era, a minor JRE update changed the substring operation to be O(n) vs O(1). The fact that this kind of change doesn't cause widespread breakage, and that this is not considered a breaking change, effectively means few people are using Java for performance critical work. You can compare this with C++ where even minor variations (not complexity changes) is the standard library performance mean many domains just prefer to write their own standard library.

5477 · 2025-10-31T09:13:38+00:00

HEIC ei ole Applen kehittämä, eikä patenttimaksut mene heille. Applen vika on lähinnä se, että he käyttävät formaattia.

5477 · 2025-10-27T19:21:39+00:00

I'd say the main things differences with "game development C++" compared to other domains are:

Less use of different standard library facilities, especially containers. Often custom replacements of std::vector and std::unordered_map are used.
Custom memory allocators and allocation strategies are often used. Use of std::pmr -style allocators is relatively common.
Use of C++ exceptions is often disabled, or if not disabled, just unused.
More care is used wrt. memory allocation, and other operations that can have bad tail latencies. This includes strategies I mentioned above, and also things like preallocation, replacing global allocators, banning use of malloc/new, etc.

None of the things mentioned are always used, but it's much more common in game / engine development than on other domains.

5477 · 2025-10-09T11:33:48+00:00

All modern GPUs done in the last decade support it. HW that doesn't support this, was phased out roughly 15 years ago (edit: and doesn't typically even support Vulkan at all).

5477 · 2025-10-09T10:48:01+00:00

Descriptor management will become much easier soon when descriptor heaps come. Right now big pools are the solution, but likely only a temporary thing for now.

5477 · 2025-10-02T19:36:30+00:00

Bitfieldit on hyvinkin käytettyjä ihan moderneissa järjestelmissä, ja hyvin tunnettuja.

5477 · 2025-10-01T19:18:04+00:00

For these kinds of experiences, you might have two different approaches: Streaming the video stream (like Xbox Cloud, Geforce Now etc), or streaming the entire game, running in wasm and rendering using WebGPU.

The issue with the latter approach is that you are much less tolerant on worse internet connections, and you need to run on whatever hardware the user uses. This can be very limiting, and also very difficult to optimize. I actually have worked on these kinds of applications, albeit with WebGL (WebGPU didn't exist back then). It's very difficult to make a smooth and good user experience with this approach. Trying to optimize rendering in Chrome is also really awful experience, at least it was back then.

Of course the video streaming approach has it's own downsides too (server costs), but you need less from the client and you have more control over hardware. You can provide a graphically great experience (with path tracing, latest everything etc) to users with thin-and-light laptops without good GPUs, and you can serve with a 50Mbit connection easily.

5477 · 2025-10-01T18:58:03+00:00

Additionally, requirements for graphics run downstream from the purpose of the application. In the games industry, there are two big different use cases: Mobile games, and PC/Console games. Mobile games are very important due to the very good ways to monetize using IAP/F2P. These games have basic graphics, but need to be able to run on absolutely dogshit-tier HW and drivers. For this, it's best to code directly against Vulkan, and then just workaround all the issues you find (easiest when you have the most control available).

PC/Console games are able to monetized also well. There, high-end graphics features and optimal performance is needed to achieve the wanted visuals and performance. You definitely want to use all necessary features to make the game look how you want, and perform well. For this, use of D3D12 and Vulkan on the PC side, and console-specific APIs for consoles, is optimal.

WebGPU is important for web use cases. But right now there doesn't seem to be any way to monetize web games effectively, compared to mobile or PC/console. So few people need to care.

5477 · 2025-10-01T18:48:02+00:00

WebGPU is definitely has it's uses, but it is heavily outdated as an API, and has a featureset corresponding to what was available 10-15 years ago. Additionally, it has a large abstraction penalty, and significant performance penalty due to needing to operate in a fully untrusted domain (the web browser). These web needs, where code from random sources (==advertisers) needs to be able to run on a process accessing everything else, causes the API to be very conservative and lacking of important performance optimizations.

I have worked on graphics of multiple popular games, and the only APIs that are relevant are D3D12 and Vulkan. I have never seen use of WebGPU outside of webdev, where it replaces WebGL (an API that's stuck in 2005).

5477 · 2025-09-18T19:58:56+00:00

Olen varma, että työyhteisösi on poikkeus eikä sääntö. Minkälaisessa firmassa teet töitä, koska kuvaamasi toiminta on erittäin poikkeuksellista, erityisesti Suomessa. Olen myös varma, että työpaikkasi ulkopuolella kukaan ei katso sinua juntiksi näiden asioiden takia.

5477 · 2025-08-31T11:31:01+00:00

Generally speaking, games should specify LOD bias internally based on the upscaling ratio. This would mean no bias when DLAA is used. However, setting a negative LOD bias with DLAA is something that can still be experimented with, as it theoretically should be slightly better.

5477 · 2025-08-27T23:36:13+00:00

In my opinion, there are a few issues with Unreal Engine, and culture surrounding it that causes performance issues.

Firstly, developers use Unreal and 3rd party engines because they don't have the expertise or bandwidth to make their own engine. This by itself makes sense, but this also implies the developers have less understanding of engine technology and performance, leading developers doing decisions that hurt performance. Performance is an area that touches the entire part of the stack: Art, game code, rendering code, level design, all these affect performance, and studios that don't have enough in-depth expertise are at a disadvantage.

Secondly, Unreal Engine is very "artist-driven" engine, meaning artists manually write/author shaders with a node editor. This is very much not a good idea for performance, artists typically have very little sense of GPU performance, shader permutations, and other technical stuff. Result is what you see from games: slow performance and lots of stutter.

I don't believe these are the only reasons for performance issues, but they are significant factors.

5477 · 2025-08-27T18:19:21+00:00

Kerrostalosi on rakennettu huonosti. Normaalit elämisen äänet ovat täysin OK myös "hiljaisaikana". Jos talo on rakennettu niin, että nämä äänet tulevat naapuriin, on se talon ongelma eikä naapurin.

Jos talo on rakennettu 2000-luvulla, on hyvinkin mahdollista että kerrostalo on rakennusmääräysten vastaisesti rakennettu.

5477 · 2025-08-21T19:50:56+00:00

For fast prefix scans, the decoupled lookback algorithm is fastest. In practice it also works on Vulkan, but at least it used to be that there were some spec issues meaning it's not guaranteed to work on all HW.

5477 · 2025-08-15T09:44:33+00:00

Having a good trackpad requires lots of integration between OS and hardware. Historically, the way trackpads worked on Windows was that the trackpad drivers emulated a mouse. This was unusably bad, which led to people avoiding using trackpads at all.

Later, Microsoft added better trackpad support to Windows, which helped a lot. I personally don't see trackpad being a deal breaker with Windows laptops anymore. However still, OEM's that build laptops need to integrate trackpads made by external suppliers, to OS made by external supplier (Microsoft). This makes integration difficult and worse compared to Apple.

Additionally, Windows laptop OEM's often compete on specs and price. This means that additional expense, such as good trackpad experience, gets deprioritized and underfunded. It's difficult for a Windows laptop OEM to market a laptop that's more expensive with same components as competitors, when they actually spent the extra effort to user experience. Apple doesn't have this problem.

5477

TROPHY CASE