Jump to content
  • Advertisement

ajmiles

Member
  • Content Count

    431
  • Joined

  • Last visited

Community Reputation

3400 Excellent

About ajmiles

  • Rank
    Member

Personal Information

  • Role
    Programmer
  • Interests
    Programming

Social

  • Twitter
    @adamjmiles
  • Steam
    ajmiles

Recent Profile Visitors

7011 profile views
  1. Perhaps there's some quirk around zero descriptor heaps that we haven't tested. I'll try and find some time next week to see if I can reproduce any problems. Can you confirm what version of Windows you're using right now? Run 'winver' and type out the full build number.
  2. I'm obviously not familiar with all your code, but this looks a bit odd, no? UINT heap_sizes[] = { 250, 0, 20, 0 }; Each of those heap sizes seems to correspond to a descriptor type, and you're asking for zero Sampler descriptors and zero DSV descriptors in the heap?
  3. Are you able to provide a repro of some description?
  4. Have you tried this code on more than one IHV's GPU and do you have the driver fully up to date? What about WARP / Microsoft Basic Render Device?
  5. @AlanGameDev Ah ok, in that case the Optional Feature I was talking about won't apply, it's just a Windows 10 thing. I'm not sure what the 8.1 SDK tools are, but they're probably not relevant. I'll have a look at the compiled code for the shader you posted in full earlier, but I don't expect it to yield anything obvious. EDIT: Can't see anything amiss with the shader as posted. I think a runnable repro is probably the only way to go.
  6. @AlanGameDev I just ran that device creation code just fine here so I'm not sure why you'd get DXGI_UNSUPPORTED. Do you have Windows 10's Optional Feature "Graphics Tools" installed?
  7. @AlanGameDev Ah ok, I misunderstood that bit about DXUT, it's clearer now I've reread it. What's the smallest value of max/w that causes the problem? Wondering if we could perhaps take a look at the shader disassembly between the closest working and not-working versions of the shader. Also, have you tried running the workload on WARP / Software Render Device? If the shader has been compiled in such a way that it'll never terminate then I would expect WARP to hang in the same way as a hardware device - this would rule out a vendor-specific issue.
  8. @AlanGameDev Which version of the D3D compiler are you using? I'm worried by the fact you're still using DXUT might mean you're also using the DirectX SDK from June 2010 rather than the WIndows 10 SDK from 2018.
  9. I felt my ears burning... If you have a repro I'd be happy to take a look.
  10. That makes it sound like there isn't still a good reason that the semantics still exist. They're still required for binding the Input Layout to the Vertex Shader. A struct declared in a shader needs to markup the members of that struct such that the driver/hardware know which member corresponds to which element in the input layout. A VS_INPUT struct can declare its elements in any order and even omit elements that may be included in the input layout, the mapping from the Input Layout to the VS Input is handled by the input semantic names and without them some other system would need to be added to achieve this.
  11. Have you tried running it with the Software WARP renderer? What about another GPU or another machine? Are the graphics drivers up to date?
  12. To be honest, I'm not sure how you're getting red in your "working" case. PIX doesn't show any referenced textures for your pixel shader, yet the pixel shader does appear to be written as if it's expecting 6 textures to be bound. They should be showing up here in the PS group as a descriptor table / SRVs. I've had a look into why they aren't showing up, and I'm a little worried by how your root signature looks. For the root parameter describing the descriptor table, the "OffsetInDescriptorsFromTableStart" field is set to 2147483648, which is 0x80000000. I would have expected this value to be either 0 or D3D12_DESCRIPTOR_RANGE_OFFSET_APPEND, which is 0xFFFFFFFF. There's always the possibility that PIX is wrong, but could you check what you think you're setting this field to?
  13. Sharing a PIX capture with us would probably also solve the problem.
  14. Does that mean you still haven't figured out what's wrong?
  15. The Visual Studio Graphics Debugger (VSGD) should work fine for simple applications, but that particular feature is no longer under active development and is likely to become less useful to DX12 developers as time goes on. "PIX For Windows" is a separate standalone graphics profiler and debugger and is in constant development. I would recommend installing PIX For Windows and using this for any investigations you might want to do in the future.
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!