Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 18 May 2011
Offline Last Active Yesterday, 11:57 PM

Topics I've Started

DX11 Multithreaded Resource Creation Question

08 July 2014 - 01:45 PM

This page says that coarse synchronization is used to prevent concurrent thread device access.




Can I design a multithreaded resource loader with only multithreading in mind and expect that the cards/drivers that don't support it will serialize the resource creation? I can't be sure, but it seems like I have heard stories of this causing crashes on drivers without support for multithreaded resource creation. 


Can anyone confirm this? I don't have a system that I can try it out on!

Cascaded Shadow Maps Optimization Concept?

30 May 2014 - 03:29 PM

I just had a random thought the other day that sounds feasible, but I wonder if any of you guys can poke a hole in the concept.


The depth renders for cascaded shadow maps are orthographic, which means that there isn't any perspective foreshortening on the model renders. Every object with the same model/rotation/scale should have the same relative depth extents regardless of where they are on the shadow map.


I'm thinking it might be possible to render the model depth once to a render target texture, and then for every instance of that model on the shadow cascade you just draw quads and read the depths from the depth-texture that was rendered up front. You would also have to offset the the depths read in from the texture by the instance's distance from the orthographic camera. Then you would just specify the depth output in the pixel shader to allow for depth-testing like normal.


Depth rendering is pretty fast so this might be counterproductive because of the texture reading. You would probably have to atlas several model depth renders onto the same render target to minimize the number of binds/state-changes.


Can anyone see a flaw with the idea, or should I try out an implementation of it and tell you all how it goes?

Gamma Correction Issues

15 January 2014 - 04:59 PM

I'm trying to get gamma correction to work in my DX11 tile deferred renderer, but something in my pipeline must be doing something that I don't realize.


When I manually do gamma correction with pow(color, 2.2) and pow(finalColor, 1.0/2.2) it looks great! When I use the sRGB formats it appears way too bright.


My pipeline is as follows.


1. Create diffuse G-Buffer by reading from sRGB textures and writing to a sRGB render target. This is a pass-through.

2. Perform lighting in compute shader. Read from the sRGB diffuse G-buffer and compute lighting. Write the result to a DXGI_FORMAT_R16G16B16A16_FLOAT. I can't use an sRGB write format here because I have to write the result into a UAV.

3. Run post-processing. Read from the DXGI_FORMAT_R16G16B16A16_FLOAT and write down to the sRGB render target back buffer to be presented to the screen. I've disabled post-processing steps for the moment so this is just a pass-through.

4. Present.


What am I missing? >_>


Also, thanks!

Texture Compression Questions

02 December 2013 - 11:08 AM

There's a suprising lack of documentation on loading DXT compressed data into DX11. Here are a few questions:


1. Is creating a compressed texture resource as simple as passing in the BC compressed data like normal texture data, but with the DXGI_FORMAT_BC--- flags as the format?


2. How do I create mip maps of BC compressed data? I assume I should create mip maps with the uncompressed textures, and then compress them afterwards. Which leads me to..


3. How do I compute mip map offsets for compressed textures, so I can create/load them in properly? I want to compress a 2D texture array and generate mip maps before game start, but I'm not quite sure how to load them all up on resource creation.


4. Do BC formats need to be sampled in some special way, or does DX11 take care of it?

GPU to CPU stalling questions in DX11.

17 November 2013 - 08:34 PM

When it comes to GPU->CPU read back in DX11, what is the main concern with stalling? If work gets finished and the results are copied over to a staging buffer that you read from, what is the main cause of stalling aside from the transfer latency?


I want to generate 2D/3D noise on the GPU and copy it back to the CPU for usage in the middle of a game loop, but I'm not sure what measures I should be taking to reduce stalling. Do I just have to wait some amount of time until I'm sure the work is done? Is there a callback function or some other means of telling that the data is ready to be read?