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
1
Sample a Texture2D with the CPU
Started by NickUdell, Jun 13 2012 07:03 AM
5 replies to this topic
Sponsor:
#2 Members - Reputation: 3828
Posted 13 June 2012 - 09:23 AM
Keep a copy of the texture data in system memory and then it's just a simple array lookup.
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.
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.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#3 Members - Reputation: 263
Posted 13 June 2012 - 01:08 PM
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.
Sole Creator of Pigment - a procedural, block-base space trading sim.
PhD student working on medical imaging at the University of Southampton.
Enjoyer of games, films, books and cider.
PhD student working on medical imaging at the University of Southampton.
Enjoyer of games, films, books and cider.
#4 Members - Reputation: 515
Posted 14 June 2012 - 02:02 AM
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.
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.
"There will be major features. none to be thought of yet"
#5 Members - Reputation: 263
Posted 14 June 2012 - 03:58 AM
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.
Sole Creator of Pigment - a procedural, block-base space trading sim.
PhD student working on medical imaging at the University of Southampton.
Enjoyer of games, films, books and cider.
PhD student working on medical imaging at the University of Southampton.
Enjoyer of games, films, books and cider.
#6 Members - Reputation: 515
Posted 14 June 2012 - 05:32 AM
That, Sir, is a excellent approach! and make sure to post the results!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.
Edited by Tordin, 14 June 2012 - 05:33 AM.
"There will be major features. none to be thought of yet"
