Blog

# Floor and Ceil Versus Denormals on CPU and GPU

Sat
23
May 2026

Recently, I dove deep into floating-point numbers and their behavior. Somehow, this topic haunts me in my programming practice since I created Floating-Point Formats Cheatsheet back in 2013 and also released a comprehensive article The Secrets of Floating-Point Numbers in 2024.

This time, I would like to focus on one specific question:

What is the result of floor(-1.175493930432748e-38) ?

Note: Hexadecimal value of our input number is 0x807FFFFD.

Read full post »

Comments | #math #gpu Share

# DirectX 12 News from GDC 2026 - My Comments

Sun
15
Mar 2026

Game Developers Conference (GDC) just took place on 9–13 March 2026 (renamed this year to “GDC Festival of Gaming”). Microsoft announced lots of interesting news during the event regarding further development of DirectX 12, its accompanying libraries, and tools. I didn’t attend the conference this year, but the announcements were also published on their DirectX Developer Blog. In this article, I will gather and summarize these news items, provide links to the appropriate web pages, and include my comments.

When I was working at AMD, I was deeply involved in this area - writing code, publishing articles on the GPUOpen website, attending GDC, and even giving a talk there twice. Back then, I didn’t post much about it on my personal blog, as I would have needed to watch my words and secure corporate approvals. Now, as I’m just a programmer at Plastic - a small game development studio - I can observe these developments from the outside and comment on them freely, which I am going to do with brutal honesty 🙂 If I had a YouTube channel, I would record a “reaction” type of video, but since I’m writing a blog, this will be my reaction in text form.

Disclaimer: Everything in this article is based on information shared publicly by Microsoft and GPU vendors and could be gathered by any graphics programmer. No insider information was used.

Read full post »

Comments | #microsoft #directx Share

# Total Commander - a Plugin Supporting a Custom Archive Format - a New Article

Sat
07
Mar 2026

Today I would like to present my new article: "Total Commander – a Plugin Supporting a Custom Archive Format". In this article, we will design our own file format that allows multiple files to be packed and compressed into a single archive, similar to formats like ZIP or 7Z. Using the C++ language and the Visual Studio environment on Windows, we will then write a plugin for the Total Commander file manager that enables creating and manipulating such an archive, including freely adding and removing files inside it.

The article was first published few months ago in Polish in issue 5/2025 (120) of the Programista magazine. Now I have a right to show it publicly for free, so I share it in two language versions:

See also GitHub repository with the source code accompanying the article: sawickiap/TotalCommanderPluginTutorial

Comments | #windows Share

# A Formula for Overall System Load

Thu
26
Feb 2026

Some time ago I've shared my thoughts about coming up with a nice formula to calculate memory fragmentation. I've recently had another such math puzzle, this time themed around "system load". Below you will find the formula I developed, this time with an interactive demo!

The problem is this: Imagine a system that consists of several sub-systems, each having a gauge indicating the current load, 0...100%. It may be some real device like a computer (with CPU busy %, GPU busy % and the current memory consumption), some vehicle (a car, an airplane), or some virtual contraption, like a spaceship in a sci-fi video game (with the current engine load, force field strength, temperature that can make it overheat, etc.) Apart from the load of the individual subsystems, we want to show a main indicator of the overall system load.

What formula should be used to calculate it? All the load values, displayed as 0...100%, are internally stored as numbers in the range 0.0...1.0. The key principle is that if at least one subsystem is overloaded (at or near 100%), the entire system is considered overloaded. A good formula for the overall system load should have the following properties:

The output is 0 if and only if all inputs are 0. In other words, if any subsystem has load >0%, the overall system load is also >0%.
The output is 1 if at least one input is 1. In other words, it's enough for one subsystem to be fully loaded at 100% to consider the entire system loaded at 100%.
If the output is <1, any increase in any input value should result in some increase in the output value.

Note that these requirements don't specify what happens between 0 and 1. For example, should the output become 0.5 if just one input reaches 0.5, or only after all inputs reach 0.5? We have full freedom here.

#1. My first idea was to use AVERAGE(input[i]). It meets requirement 1 and 3, but it doesn't meet requirement 2, because it requires all inputs to be 1 for the output to become 1.

#2. My second idea was to use MAX(input[i]). It meets requirement 1 and 2, but it doesn't meet requirement 3, because for any input other than the largest one, a change in its value doesn't change the output.

#3. There is a more complex formula that meets all 3 requirements. It may be called the "inverse product" and it looks like this:

output1 = 1.0 - ( (1.0 - input[0]) * (1.0 - input[1]) * ... )

You can think of it as multiplying the "headrooms" left in each subsystem.

#4. Unfortunately, the formula shown above has a tendency to give very high values nearing 100% even for low input values, which is not very user-friendly. A result that is closer to MAX() reflects the overall system load better. Considering this, but still wanting to preserve our requirement 3, I ended up blending AVERAGE() with the inverse product 50/50:

finalOutput = (AVERAGE(input[i]) + output1) * 0.5

Here is an interactive demo of all the formulas described above. You can move the sliders to control the input values.

Further modifications are possible:

A different blend than 50/50 between the average and the inverse product could be used.
The final output could be shaped somehow, making it higher or lower in mid values to meet specific design needs, e.g. by raising it to some power, like 1.5.
While a specific input value increases gradually, there is a sharp transition in the behavior of the output when it becomes the highest of all inputs. It could be smoothed out somehow.

Comments | #math Share

# Graphics APIs – Yesterday, Today, and Tomorrow - a New Article

