Sign in to follow this  

How DX handles surfaces

This topic is 2317 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

It's only a curiosity, I wonder how DirectX handles surfaces because i tried to make my own ones in C++ (array of 3-byte rgb colors) and my render functions were so slow, also my application crashed a lot of times.

Share this post


Link to post
Share on other sites
In the context of Direct3D, surface objects encapsulate handles to physical or virtualized graphics memory, which often resides on the GPU when the data associated with it is used for rendering. Modern graphics hardware can be tens to hundreds of times faster on simple rasterization operations than a CPU.

Application crashes are usually caused by bugs in your logic. Often, graphics-related crashes arise because you try to write to (or read from) memory addresses that are not available for your application; this is commonly caused by incorrect pointer arithmetic (for example, you make incorrect assumptions about image dimensions or scanline width).

Application slowness is generally caused by lack of optimization, if the algorithms themselves are trivial. For example, 4-byte vectors are often used to represent pixels instead of 3-byte ones, because 4 bytes aligns readily with 32-bit registers and bit-level operations. Even though you might think that the extra byte is only a memory burden, the alignment benefits improve actual performance greatly. And this is just a simple example.

Low-level optimization of code is not easy, as it requires solid understanding of all the systems involved in the operations.

Share this post


Link to post
Share on other sites
[quote name='ArgusMaker' timestamp='1313079134' post='4847743']
What if I want to write/read data in the gpu memory?
[/quote]

You can't read data directly, typically you'll have to pull it back to CPU memory (which will be a slow process) and then do your thing. This is slow for a number of reasons. Bandwidth from GPU to CPU can be poor on some (mainly older) hardware, and reading from the GPU normally involves having to stall the pipeline. One of these on it's own can kill your performance.

A better way of doing this is to keep two copies of data for each surface; one in CPU memory and the other in GPU memory. Work on the CPU memory copy, and when the time comes to draw update the GPU copy of it. This gives you data local to the processor that is doing the heavy work each time, but does cost a little bandwidth. It's not as bad as you might think however, as bandwidth from CPU to GPU is always going to be quite good.

The best way is to rethink the way you're doing your drawing. You seem to have a "do everything on the CPU" mindset, and modern graphics hardware and APIs aren't really made for that kind of workflow. Instead You should be looking to use shaders for running computation on the GPU, and playing to the strengths of the platform.

Share this post


Link to post
Share on other sites

This topic is 2317 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this