@hwnd%

[Richard Russell]

The obvious bit that stands out are the 2 single byte elements in the DEPTH_STENCIL_DESC, these are coded by the compiler in 32bit mode which ads the padding automatically (so AI says),

If your 32-bit structure is working that can't be right, because there's no 'automatic padding' in BBC BASIC - the structure members are always close-packed with whatever size you've declared them as (one byte in the case of depthStencilDesc.StencilReadMask&). Indeed, from the declarations you listed, the subsequent FrontFace{} and BackFace{} structures are not even 4-byte aligned.

That's probably quite significant, because if there isn't a requirement for 4-byte alignment in the 32-bit version it's probably the case that there's no requirement for 8-byte alignment (or even 4-byte alignment) in the 64-bit version! So maybe the AI is giving misleading information.

Indeed, from a quick glance, there's nothing in any of the structures you listed that would make me think you need to make any changes at all between 32-bit and 64-bit mode. I might be wrong, but the obvious candidates for changes being needed (pointers and handles - which are often pointers under the hood) don't seem to be present at all.

But it all comes down to how the structures are declared in C and whether the compiler's padding rules are set differently in the 32-bit amd 64-bit builds. If they are, all bets are off.

[Richard Russell]

Indeed, from a quick glance, there's nothing in any of the structures you listed that would make me think you need to make any changes at all between 32-bit and 64-bit mode.

I asked Gemini AI the direct question:

In respect of the Windows D3D11_DEPTH_STENCIL_DESC and D3D11_DEPTH_STENCIL_VIEW_DESC structures (and their sub-structures), are there any differences between 32-bit and 64-bit builds? Do any of the members change size or alignment?

and its answer was:

No, there are no functional differences in size or alignment for these specific structures between 32-bit (x86) and 64-bit (x64) builds.
Because these structures consist entirely of fixed-size types like UINT, BOOL, and enums (which are 4 bytes in the Windows C++ environment), they do not contain pointers or size_t members that vary by architecture.

As that agrees with my own analysis, it may be right.

[Ric]

Thanks Richard, it is a bit disappointing because I thought I was nearing the end of what the problem could be. I'll try AI with the same question for the rest of the structures and see what happens.

[JeremyNicoll]

... and definitions

Code: Select all

  DIM D3D11_DEPTH_STENCILOP_DESC{StencilFailOp%,StencilDepthFailOp%, \
  \ StencilPassOp%,StencilFunc%}

  DIM D3D11_DEPTH_STENCIL_DESC{DepthEnable%,DepthWriteMask%,DepthFunc%, \
    \ StencilEnable%,StencilReadMask&,StencilWriteMask&, \
    \ FrontFace{}=D3D11_DEPTH_STENCILOP_DESC{}, \
    \ BackFace{}=D3D11_DEPTH_STENCILOP_DESC{}}

If i use these in 32bit mode all works fine so i can presume that the variable/enumerations are correct and the alignment of the structures is incorrect.

How can something "work fine" but have "alignment ... incorrect"?

The obvious bit that stands out are the 2 single byte elements in the DEPTH_STENCIL_DESC, these are coded by the compiler in 32bit mode which ads the padding automatically(so AI says), I have tried adding pading and all is fine.

Do you mean eg:

Code: Select all

  DIM D3D11_DEPTH_STENCIL_DESC {DepthEnable%,DepthWriteMask%,DepthFunc%, \
       \ StencilEnable%,StencilReadMask&,StencilWriteMask&, \
       \ Fill1&, Fill2&, \
       \ FrontFace{}=D3D11_DEPTH_STENCILOP_DESC{}, \
       \ BackFace{}=D3D11_DEPTH_STENCILOP_DESC{}}

When it comes to 64bit mode when the 2 extra bytes of padding are added this still leaves a DWORD missing

How do you KNOW? What precisely do you mean by "missing"?



I wrote a reply to this several days ago and it never appeared; in the course of that I googled for terms like:

alignment in D3D11_DEPTH_STENCIL_DESC

and I just did so again but not (I suspect) with the exact-same terms. THIS TIME googling for

field alignment in D3D11_DEPTH_STENCIL_DESC

showed (in the AI-generated summary) something odd (not what I remember from last time):