Tue
20
Jan 2026

Today I would like to present my new article: "Graphics APIs – Yesterday, Today, and Tomorrow". In this article, we will take a quick walk through the history of graphics APIs such as DirectX, OpenGL, Vulkan, and the accompanying development of graphics cards on the one hand, and video games on the other, over the years. We will not be learning how to program in any of these APIs. This article should be understandable and may be engaging for anyone curious about games or graphics, or at least for those who played games in childhood.

The article was first published few months ago in Polish in issue 4/2025 (119) (July/August 2025) of the Programista magazine. Now I have a right to show it publicly for free, so I share it in two language versions:

Comments | #productions #directx #vulkan #opengl #rendering Share

# State of GPU Hardware (End of Year 2025) - New Article

Mon
29
Dec 2025

I published a guest article by Dmytro “Boolka” Bulatov, providing an overview of the current GPU market in context of what features are supported on end-users machines:

» "State of GPU Hardware (End of Year 2025)" «

Comments | #gpu #hardware #directx Share

# How I Fixed My App Taking 5 Minutes to Start

Mon
22
Dec 2025

I recently got a new Windows PC, which I use for development. I work on a game based on Unreal Engine, and I build both the game and the engine from C++ source code using Visual Studio. From the very beginning, I had an annoying problem with this machine: every first launch of the game took almost five minutes. I don’t mean loading textures, other assets, or getting into gameplay. I mean the time from launching the app to seeing anything on the screen indicating that it had even started loading. I had to wait that long every time I started or restarted the system. Subsequent launches were almost instantaneous, since I use a fast M.2 SSD. Something was clearly slowing down the first launch.

Solution: open Windows Settings and disable Smart App Control. This is a security feature that Microsoft enables by default on fresh Windows installations, and it can severely slow down application launches. If you installed your system a long time ago, you may not have it enabled. Once you turn it off, it cannot be turned back on - but that’s fine for me.

Full story: I observed my game taking almost five minutes to launch for the first time after every system restart. Before I found the solution, I tried many things to debug the problem. When running the app under the Visual Studio debugger, I noticed messages like the following slowly appearing in the Output panel:

'UnrealEditor-Win64-DebugGame.exe' (Win32): Loaded (...)Engine\Binaries\Win64\UnrealEditor-(...).dll. Symbols loaded.

That’s how I realized that loading each .dll was what took so long. In total, launching the Unreal Engine editor on my system requires loading 914 unique .exe and .dll files.

At first, I blamed the loading of debug symbols from .pdb files, but I quickly ruled that out, because launching the game without the debugger attached (Ctrl+F5 in Visual Studio) was just as slow - only without any indication of what the process was doing during those five minutes before anything appeared on the screen.

Next, I started profiling this slow launch to see what was happening on the call stack. I used the Very Sleepy profiler, as well as Concurrency Visualizer extension for Visual Studio. However, I didn’t find anything unusual beyond standard LoadLibrary calls and other generic system functions. That led me to suspect that something was happening in kernel space or in another process, while my process was simply blocked, waiting on each DLL load.

Naturally, my next assumption was that some security feature was scanning every .dll file for viruses. I opened Windows Settings → Protection & security → Virus & threat protection and added the folder containing my project’s source code and binaries to the exclusions list. That didn’t help. I then completely disabled real-time protection and the other toggles on that page. That didn’t help either. For completeness, I should add that I don’t have any third-party antivirus software installed on this machine.

I was desperate to find a solution, so I thought: what if I wrote a separate program that calls LoadLibrary on each .dll file required by the project, in parallel, using multiple threads? Would that “pre-warm” whatever scanning was happening, so that launching the game afterward would be instantaneous?

I saved the debugger log containing all the “Loaded … .dll” messages to a text file and wrote a small C++ program to process it, calling LoadLibrary on each entry. It turned out that doing this on multiple threads didn’t help at all - it still took 4–5 minutes. Apparently, there must be some internal mutex preventing any real parallelism within a single process.

Next, I modified the tool to spawn multiple separate processes, each responsible for loading every N-th .dll file. That actually helped. Processing all files this way took less than a minute, and afterward I could launch my game quickly. Still, this was clearly just a workaround, not a real solution.

I lived with this workaround for weeks, until I stumbled upon an article about the Smart App Control feature in Windows while reading random IT news. I immediately tried disabling it - and it solved the problem completely.

Apparently, Microsoft is trying to improve security by scanning and potentially blocking every executable and .dll library before it loads, likely involving sending it to their servers, which takes a very long time. I understand the motivation: these days, most users launch only a web browser and maybe one or two additional apps like Spotify, so every newly seen executable could indeed be malware trying to steal their banking credentials. However, for developers compiling and running large software projects with hundreds of binaries, this results in an egregious slowdown.

Comments | #windows Share

# Secrets of Direct3D 12: The Behavior of ClearUnorderedAccessViewUint/Float

Wed
17
Dec 2025

This article is about a quite niche topic - the functions ClearUnorderedAccessViewUint and ClearUnorderedAccessViewFloat of the ID3D12GraphicsCommandList interface. You may be familiar with them if you are a programmer using DirectX 12. Their official documentation - ClearUnorderedAccessViewUint and ClearUnorderedAccessViewFloat - provides some details, but there is much more to say about their behavior. I could not find sufficiently detailed information anywhere on the Internet, so here is my take on this topic.

Read full post »

Comments | #directx Share

Older entries

Blog

Bluesky

Bookmarks

Blog Tags