I'm using SlimDX and Direct3D11 and I have a Texture2D created by loading from a file. I want to use this, and a couple of other textures to build a set of procedural textures at runtime - however I don't want to use the GPU as it's already very busy doing other things.

Unfortunately I can't find any way of sampling a Texture2D outside of HLSL or using Texture2D.SaveToStream() and skipping through to the pixels I want manually.

Is there a simpler way of doing it? Something similar to HLSL's Texture2D.Sample(sampler,coords) or am I going to have to wade through the data stream?

Thanks

Keep a copy of the texture data in system memory and then it's just a simple array lookup.

BUT.

Are you really quite certain about the "I don't want to use the GPU as it's already very busy doing other things" part? Chances are that it's nowhere near as busy as you think it is, and even if so, the bottleneck on your program from creating procedural textures at runtime on the CPU (and then having to upload them to the GPU as dynamic texture resources) is very likely going to be FAR higher than doing so on the GPU.

In other words you're talking about something in the region of accepting a 100% performance overhead on the CPU side (especially if the CPU needs to block while uploading one of those textures) in exchange for something like a 5% or 10% performance saving on the GPU. That seems like it's the wrong way around to me.

I was planning to build the CPU implementation on a separate thread so I could run it with low priority and build the textures slowly. It's a space game and I'm actually limiting the number of procedurally-textured objects on screen at any one time to 8 or 9, and due to the distances involved, this will update very slowly - so I have in the order of several minutes to actually generate the new textures - this in turn allows me to build very detailed (many octaves of fBm noise) texture representations without causing stuttering due to the GPU currently generating a large texture while my render thread waits.

Even if you build it on another thread, it´s probably gona take alot longer. ALOT longe than building it on the gpu.
i mean, the gpu have like 1k cores, Or more/less depending on chip. but it´s far more than 8 cores.

So i have to agree with what mhagain said, it sounds wrong to do it on the cpu.
you could have the cpu to calculate what the gpu should do on the other thread but not build the texture itself.

Hmm I see your point, I'll do a GPU implementation for now then and when it comes to optimization later I'll write up a CPU implementation and test them side by side.

Hmm I see your point, I'll do a GPU implementation for now then and when it comes to optimization later I'll write up a CPU implementation and test them side by side.

That, Sir, is a excellent approach! and make sure to post the results!