I've finally setup a nice decompression thread that takes care of everything (almost) without any hiccups from the rendering side.

Right now I'm only decompressing textures in full size.
When a texture it's loaded, the average color (or 1x1 mip-map) is loaded right away (the 1x1 mip is stored in the file header without any need for decompression). Then a task for decompressing the full size texture is created and the decompression starts right away.
Right now it's either 1x1 or full-size, next I'll have to pick actual intermediate resolutions depending on the image being rendered.

One nice thing that I found out is that DX10 is thread-safe by default (no need to set special flags, making one fear for degraded performance). So, the actual texture creation and decompression is all happening in a thread separate from the main loop.
As I mentioned before, a texture decompressor will unpack data in slices using OpenMP. This allows me to use whatever cores I have to decompress one texture at the time as fast as possible (more cache coherent than trying to decompress different textures at once).
Currently, during load I can see all 4 cores being used to the maximum (more or less).. it's a nice feeling 8)

To minimize initialization times, I've also implemented a simple Direct3D texture object cache.
Every time a texture is released by the engine, it doesn't actually get immediately released in Direct3D but rather added to a free list (unlike the Wikipedia article, I'm actually not using linked-lists) where it can be picked up again if there is another request for a texture with the same characteristics.. otherwise it will be released from D3D after a few frames being unused.
Cache aside, I'm mostly counting on the multi-threading to cover up for all those potential stalls incurring from resource management in D3D.

The next big step will be to continuously "resize" textures depending on the needs of the frame being rendered.
This should happen lazily to avoid too much work by the decompression system.
The reason why one would want to resize textures is to economize on memory, but that doesn't have to happen at every frame for every texture. It makes more sense to keep a texture at 1024x1024 even if the next frame only needs a 512x512, rather than putting to work the decompression. The 1024x0124 may be needed soon again and the rasterizer is going to pick the right mips regardless of the maximum resolution.

In general I like the idea of progressive quality. I like the idea of drawing geometry with whatever texture resolution I have. This way I can theoretically keep a consistent frame rate and the quality of the textures will change depending on how fast the decompression can happen (which depends on the CPU/GPGPU power).

Next next I'll have to worry about geometry.. that's trickier especially when using a lot of complex materials.. but hopefully some coworkers can help there ;)

wooooo
zzzzzzzzzzz

I've been busy between work and not work !

Recently I tried Google Apps for my father's web site. I like the Google Sites thing which is an evolution of JotSpot, a company that Google bought over a year ago.
Very easy to set things up, yet I still have to change th HTML to do certain things. All those WYSIWYG editors seem broken to me. It's usually very hard to place a cursor when one really wants, or to get rid of some formatting. Very hard to get rid of a link being assigned as text is typed and incredibly complicated to extend an hyperlink effect to text added before an existing hyperlink.
I also never quite understood the logic by which things get selected. For example even in MS Word, when I go select a line of text, the selection will snap to include the newline character. Or sometimes I select some text from bottom to top and a whole chunk of text gets selected !

In Google Sites I can't find a way to select a whole table while changing hyperlinks for a picture it doesn't really work with what I have.
Still it's nice to setup sites quickly, though I wish Google Apps would allow Google Sites to take over the domain, rather than redirecting to some complicated URLs.

Speaking of Direct3D 10, I've been using it for a while now. Nothing too special, but it's interesting the tendency to shift rendering properties, such as texture sampling and blending from the engine to the HLSL code. On one side it's a pain to try take over those stats over the shader (see Shader Reflection). Some complex passages need to be done to for example replace texture addressing.. but then again, maybe those things should be translated into shader permutations: even when starting from one generic shader, perhaps different shaders should be created depending on the material properties.

Recently I also tried to render a scene using points rather than triangles. Much to my surprise, points rendering (on NVIDIA GT8800 Ultra) was about 3 times slower.
I'm told that moder graphics cards are optimized for triangles but still.. rendering points should be so much faster !!
My goal was to speedup rendering of objects that are rather complex but that are being projected distant enough so that triangles are no bigger than one pixel.
Ideally then one would also take into account camera focus to use larger points in place of triangles when they are going to be smoothed by out of focus post processing.

mumble mumble

A quick note to express an opinion on Direct3D 10.
It seems very focussed on static mesh rendering, but has no support for direct primitive rendering like OpenGL. So, once again I have to write a layer to be able to draw lines and polys for debugging and quick prototyping.
Direct3D 10 has this "state objects" concept, so now changing states has to be done either selecting different predetermined effect's "techniques" (a technique can select different states) or one has to change states by creating state objects for every combination... what a pain !

I've moved form vertex/pixel shaders to "effects". I still have to see how effects handle render targets with annotations, but it seems like a not very well defined matter. For one thing, nVidia's FX Composer 2 seems to be the better tool to building effects, but at the same time it doesn't support Direct3D 10.. geezz

As GPU programmability is improving, it feels restrictive to use Direct3D 10. Interfacing C++ with shaders is a pain.. but at the same time shaders make it very easy to write highly parallel code.

ummmmmmmm