I`m reading through DirectX documentation. I`m want to read/edit individual pixels on a texture and from the back buffer. I need a pointer to where I should be looking. Functions names alone aren`t very suggestive. I`m not looking for exact function names, I know the protocol varies from one DirectX version to another. I need some general guidance.

Unfortunately the very term differs between API levels. In D3D9, its called “texture locking” (https://docs.microsoft.com/en-us/windows/win32/api/d3d9helper/nf-d3d9helper-idirect3dtexture9-lockrect)

And in the newer API its called “mapping” of the resource. (https://docs.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d11-id3d11devicecontext-map)

The concept is the same though: You tell the GPU to offer you a pointer to the textures data. This involves telling the GPU when creating the texture, and imposes certain restrictions, as well as having a considerable performance overhead (if you happen to lock/map a texture that is currently processed by the GPU, it forces the CPU to stall).

Not sure about the backbuffer though.

so locking/mapping has to be done on both textures and the back buffer? The back buffer resides on GPU memory as well ( short lived as it may be)

Calin said:
so locking/mapping has to be done on both textures and the back buffer? The back buffer resides on GPU memory as well ( short lived as it may be)

Locking the backbuffer is kind of special.
In D3D11, you have to first copy the backbuffer to another texture using CopyResource: https://stackoverflow.com/questions/10623787/directx-11-framebuffer-capture-c-no-win32-or-d3dx; and then you map that.
In D3D9, you can call GetBackbuffer and lock it, given that you pass the right parameters when creating the swapchain (https://docs.microsoft.com/en-us/windows/win32/direct3d9/accessing-surface-memory-directly; see below)

Thanks for sheeding light Juliean

Note that you're very unlikely to actually get a pointer to “the backbuffer” as used by the GPU. It is unlikely to be structured like a linear RGBA bitmap in practice in the hardware. Instead, “locking the backbuffer” means “resolve/copy the backbuffer to a memory chunk, then give you a pointer to that” and the “unlocking the backbuffer” means “render the memory you edited as if it were a full-screen texture, back into the color buffer.” Even though the calls may be called “GetBackbuffer()” and “LockBuffer()” that's just some API magic that hides the actual copies under the covers.

It's almost never the right thing to do to stall all rendering such that you can poke a few bits into the backbuffer. Generally, you'll want to poke bits into a system memory texture, and then blit that texture to the screen (perhaps using alpha testing.) The only case where you want to read back the back buffer is if you have a “take screen shot” function.

hplus0603 said:
Instead, “locking the backbuffer” means

Is that a D3D 11 only case or it`s a specific across all DirectX versions starting DirectX9 AD

Calin said:
Is that a D3D 11 only case or it`s a specific across all DirectX versions starting DirectX9 AD

Its a reality within the GPUs hardware, which the newer APIs reflect clearly while the older ones did the magic behind the scenes. In general you cannot get pointers to GPUs RAM directly, only one some consoles. So there always has to be some datatransfer to RAM if you want to read something back to the CPU-side. Thats one reason you have to lock and cannot just say “give me pointer to texture memory” (the other being to synchronize read/writes between CPU and GPU).
However for most normal textures, the GPU has the option to certain tricks, like place a texture that you mark as CPU read/write-enabled directly into RAM, which for backbuffers is not and option.

Juliean said:
read back

I got it

The “locking really just copies the data” started with DirectX 8 or so, when hardware started becoming asynchronous with hardware-transform-and-lighting (original GeForce, Radeon, cards.) Exactly which drivers implemented it in which way in what driver versions varies, of course, but on modern systems, there is no “poking at the bits for real" at all.