The D3D11_DEPTH_STENCIL_DESC structure is used to define the depth-stencil state in Direct3D 11 via the ID3D11Device::CreateDepthStencilState method. It controls how the output-merger stage performs depth and stencil testing. 

Field Breakdown and Structure Alignment
The structure is defined in d3d11.h and generally follows standard C++ padding rules for 32-bit and 64-bit systems. 

    BOOL DepthEnable (4 bytes): Enables depth testing.
    D3D11_DEPTH_WRITE_MASK DepthWriteMask (4 bytes): Enumeration (0 or 1).
    D3D11_COMPARISON_FUNC DepthFunc (4 bytes): Enumeration (comparison function).
    BOOL StencilEnable (4 bytes): Enables stencil testing.
    UINT8 StencilReadMask (1 byte): Identifies portion of depth-stencil buffer for reading stencil data.
    UINT8 StencilWriteMask (1 byte): Identifies portion of depth-stencil buffer for writing stencil data.
    Padding (2 bytes): Implicit padding to align the next 4-byte member.
    D3D11_DEPTH_STENCILOP_DESC FrontFace (8 bytes): Structure (2 x D3D11_STENCIL_OP, 1 x D3D11_COMPARISON_FUNC = 3 x 4-byte enums, however, D3D11_DEPTH_STENCILOP_DESC is typically packed tightly).
    D3D11_DEPTH_STENCILOP_DESC BackFace (8 bytes): Structure (same as above) 

I added the colour.

I thought I recalled "D3D11_DEPTH_STENCILOP_DESC" being 4 x 4 bytes not the 8 bytes that the text above says. And note it also says that those 8 bytes are madeup of 3 x 4 bytes ... packed tightly. I think that's AI fiction ... especially as when I asked:

D3D11_DEPTH_STENCILOP_DESC alignment

I got:

Structure Breakdown (32-bit/64-bit alignment)

    StencilFailOp (D3D11_STENCIL_OP): 4 bytes (Enum)
    StencilDepthFailOp (D3D11_STENCIL_OP): 4 bytes (Enum)
    StencilPassOp (D3D11_STENCIL_OP): 4 bytes (Enum)
    StencilFunc (D3D11_COMPARISON_FUNC): 4 bytes (Enum) 

Total size: 16 bytes.

Key Alignment and Usage Considerations

    Alignment: The structure is packed tightly. On modern 64-bit Windows systems, the structure remains 16 bytes due to the 4-byte enum size.

I also googled for: D3D11_DEPTH_STENCIL_DESC alignment
and got (I think) rubbish:

The D3D11_DEPTH_STENCIL_DESC structure is used in Direct3D 11 to define the depth-stencil state via the ID3D11Device::CreateDepthStencilState method. 

Alignment and Structure Details:

    Alignment: The structure consists of boolean (BOOL), enumeration (D3D11_DEPTH_WRITE_MASK, D3D11_COMPARISON_FUNC), and 8-bit integer (UINT8) types. It adheres to standard C++ structure alignment rules, with members typically aligned on 4-byte boundaries.

    Size: The structure is relatively small, consisting of two bools, two enums, two D3D11_DEPTH_STENCILOP_DESC structs (which contain 4 bytes each), and a UINT8 mask.

My colouring again... I keep getting different answers!

... so i have tried the obvious and padded this with a DWORD. Unfortunately this still does not work.

Do you mean you followed Fill1& and FIll2& with Fill3% ? It seems unlikely (to me) that if all the fields inside D3D11_DEPTH_STENCILOP_DESC are 4 bytes long that that would be needed.

Another slightly annoying feature is that all parts of my code create successfully flagging no errors and returning addresses where it should and hRESULT = 0 where it should?

If you're defining data layouts incorrectly it very likely just means that the called functions are still seeing values for things just not those you intended. There's a lot of BOOLs & enums with low values so a lot of the bytes in some structures will just have zeros in them.

[Richard Russell]

How can something "work fine" but have "alignment ... incorrect"?

Presumably it was a typo and what he meant to write was "correct".

The key things that you seem not to be taking into account are that his code works properly in 32-bits mode and that there are seemingly no differences in the size and alignment of the structures between 32-bits and 64-bits. If that is indeed the case, it makes it unlikely that the problem is in this part of the code at all.

