Jump to content
  • Advertisement

SoldierOfLight

Member
  • Content count

    307
  • Joined

  • Last visited

Community Reputation

2263 Excellent

1 Follower

About SoldierOfLight

  • Rank
    Member

Personal Information

  • Role
    Programmer
  • Interests
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Depends on the sizes we're talking about here. Generally, using Map(WRITE_DISCARD) on a CB results in re-allocating the entire buffer. If you're talking about a few bytes per texture, then it's probably more efficient to cram them all together, as individual CBs would waste a lot of memory in padding. If you're talking about a few hundred bytes per texture, it probably makes more sense to only re-allocate/bind the one that's relevant at the moment. The actual hardware implications of "binding" CBs and textures vary across different hardware, even on the same vendor, but generally binding a CB is very cheap, while binding textures is less cheap. If you're interested in not needing to change texture bindings as often, you can take a look at DX12 with its bindless (read: bind fewer times, not never) options. But I'd recommend profiling before deciding that changing your bindings is the bottleneck.
  2. You're probably looking for ID3D11Fence. Treat your D3D11 device as if it was another D3D12 command queue.
  3. SoldierOfLight

    DirectInput GUID compare

    A GUID is 128 bits. A DWORD is 32 bits. You can't assign a GUID to a DWORD.
  4. Some drivers are mature enough to claim support for SM6 for all applications, but other drivers are only mature enough for developers to test SM6 on them. For these less mature drivers, the app needs to explicitly opt in to experimental mode, and must be running on a machine with Developer Mode enabled. If you query for SM6 support, the answer you get may change based on whether or not you've enabled experimental SM6 support.
  5. Ah, now I understand what you're looking for, you want to avoid stretching. You're looking for DXGI_MODE_SCALING, but note that there's only STRETCH and CENTERED. Fullscreen exclusive doesn't give you the option for aspect ratio preserving stretch. Sounds like you want a borderless fullscreen window, using DXGI flip model (FLIP_DISCARD instead of DISCARD), using DXGI_SCALING_ASPECT_RATIO_STRETCH. That's the only way I know of to get an aspect ratio preserve.
  6. Pretty sure your problem is that you're missing the DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH flag. Not sure what that looks like in SharpDX though.
  7. SoldierOfLight

    Failing to create shader - help

    Shader model 5.1 isn't supported by DX11 at all, only DX12. There is no FL11.3, and successfully querying the ID3D11Device3 interface indicates that your OS has "DX11.3" but you don't actually need to query that interface to use those features - unless they're only available on that interface.
  8. SoldierOfLight

    dx11 api dx12 implementation

    Pretty sure @ZachBethel is right: https://msdn.microsoft.com/en-us/library/windows/desktop/dn913195(v=vs.85).aspx
  9. The video memory manager I mentioned lives in DxgMms1.sys or DxgMms2.sys. It's responsible for allocating and managing memory, yes. I doubt that the 4GB limit is well-documented anywhere, considering that up until recently it wasn't a limitation that anybody could really run into.
  10. I believe that the graphics memory manager currently has a limit on any individual allocation being less than (4GB - 64KB), regardless of whether it's coming from system memory or video memory. Try using multiple heaps and mapping them into a reserved resource to get something larger than 4GB.
  11. SoldierOfLight

    VSSetConstantBuffers1 Problems

    That's correct, you need to use 256-byte offsets, which is 16 "constants" where each constant is 4 floats (16 bytes).
  12. That'd be undefined behavior. It might work on some hardware, it might not on others. The view dimension declared in the shader and descriptor must match.
  13. You should be able to see in the stack which component is doing the divide-by-zero. That should be your starting point for whose fault it is. If it's d3d9.dll, probably Microsoft's fault. If it's the NVIDIA or Intel driver, then there's the blame.
  14. Yes, you are. Begin and End are used for queries, not frame delimiters like D3D9. You can have any number of queries per frame, including zero.
  15. This is a known issue. Turns out that the C++ function implementations don't match the C function definitions, specifically when returning structures larger than one pointer. The workaround is to cast the functions to what their implementation really looks like before calling them. Example with ID3D12DescriptorHeap::GetDesc: ((void (__stdcall*)(ID3D12DescriptorHeap*, D3D12_DESCRIPTOR_HEAP_DESC*)) mDescriptorHeap->lpVtbl->GetDesc)(mDescriptorHeap, &debugdescHeap); Basically, the way MSVC implements __stdcall when returning large structs is to hoist it to an out parameter for C++, but I'm pretty sure that the C compiler chooses a different calling convention entirely. My suggestion: don't use C.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!