Jump to content

  • Log In with Google      Sign In   
  • Create Account

Funkymunky

Member Since 28 Jul 1999
Offline Last Active Sep 27 2016 04:48 PM

#5291618 [D3D12] MRT only updates the first texture (kinda)?

Posted by on 14 May 2016 - 03:10 PM

Yes!  Which led me to realize that I was creating the Pipeline State with 1 Render Target.  That is some sharp remote debugging sir.  Thank you!




#5286223 [D3D12] Resource Barriers in Multiple Command Lists

Posted by on 10 April 2016 - 08:16 PM

How about if they're in different queues?

 

I have Command List 'A' and Command List 'B'.  I put 100 commands in 'A' and a Resource Barrier from pixel shader resource to render target.  'B' is a command list for a Compute Queue, and only has a Resource Barrier from render target to shader resource before the Compute Dispatch.

 

How do I now assure that 'A' transitions the resource before 'B'?




#5285419 [D3D12] Resource Barriers in Multiple Command Lists

Posted by on 06 April 2016 - 06:44 AM

Let's say I'm going to submit Command List 'A' and Command List 'B'.  I'm guaranteed to submit 'A' before 'B'.  I put 100 commands in 'A', and then a Resource Barrier to transition a resource from a pixel shader resource to a render target.  The only thing I put in 'B' is a Resource Barrier to transition that same resource from a render target to a pixel shader resource.

 

Do I have any assurance that 'A' will transition the resource before 'B' does?




#5284313 Debugging this Vulkan crash

Posted by on 30 March 2016 - 01:06 PM

After finally circling back to this, I discovered that the problem was that when creating the VkInstance, I was only using the extension "VK_KHR_SURFACE_EXTENSION_NAME."  As I am doing this on Windows, I needed "VK_KHR_WIN32_SURFACE_EXTENSION_NAME."




#5279757 [D3D12] What is the benefit of descriptor table ranges?

Posted by on 05 March 2016 - 07:21 PM

In regard to root signatures for descriptor heaps, what is the point of having a descriptor table with a range of multiple descriptors?  Is it just to minimize the number of calls to SetGraphicsRootDescriptorTable/SetComputeRootDescriptorTable?  That seems like a small victory for the price of ensuring that your descriptors are contiguous within the heap.  Sharing resources between shaders then requires more complicated root signature creation.  And changing a resource at runtime (like switching to a different texture) requires either: a stall in the rendering so the descriptor can be reused, copying a bunch of descriptors to create another contiguous section, or creating a new root signature on the fly to accommodate the new breakdown of resource descriptors.

 

Is it really that big of a win over calling SetGraphicsRootDescriptorTable for each individual resource, and defining the root signature along the same lines?




#5278352 Debugging this Vulkan crash

Posted by on 26 February 2016 - 03:19 PM

So I've slowly been throwing together a vulkan example so that I can get an understanding of how everything works.  Right now I get an access violation, and what I'm really wondering is if anyone has any suggestions on how to debug it.

 

I've read through SaschaWillems' code, and I thought I'd done everything he did (I've also compared it against the demo code that comes with the Lunar SDK, and everything seems in order).  But I get a crash when I call vkQueuePresentKHR, with the error being "Access violation reading location 0xBAADF00D".  So that's an interesting hex value, and googling it reveals that it's generally "used by Microsoft's LocalAlloc to indicate uninitialized allocated heap memory".  In my debugger (Visual Studio 2015), it pops open a window that says "No symbols loaded" and is looking for VkLayer_swapchain.dll.

 

 If I disable that call to vkQueuePresentKHR, the program will run (and obviously not display anything), but will crash on VkDestroySurfaceKHR, with an Access Violation at 0xBAADF025.  The combination of these crashes makes it seem like my surface is uninitialized, but I've walked through that code several times and everything seems in order.  I have checks for VK_SUCCESS on every vulkan function and nothing is failing or indicating an error.

 

So I'm not really looking to dump my Vulkan test code here, as it's a lot, and I'm not sure exactly where the issue is yet.  Really what I'm wondering is if anyone has any tips on debugging this problem.  Maybe a better way to look into VkLayer_swapchain.dll?