The only alternative possibility that I can think of is that the code has always been wrong, but that somehow the mistake proved innocuous in the case of 32-bits operation but results in a fault in 64-bits operation. For example, perhaps the overall structure alignment is supposed to be 16-bytes but that it is only enforced in 64-bits mode; but I think the OP has explicitly eliminated that particular cause.

Given the above, the rest of your comments don't seem to be very relevant, and I worry that it could be a case of 'the blind leading the blind'.

[JeremyNicoll]

Can anyone shed any light?

Are there any API calls you could make which return examples of these structures ... which you could analyse to see how long they are & maybe (though it will be difficult if many fields only have a few ones & twos in them) where there's fields and where suspected padding?

[JeremyNicoll]

The key things that you seem not to be taking into account are that his code works properly in 32-bits mode and that there are seemingly no differences in the size and alignment of the structures between 32-bits and 64-bits. If that is indeed the case, it makes it unlikely that the problem is in this part of the code at all.

So why is/was he so sure that a DWORD was "missing" & that extra padding was needed? Did he subsequently remove it?

The only alternative possibility that I can think of is that the code has always been wrong, but that somehow the mistake proved innocuous in the case of 32-bits operation but results in a fault in 64-bits operation. For example, perhaps the overall structure alignment is supposed to be 16-bytes but that it is only enforced in 64-bits mode; but I think the OP has explicitly eliminated that particular cause.

Given the above, the rest of your comments don't seem to be very relevant

I think the stuff I quoted clearly showed that no AI-generated answer can be trusted - which is not a worthless discovery.

, and I worry that it could be a case of 'the blind leading the blind'.

I forgot (this time) to insert my "I'm guessing" caveat - sorry - which was in my prior post. When I posted a few days ago I thought I saw the usual red "queued for moderation" msg but now wonder if it was some sort of other error & the post wasn't queued at all.


I've been looking online for the DirectX 11 d3d11.h file to see if it contains any clues that might help .. but can't find it (except some links on possibly dubious websites). I don't want to download and then unpack/install a whole Windows SDK. I did also wonder if one installed the (free) VS Studio Community Edition & tried to compile sample C/C++ D3D code (surely there's some somewhere) whether there's compiler listing options which would show the padded/aligned structure data layouts it used.

[Richard Russell]

Are there any API calls you could make which return examples of these structures ... which you could analyse to see how long they are

If all an API call returns is a pointer to the structure, it's not possible to deduce from that how long it is. Anyway, we already know that the sizes of these structures are unchanged from what they were in 32-bits mode. To be different they would have to contain at least one pointer, handle or other size-t-sized member, and they don't. We don't need AI to tell us that!

[Richard Russell]

I think the stuff I quoted clearly showed that no AI-generated answer can be trusted - which is not a worthless discovery.

I rely heavily on AI now. It's not always right, but that's not so much a problem when you already know enough about a subject to judge the likely accuracy of its reply. Look at the way mathematicians are increasingly using AI to help with their research, sometimes the answers are nonsense but the smattering of insights they provide can be invaluable.

I did also wonder if one installed the (free) VS Studio Community Edition & tried to compile sample C/C++ D3D code (surely there's some somewhere) whether there's compiler listing options which would show the padded/aligned structure data layouts it used.

I commonly check the sizes of structures by compiling them. You don't need entire SDKs or IDEs for that, just the relevant header (.h) file which can usually be found at GitHub. Here's an extract from the output from just such a program of mine:

sizeof(SDL_version) = 3
sizeof(SDL_AudioCVT) = 84
sizeof(SDL_AudioSpec) = 24
sizeof(SDL_AudioFilter) = 4
sizeof(LUID) = 8
sizeof(LUID_AND_ATTRIBUTES) = 12
sizeof(TOKEN_PRIVILEGES) = 16
sizeof(jmp_buf) = 64
sizeof(WSADATA) = 400
sizeof(DXGI_SWAP_CHAIN_DESC) = 60

[Richard Russell]

Here's an extract from the output from just such a program of mine:

I added the two structures that the OP is most interested in to that program (these are 32-bits values, not 64):

sizeof(D3D11_DEPTH_STENCIL_DESC) = 52
sizeof(D3D11_DEPTH_STENCIL_VIEW_DESC) = 24

Note that they are both multiples of 4, so there does need to be enough padding to ensure that.