(I've googled for the possibility to write assembler-like instructions for DirectX 12, but have found nothing more than hacking the bytecode. Something I don't have the patience to do. So I need to deal with HLSL but I need to make few things clear)

I have thought of a simple example that demonstrates what exactly I need to know:

For the example I have two textures of the same size, both 2D and of the type of DXGI_FORMAT_R8_UINT. Let say 128x128 "pixels". One is inputted to the pixel shader and the pixel shader outputs the result to the other.

I want the shader to take the input byte, XOR it with 44h and output it to the render target.

My doubt is which of those two will happen:
(assuming for the example that the registers used in the GPU's ALUs are 16 byte wide)

case 1: the HLSL compiler loads the byte to the first component of a 16-bytes-wide vector register(or to the lowest 8 bits of the first 4-dwords-wide vector register).
and the rest of 15 bytes are just zeroed

case 2: HLSL compiler is wise enough to read the data in chunks of 16 bytes and load them into the 16 bytes of a 16 components vector register, propagate that 44h to another 16 bytes wide register, XOR it once and write a single 16 bytes chunk to the render target. (but I can't see it happen, because it says in MSDN that the unused components are zeroed. Not clear if they are just hidden from me or they was zeroed for real as in the first case....)

What about variables:

Would this

float fVar = 3.1f;

occupy the same type of register as this

float4  fVector = { 0.2f, 0.3f, 0.4f, 0.1f };  ?

(i'm sorry if i'm posting too often, but it is very hard for me to find something helpful in google)

@turanszkij So, there is yet another compiler that gets in the middle...

For the simple example above, I could for example read the texture as DXGI_FORMAT_R32G32B32A32_UINT and XOR it with 0x44444444. This way I will solve my problem from the HLL, without losing time with assembler for the GPU. The problem is my project is more complex than this simplified example. I try to run out of doubts by changing my solution. I could try to force some kind of parallelism by using only vector variables of four components in my code, but it is painful to guess how it works.

AFAIK, all recent GPU use 32bit rgisters and nothing else. A vec4 uses 4 registers, a byte uses 1 register. (Exception is AMD Vega, which brings back 16bit registers with twice ALU performance).

Also recent GPUs are scalar, there is no more native vec4 and the compiler always creates 4 instructions if you use them.

Native vector instructions date back to pre Fermi and pre GCN.

(Correct me if i'm wrong with anything)

1 hour ago, NikiTo said:

case 2: HLSL compiler is wise enough to read the data in chunks of 16 bytes and load them into the 16 bytes of a 16 components vector register, propagate that 44h to another 16 bytes wide register, XOR it once and write a single 16 bytes chunk to the render target. (but I can't see it happen, because it says in MSDN that the unused components are zeroed. Not clear if they are just hidden from me or they was zeroed for real as in the first case....)

I assume in your code each thread does the XOR on it's own data. This means that each thread uses it's own register and because other threads can't access this register what you suggest is impossible, or at least it makes no sense. Actually on every GPU groups of 4 neighbouring threads can share registers, but this is available only through extensions to the programmer, and even if the compiler utilizes this there would be no win in packing data around just so that one thread does a single XOR while the other 3 threads do nothing meanwhile (Remember threads operate in lockstep and all of them need work to do all the time if possible.)

Related: The only way to share data between threads efficiently is LDS memory. And you can use this only with compute shaders. Pixel Shaders are only good for simple brute force algorithms.

To look at final assembly code, you may look at vendor tools like NSight or CodeXL. (The latter at least works for OpenCL - not sure how far DX12 support goes.)

I would expect the compiler to produce 16 parallel XORs in each of those 4 threads(for the simple example above in the OP) giving me 16x4 totally parallel operations.

58 minutes ago, NikiTo said:

I would expect the compiler to produce 16 parallel XORs in each of those 4 threads(for the simple example above in the OP) giving me 16x4 totally parallel operations.
The all and any instructions in HLSL suggest to me that there are SIMD registers under the hood.

Ok, but then you can simply ready your bytes in blocks of 32bits and XOR them with 0x44444444 and write back 32bits again.

I guess what you have in mind is not that simple and then the answer probably again becomes: No, the compiler won't do such optimiziations for you, but you can do it yourself when possible, e.g. storing 4 counters in one int32, and incrementing all of them with one instructuon: counters += 0x01010101.

There are no more SIMD or MMX like registers like we have on CPU, instead a GPU processes 1 instruction on 32/64 threads, each of them operating on its own registers. This is transparent to the programmer and there is nothing hidden under the hood that transforms your code into something very different. 

You may give a more complex example that i can not solve with a simple trick as above...

58 minutes ago, NikiTo said:

I try to change my algorithms in a way to be able to run in pixel shaders on the 3D Engine with its own memory each one, because I guess 3D Engine is guaranteed to be the best optimized piece of hardware in any GPU(Compute Engine, they say, could not be even present on some GPUs)).

From your other thread i have the impression you work on an algorithm probably with some complexity that does not rasterize triangles?

Then compute shaders is for you and you won't benefit from graphics pipeline. GPUs without compute cpability - that's more than a decade back.

Graphics pipeline hase very restricted GPGPU capabilities - you need to do things very inefficient. (I would even say you can do nothing useful with pixel haders, except shading pixels)

It seems you are very wrong with your guess (!) Exception: Your algorithm is so tiny and simple that you can do it in pixel shader without any limitation, but if you don't know compute, you can't be sure. And even if, pixel shader has likely the same performance than compute shader.

Example: A N-Body simulation of 1024 planets.

Pixel shader: Every thread reads ALL 1024 planets to see how their gravity affects the threads body.

Compute shader: Every thread reads ONLY ITS OWN planet, stores it in LDS memory, now every thread has access to every planet. 15 times faster. Threads can communicate this way - you can do useful things.