Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Sample a Texture2D with the CPU


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 NickUdell   Members   -  Reputation: 288

Like
0Likes
Like

Posted 13 June 2012 - 07:03 AM

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
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.

Sponsor:

#2 mhagain   Crossbones+   -  Reputation: 8282

Like
4Likes
Like

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.

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 NickUdell   Members   -  Reputation: 288

Like
0Likes
Like

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.

#4 Tordin   Members   -  Reputation: 604

Like
1Likes
Like

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.
"There will be major features. none to be thought of yet"

#5 NickUdell   Members   -  Reputation: 288

Like
1Likes
Like

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.

#6 Tordin   Members   -  Reputation: 604

Like
2Likes
Like

Posted 14 June 2012 - 05:32 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.

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

Edited by Tordin, 14 June 2012 - 05:33 AM.

"There will be major features. none to be thought of yet"




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS