In msdn article titled "Uploading Different Types of Resources" https://docs.microsoft.com/en-us/windows/desktop/direct3d12/uploading-resources, 
function named SetDataToUploadBuffer has two parameters named UINT alignment and UINT& offset. 

I am really confused between two. By offset I am assuming "from the beginning" how many bytes one wants to update or do operation on.
I have no idea about alignment but the call passes "sizeof(float)" to SetDataToUploadBuffer. Does this mean the caller meant to skip first float and update the rest of floats

in the buffer?

38 minutes ago, ritzmax72 said:

In msdn article titled "Uploading Different Types of Resources" https://docs.microsoft.com/en-us/windows/desktop/direct3d12/uploading-resources, 
function named SetDataToUploadBuffer has two parameters named UINT alignment and UINT& offset. 

I am really confused between two. By offset I am assuming "from the beginning" how many bytes one wants to update or do operation on.
I have no idea about alignment but the call passes "sizeof(float)" to SetDataToUploadBuffer. Does this mean the caller meant to skip first float and update the rest of floats

in the buffer?

In general terms alignment has to do with how data is placed in memory. For instance if you have 4 byte integers, they will typically be 4 byte aligned.  This means they could start on memory address 0, 4, 8, 12, 16 and so forth, anything divisible by 4. Likewise double precision floats (typically 8 bytes) are going to be 8 byte aligned, 0, 8, 16, 24 ....... you get the idea. This is enforced on a lot of architectures and you get the dreaded "bus error" if you do something wrong.  Mostly you don't have to worry about this because the compiler takes care of it, but it can happen if you are casting pointers around or doing something odd.  On intel CPUs I think it's technically not enforced but it used to be that if you misaligned stuff there would be a performance hit. It still may be true.

Alignment doesn't purely have to do with basic types. For instance if you have a struct that's 10 bytes in size but with 4 byte alignment, it means it will start on a memory location divisible by 4, but at the end there will be 2 padding bytes to put you back on 4 byte alignment.  The compiler will actually add these to the end of your structure so if you took it's size it will tell you it's 12 not 10, even though only 10 are used.  Again the compiler does this automatically but you can enforce other alignments with alignas. For instance this is from one of my classes.

template<int I> class alignas(8) TDLVHSgl : public CDLVHGrp
{
  .....
}

I'm not 100% sure what alignment  means in your context.  Often terms are overloaded but it's likely related.

Ha ha, probably too much information and not the right information, but maybe it helps.

return hr - return handler, OK/ not OK

UINT& byteOffset - getter result from function

alignment - memory align bytes (4, 8, 16 etc)

Adding on to what @Gnollrunner said, some data that the GPU's going to read will have a non-natural alignment. For example, the natural alignment of a float would be 4 (because a float is 4 bytes), but if you're going to read data out of a constant buffer, you need a 256-byte alignment for that data. So if I have a buffer, and I want to put 2 constant buffers in it, and I put the first one at offset 0, size 4, the second one can't go at offset 4, it needs to go at offset 256.

The data within the constant buffer still gets natural alignment, so if I have two constant buffers, each with two floats, the first CB would have floats at offsets 0 and 4, and the second would have floats at offsets 256 and 260.