Jump to content
  • Advertisement

Adam Miles

  • Content Count

  • Joined

  • Last visited

  • Days Won


Adam Miles last won the day on September 4

Adam Miles had the most liked content!

Community Reputation

3460 Excellent

About Adam Miles

  • Rank

Personal Information

  • Role
  • Interests


  • Twitter
  • Steam

Recent Profile Visitors

8643 profile views
  1. Adam Miles

    Strange Assembly Error

    Pretty sure this is nothing to do with Graphics / GPU Programming. Try https://www.gamedev.net/forums/forum/9-general-and-gameplay-programming/
  2. Adam Miles

    Drawcall isn't working out

    Problem #1: Your Vertex Shader calculates the y-coordinate for the two vertices as: 1) 1 + (0 / 300) = 1.0f (the top of the screen) 2) 1 + (200 / 300) = 1.666f (off the top of the screen) The y-coordinate in clip space is -1 at the bottom and 1 at the top, you probably want "1 - (pos / halfSize.y)" instead. Problem #2: You clear your render target to magenta and your lines are magenta coloured. Fix both problems and the line appears:
  3. Adam Miles

    Drawcall isn't working out

    When calling IASetVertexBuffers, you set the stride of your vertex to be 0 bytes. That means every vertex rendered will advance 0 bytes through the vertex buffer and therefore have identical position/colour/UV as every other vertex.
  4. Adam Miles

    Drawcall isn't working out

    Easiest way to figure it out would be to take a capture with RenderDoc, upload it and share that.
  5. What you're asking for is nigh on impossible. You may get closer by enabling IEEE strictness on your shaders and disabling any fast-math optimisations on your C++ compiler, but only certain floating point operations are guaranteed to give the same result across architectures (e.g. +, -, *, /). You can try enabling IEEE strictness using the /Gis compiler flag, but I don't think it'll get anything other than "close, but not quite". Try giving this blog post from Bruce Dawson a read: https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/
  6. You can't have a DepthStencilView with an ArraySize of 6 starting at any slice other than 0 since you only have 6 slices in your array to begin with. I assume you meant to set ArraySize to 1 in dsvDesc.
  7. Adam Miles

    DX12 Debug Interface memory leak?

    To quote my colleague @SoldierOfLight from DX12 Discord, "looks like the fix for that should be in the latest insider fast build, 18963"
  8. Adam Miles

    DXR Flickering Artifacts

    Your problem is this: And the fix is this: Since you currently only have one hit group, the last two geometries are indexing off the end of your shader binding table into unknown memory. Therefore it's not running your Closest Hit shader for the last two triangles and therefore the payload is coming back with the same color it was initialised with in the ray generation shader (Narrator: It wasn't initialised, hence the flickering).
  9. Adam Miles

    DXR Flickering Artifacts

    The artifacts themselves look more like an issue stemming from a missing barrier or synchronisation on the UAV you write to or how/when you copy it to the swap chain (rather than the TLAS/BLAS builds). If you want to check something into your branch again I can take a look in the morning.
  10. Adam Miles

    DXR and Device Hung Error

    I checked your latest changes and the one thing you didn't do was make the TLAS a 'Root' Shader Resource View. I'm just about to jump on a plane, so I've attached a modified RayTracingPass.cpp you can diff with yours and see the 4 changes I made. It should be possible to have a TLAS be inside a Descriptor Table, but I would need to debug it further when I get home to figure out why a RootSRV works but an SRV in a Descriptor Table doesn't. RayTracingPass.cpp
  11. Adam Miles

    DXR and Device Hung Error

    @_void_ Using the project you linked in a PM I can see the GPU hang you report. When trying to view the Acceleration Structure in PIX it was clear you'd created the TLAS SRV as a StructuredBuffer which is not what you're supposed to do. This StructuredBuffer was created with NumElements = 1, StructureByteStride = which isn't going to work. According to the DXR spec you're supposed to create TLAS SRVs as 'Raw' SRVs. I've never actually tried creating a Raw SRV of a TLAS and then putting it inside the shader binding table / ray gen shader's local root signature. When I tried it, the hang continued... As a 'fix' (and this is what I do normally anyway), I put the TLAS as a Root SRV in the Global Root Signature instead and this works.
  12. Adam Miles

    DXR and Device Hung Error

    You're going to need to simplify what you've got as much as possible (or post something someone can run). Try calling TraceRay with the "SKIP_CLOSEST_HIT_SHADER" flag to eliminate that as a cause of the hang. Try setting the miss shader Shader Identifier to null so it never gets executed. Remove all code from Closest Hit / Miss Shader etc.
  13. Adam Miles

    DXR and Device Hung Error

    The list of ways to hang the GPU when using DXR is as long as my arm. Have you considered: Setting the recursion level too low when creating your RTPSO? Setting the payload size too low when creating your RTPSO? Setting the attribute size too low when creating your RTPSO? Forgetting to bind the Top Level Acceleration Structure? Forgetting to initialise the shader identifier for your hit group? Forgetting to initialise the shader identifier for your miss shader? Using unbound resources in the global root signature? Using unbound resources in the local root signature? Using a TLAS or BLAS before it has completed building?
  14. This doesn't have anything to do with Graphics or GPU programming.
  15. Adam Miles

    Wrong HLSL buffer width

    As your code is currently written in Github you aren't explicitly declaring which 'register' each constant buffer should be assigned (you were in the original code snippet you posted). If you declare two constant buffers and elect not to use one of them and *haven't* explicitly declared which register slot each one belongs to then the compiler will assign the *used* constant buffers an index in ascending order as they appear in the code. You have MatrixBuffer which is unused in the VS and ScreenSizeBuffer which is used. Therefore ScreenSizeBuffer is going to be VS Constant Buffer 0 and there will be no VS Constant Buffer 1. The corresponding C++ code is setting the ScreenSizeBuffer to be VS cb1 not cb0, so I don't see how it can be working in its current state. unsigned int bufferNumber{ 1 }; deviceContext->VSSetConstantBuffers(bufferNumber, 1, &m_screenSizeBuffer); Is what we're seeing in Github the 'working' code or the 'broken' code?
  • Advertisement

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!