#5275130 Geometry Clipmaps - sample heightmap?

Posted by on 10 February 2016 - 08:15 AM

For my implementation I have a separate texture store that I use as source data for updating the clipmap with.  The clipmap is a texture array with N levels, and the texture store is a 3x3 grid of textures (with N levels of grids).  When I'm updating the clipmap, I check if the necessary texture store entry is present before doing the update.  If it's not, I drop that clipmap level until I can render.  I also pre-emptively load the texture store based on the velocity of the camera.

 

I have a separate thread running that checks for texture requests and loads the data from the disk or generates it with procedural noise, and flags the entry as complete when it finishes a texture.




#5267963 [D3D12] CopyTextureRegion with a fence?

Posted by on 25 December 2015 - 11:44 PM

Well it turns out that I had a bug in how I updated the position that the stream used to calculate which texture index to access.  I flushed it out in the process of walking through the code to examine each of your questions.  So thanks!




#5255386 Shadow Mapping, why don't you move the shadow View matrix?

Posted by on 03 October 2015 - 12:58 PM

I'm digging into shadow mapping again.  The standard procedure I've followed is to:

 

  • Extract the 8 frustum corners of the view frustum
  • Get the centroid, move away from this in the direction of the light by the far clipping distance
  • Create a LookAt matrix using this distance and the centroid as the from/to
  • Transform the frustum corners by this Shadow View matrix i've created
  • Get the min and max x/y/z values from the transformed frustum corners to generate an off-center Ortho Projection Matrix
  • Use these Shadow Projection and Shadow View matrices for rendering to the shadow buffer.

 

I've always gotten strange clipping issues in the shadows when doing this method, and I've realized (after rendering the frustums in question) that it's because the Shadow View Matrix is translated substantially farther away from the camera frustum than the Ortho bounds can tolerate for the near/far distances.

 

Why isn't there generally a step in there to translate the Shadow View Matrix such that it aligns with the calculated Ortho near plane?  Am I missing something?

 

 

EDIT:  Well, duh, because the near/far values calculated are already in terms of the Shadow View Matrix.




#5251978 when will we see DXGI_FORMAT_R64G64B64A64_FLOAT?

Posted by on 12 September 2015 - 10:48 PM

 

Why haven't GPUs made that full leap to 64 bit as CPUs have?

 

Because CPUs made the leap to 64 bit to support a greater memory address range (ie, more RAM).  32bit, in reference to GPUs, is almost exclusively talking about color depth (ie, the number of bits per pixel).




#5251004 Spherical Harmonics Cubemap

Posted by on 07 September 2015 - 10:10 AM

MJP, you are the man.  I had to change CosineA2 to be Pi * 0.25f, which corresponds with the 1, 2/3, 1/4 bands.  But it works!  I am digesting the paper you linked me to, and I still have to adjust for the high dynamic range of the cubemaps I'm testing with, as a lot of the stuff ends up over-exposed.  But it's definitely looking much better:

 

adoowGt.jpg

 

Thanks for your help!




#5245059 DirectX12 Question that is bothering me.

Posted by on 08 August 2015 - 01:00 AM

Yes, that is correct.  You would need to wait for a fence before mapping the resource if it is being used in a command list or you'll get "undefined behavior" (potentially a driver crash).




#5234552 Engine design, global interfaces

Posted by on 12 June 2015 - 08:14 PM

Funkymunky, are you sure a couple of instances of your Singleton are enough?

 

 

Definitely, I made a SingletonManager class to make sure I kept track of them all properly.




#5234196 Engine design, global interfaces

Posted by on 10 June 2015 - 10:32 PM

Guys I've been thinking about it and I'm starting to lean toward using a couple of Singletons.




#5233586 Engine design, global interfaces

Posted by on 08 June 2015 - 12:43 PM

Perhaps L.Spiro should put an "about me" on HIS webpage, as it is not the first time I've seen this mistake.

 

http://l-spiro.deviantart.com/art/Japanese-Model-WIP-1-82010882

 

 

(!)  I'm so embarrassed.

 

(Also guys can you stop arguing about singletons, they're pretty clearly just a personal style choice.  I know people have strong feelings about them, but you're just de-railing the conversation at this point).






PARTNERS