Tag Archives: kernel

The uses of kernal threads

A novel approach to multitasking is assigning engine subsystems to run separate threads. The processor is what actually runs a code stream whilst the thread acts as an execution context for the processor.

A kernel thread is a kernel entity, like processes and interrupts handlers; it is the entity handled by the system scheduler. A kernel thread runs in user mode environment when executing user functions or library calls; it switches to kernel mode environment when executing system calls.

It stores the execution state of the 3 basic parts of the code stream; the stack which contains private data from execution, the registers which save and restore the thread, and the thread control block.

When the OS schedules a thread, it stores the registers of the current one and restores the registers of the new one. New thread starts running just where it left off.

It is fairly common for kernel code to create lightweight processes – kernel threads – which perform a certain task asynchronously. To see these threads, run ps ax on a 2.6 kernel and note all of the processes in at the beginning of the listing. The code which sets up threads has tended to be implemented again every time a new thread is needed, however, certain tasks are not always handled well. The current kernel also does not easily allow the creator of a kernel thread to control the behavior of that thread.

A kernel thread is created with the following line of code:

    struct task_struct *kthread_create(int (*threadfn)(void *data),

                                       void *data,

                                                       const char *namefmt, …);

Sometimes, a thread asks the kernel to do something that doesn’t need to execute instructions such as reading a block off the disk, then receive a packet from the network. These calls block inside the kernel.

The kernel starts the operation, puts the thread on a wait queue for when the operation completes, and schedules a new thread to run. It’s as if the call to schedule() only returns when the operation is complete: the stack and data registers are maintained

    Because kernel has full knowledge of all threads, Scheduler may decide to give more time to a process having large number of threads than process having small number of threads. Kernel-level threads are especially good for applications that frequently block.

The kernel-level threads are slow and inefficient. For instance, threads operations are hundreds of times slower than that of user-level threads.

    Since kernel must manage and then schedule threads as well as processes. It require a full thread control block (TCB) for each thread to maintain information about threads. As a result there is significant overhead and increased in kernel complexity.

Kernel-Level threads make concurrency much cheaper than process because, much less state to allocate and initialize. However, for fine-grained concurrency, kernel-level threads will still suffer from too much overhead. Thread operations still require system calls. Ideally, we require thread operations to be as fast as a procedure call. Kernel-Level threads have to be general to support the needs of all programmers, languages, runtimes, etc.


Usages of bloom and blur in games

Bloom, which is also called light bloom or glow, is a computer graphics effect used in video games, demos and high dynamic range rendering (HDR) to reproduce an imaging artifact of real-world cameras. The effect produces fringes (or feathers) of light extending from the borders of bright areas in an image, contributing to the illusion of an extremely bright light overwhelming the camera or eye capturing the scene.


The physical basis of bloom is that lenses can never focus perfectly, even a perfect lens will convolve the incoming image with an Airy disc, the diffraction pattern produced by passing a point light source through a circular aperture. Under normal circumstances, these imperfections are not noticeable, but an intensely bright light source will cause the imperfections to become visible. As a result, the image of the bright light appears to bleed beyond its natural borders.


The Airy disc function falls off very quickly but has very wide tails. As long as the brightness of adjacent parts of the image are roughly in the same range, the effect of the blurring caused by the Airy disc is not particularly noticeable; but in parts of the image where very bright parts are adjacent to relatively darker parts, the tails of the Airy disc become visible, and can extend far beyond the extent of the bright part of the image.

In HDR images, the effect can be re-produced by convolving the image with a windowed kernel of an Airy disc, or by applying Gaussian blur to simulate the effect of a less perfect lens, before converting the image to fixed-range pixels.


The effect cannot be fully reproduced in non-HDR imaging systems, because the amount of bleed depends on how bright the bright part of the image is.

As an example, when a picture is taken indoors, the brightness of outdoor objects seen through a window may be 70 or 80 times brighter than objects inside the room. If exposure levels are set for objects inside the room, the bright image of the windows will bleed past the window frames when convolved with the Airy disc of the camera being used to produce the image.


Current generation gaming systems are able to render 3D graphics using floating point frame buffers, in order to produce HDR images. To produce the bloom effect, the HDR images in the frame buffer are convolved with a convolution kernel in a post-processing step, before converting to RGB space. The convolution step usually requires the use of a large Gaussian kernel that is not practical for realtime graphics, causing the programmers to use approximation methods.

Ico was one of the first games to use the bloom effect. Bloom was popularized within the game industry in 2004, when an article on the technique was published by the authors of Tron 2.0. Bloom lighting has been used in many games, modifications, and game engines such as Quake Live, Cube 2: Sauerbraten and the Spring game engine. The effect is popular in current generation games, and is used heavily in PC, Xbox 360 and PlayStation 3 games as well as Nintendo GameCube and Wii releases such as The Legend of Zelda: Twilight Princess, Metroid A Gaussian blur is one of the most useful post-processing techniques in graphics yet I somehow find myself hard pressed to find a good example of a Gaussian blur shader floating around on the interwebs. The theory behind its value generation can be found in GPU Gems 3; Chapter 40 (“Incremental Computation of the Gaussian” by Ken Turkowski).Prime, and Metroid Prime 2: Echoes.