• Advertisement
Sign in to follow this  

Two Questions about DirectX 11 (XMVECTOR & Creating Input Layouts)

This topic is 1229 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

Hi every one;

  1. Considering XNA Math library, the API functions don’t use pointers with XMVECTOR. Why?
  2. ID3D11Device:: CreatInputLayout wants to check our vertex shader for compatibility with the defined vertex layout, so it is necessary to have a vertex shader at mesh creation time. While one may use the layout with different shaders, what is the necessity of this rule and is there any way to get rid of that?

Thank you.

Share this post


Link to post
Share on other sites
Advertisement

Thank you so much.

About 1st question, Yes, I mean the reason for passing arguments by value and reference instead of using pointers.

Share this post


Link to post
Share on other sites

Regarding your 1st Question:

from the DirextXMath.h:

// Fix-up for (1st-3rd) XMVECTOR parameters that are pass-in-register for x86, ARM, and Xbox 360; by reference otherwise
#if ( defined(_M_IX86) || defined(_M_ARM) || defined(_XM_VMX128_INTRINSICS_) ) && !defined(_XM_NO_INTRINSICS_)
typedef const XMVECTOR FXMVECTOR;
#else
typedef const XMVECTOR& FXMVECTOR;
#endif

So in most cases FXMVECTOR is a reference to the XMVECTOR, and all funcions I know of are taking FXMVECTORs as arguments.

I do not want to start a discussion over the difference on pointers and references, but since we are talking about function arguments here, think of a reference as a pointer that can't be assigned NULL, which offers some nice advantages over pointers.

 

Edit: Too slow :O

Edited by Wh0p

Share this post


Link to post
Share on other sites


ID3D11Device:: CreatInputLayout wants to check our vertex shader for compatibility with the defined vertex layout, so it is necessary to have a vertex shader at mesh creation time. While one may use the layout with different shaders, what is the necessity of this rule and is there any way to get rid of that?

 

You can just create a dummy-shader in code and use that to create the input-layout. The shader just needs to look like this:

struct VS_INPUT
{
    Arg1 : SV_POSITION;
    // and so on
};

void VS_MAIN(VS_INPUT In)
{
}

You should easily be able to create such a thing in code from your expected input signature.

Share this post


Link to post
Share on other sites


think of a reference as a pointer that can't be assigned NULL

Ok, it makes sense. Since size of XMVECTOR is small enough, we can work with itself rather than its address. But I think we can’t say the same for any type of data. Can we?

Share this post


Link to post
Share on other sites

 

think of a reference as a pointer that can't be assigned NULL

Ok, it makes sense. Since size of XMVECTOR is small enough, we can work with itself rather than its address. But I think we can’t say the same for any type of data. Can we?

 

You’ve completely misunderstood.
A reference is a pointer masked behind syntactical sugar.  A reference to any type of data is “small enough”—it’s the same size as a pointer to any type of object.

 

Pass-by-reference is not pass-by-value.  If you were creating a copy of the object (pass-by-value), then it would be valid to consider the size of the object or its complexity in a copy operation.

 

And then you also completely missed 2 other points:

 

If you pass pointer you'll have to load value from memory by pointer, however if you pass your vector by value there's a good chance it will be passed in register and you won't need to access memory, which is way more faster and efficient.

 

Yes, this is relevent part: they wrote the API in such a way as to maximize the chance of the argument being passed in a register. On PC it directly ties in with the new _vectorcall calling convention.

 

Which means that in this specific case the fundamental type behind XMVECTOR (__m128) is a type that specifically matches a register type on SSE and above.

It is a special case when considering to pass by value because if it gets copied to a register, it will go to different registers.  If it followed the general rule used when deciding to pass by value, it would often be considered too large as a type, and passing by reference would be preferred.

 

 

L. Spiro

Share this post


Link to post
Share on other sites


You’ve completely misunderstood.
A reference is a pointer masked behind syntactical sugar. A reference to any type of data is “small enough”—it’s the same size as a pointer to any type of object.

It's a shame! I didn't know that. I had better google it. Thank you very much.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement