Doing the MegaTexture thing
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
- Davide's blog
- Login to post comments
hhhmm i dont really
hhhmm i dont really understand, if the mip level is higher than it should be its not only a memory/caching issue, but visual quality is also affected, you get aliasing artifacts. so are you saying you are going to use the 1024x1024 where only 512x512 is needed to avoid extra decompression or that you will load the 512x512, but also keep the 1024x1024 in memory? Also what about trilinear filtering? Seems like you need all the mips between the min and max level.
Also another case. What if you have an object close to camera so it only needs mip level 0 and 1, but then you have the same object far away and it needs levels 3 and 4. Are you going to load level 2 or not?
I forgot to specify that I
I forgot to specify that I also upload all mip levels below 8)
In fact I wish I could reclaim only the memory of the high level so that I don't have to build a new texture when I can lose the highest (as highest resolution) level.. but them maybe memory would get too fragmented.
So when you decompress the
So when you decompress the pixel data into memory, I assume you still need to call some dx10 method to actually create the texture?
Yes, I either call
Yes, I either call CreateTexture() or get a texture from the free-list and upload the data with UploadSubResource() (faster than doing map()/unmap() because those involve making the resource writable by the CPU and that kills overall performance (most likely the texture gets put in system memory anyway)).
I see.... I had a case where
I see....
I had a case where creating and releasing textures at runtime was really affecting performance. The textures were used for fullscreen effects so they were all large render targets, and had to be in vram, but the GPU was running out of video memory, so I am not sure what it was doing exactly, but possibly it was swapping some other resources to system memory to free up space for the render targets.
Reason why they were dynamically created and released every frame was because the window in which the application ran was resizeable. But eventually I changed it to have all render target textures permanently in vram. So every time the resolution changed, i had to release all vram resident resources and then rebuild them. This was causing some lag after resizing, but performance got much better.
freaking APIs...
I really wish that I could do my own memory management.. I wish that there were no hidden latencies when creating and destroying textures or no hidden "resort to system memory" kind of back-end tricks.
Unfortunately I don't know how much room does had a driver when it comes to dealing with DX10 way of doing things.
Recently I had a write a quick preview tool and I found myself using OpenGL and GLUT. More and more I see less use for DX10, because it doesn't provide enough low level and yet it's too complicated to immediate use.
I think that "real" developers should be provided with lower level resource access.
When dealing with complex scenes, data management becomes the biggest issue.
Recently I had a write a
Recently I had a write a quick preview tool and I found myself using OpenGL and GLUT.
What's this talk about OpenGL? 8P ha ha ha ... Just teasing. Have you looked into using Processing? It may or may not be ideal for what you need ... probably not though.
Yeah, doing stuff on the PC end can be a pain because you don't have control. Maybe DX11 will give you the features you need?
Recently I had TO write
I've heard of Processing. I also saw some cool ray tracing and photon mapping applet written in Processing (can't find it now !)
I guess it's basically a framework running using the Java Virtual Machine (?)
Something cool to look at.. but not terribly useful if one is not targeting the web and already has a good framework and good knowledge of C++ 8)
I dunno about DX11 fitting my needs. I doubt it. I've heard that NVidia has been showing a DX11 preview around, but I haven't seen anything myself... mumble mumble
Well if you want low level
Well if you want low level access to resources, thats what consoles are for =)
Anyway I agree. I remember in the old days you could actually do more manual resource management on PC. And it is not only textures.
Vertex/Index data and shaders also get managed by directx
I guess there is a time for
I guess there is a time for automatic resource management and a time for manual (as in custom) resource management.
About consoles.. I'm a bit afraid on what may happen for the next generation. Sony has definitely tripped with their (supposedly !) attempt to ditch discrete graphics once.. and the rumor has it that Microsoft is also going to shift more power on the GPU.. so we may end up with more of the same, while personally I'd like to see more integration.
The "big wigs" of games' 3D graphics programming tend to want more control, but they are also usually on PC (those on consoles are too busy optimizing for the current generation 8).
Maybe this is related ...
Geospatial Texture Streaming From Slow Storage Devices
..seems like another paper
..seems like another paper about the MegaTexture thing...
HHmmmm 'geospatial'....
HHmmmm 'geospatial'.... cool word =)
A small step for a
A small step for a programmer, a big step for humanity !!!
A small step for a
A small step for a programmer, a big step for humanity !!!
That's not very geospatial thing to say sir! 8P
Reminds me I should pick a
Reminds me I should pick a name for the texture thing (something more meaningful than the file extension name 8).. but I doubt I'd go as far as picking some interstellar-travel-evoking nomenclature !
So you mentioned 4 threads
So you mentioned 4 threads and Dx10, and I am curious what is your system setup?
Currently 4 cores Intel CPU
Currently 4 cores Intel CPU and G80.. but aiming to eventual many-cores platforms.
I'm looking to get a 4 core
I'm looking to get a 4 core system in a month or two myself; I'm assuming they're 64-bits?
I think they all support 64
I think they all support 64 bit. Though at work my main machine is running Vista 32.. using only 3GB of the 4 available.. sad.
Are you also planning on
Are you also planning on doing some multi core programming?
Quad core 3.2ghz is $1500, quad 2.4 is $200 while dual core 3.2 is also $200 and for things like games will outperform the 2.4 quad.
That's some crazy
That's some crazy price-points! :) I'm planning on doing multi-core programming and R&D ... at least at home anyways. I'll just go ahead and get Vista64 (not that I'm a Vista fan, but it's inevitable) ... :-/
My guess is that today's motherboards allow things like swapping out a 4-core CPU to an 8-core CPU, etc? Or is that pipe dreaming? :)
yeah, i am sure its all just
yeah, i am sure its all just marketing, i dont see why a 3.2ghz quad core should be $1300 more than a 2.4ghz one.
i am also thinking of buying a new pc. probably going to go with the core 2 duo 3.16ghz and Vista 64bit.
i havent seen an 8-core CPU on any of the websites i've been pricing out the new pc. do 8-core cpus even exist?
The one I use at work is
The one I use at work is 8-core ... or maybe it's two 4-cores ... boy ... this is getting confusing! 8P
There is no 8 cores out yet.
There is no 8 cores out yet. I think the first one from Intel should be based on Nehalem... I think pretty much everyone is confused with these things nowadays.. (me included 8)
Ah, it's a dual 4-core
Ah, it's a dual 4-core machine then ... how confusing. 8P I was going to say that maybe I should wait and get an 8-core machine ... but (for now), I'll just get a motherboard that will be able to support that (if they exist). Nothing like those early revision hardware bugs to deal with. :)