Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 03 Jan 2000
Offline Last Active Dec 12 2015 12:57 AM

Posts I've Made

In Topic: [D3D12] Use compute shader to write to swap chain backbuffer?

07 December 2015 - 09:28 PM

This article is from a year ago but it matches all my past observations and things I've been told: https://software.intel.com/en-us/blogs/2014/07/15/an-investigation-of-fast-real-time-gpu-based-image-blur-algorithms


The constant time compute shader blur is over twice as slow in a small kernel and still very slow until the kernel size is huge. Also consider that when you're writing to a UAV that represents a render target, you're either doing non-coherent writes because the destination texture is swizzled, or you're writing to linear memory in which case you probably need to re-swizzle it later to be useful.


Things could certainly be different now which would be great but my general rule has always been that unless I'm doing a whole lot of work with shared memory, the pixel shader's gonna be faster.


That's an apples to horseshoes comparison, though, unless I'm misreading - they're comparing the timings of two different techniques (both of which are running in compute from the sound of it) and comparing the timings of each. Yeah, the constant-time shader is slower, but it's solving a different problem. You wouldn't use that for a small kernel because of all the extra overhead involved.


There are other ways to make compute blur faster (like using groupshared memory which doesn't seem to be mentioned in that article, which can drastically reduce your memory accesses), but it doesn't say anything about comparing a 1:1 pixel shader:compute shader version of the same operations.


Also, how you decide to break your compute shader up can make a difference with performance (including cache coherency) - if your compute shader's thread groups load/store things in BLOCKS as opposed to in scanlines, you're likely to get better coherency group to group because you'll be writing into places that are related in memory, as I understand it.


I don't think that compute postprocessing is NECESSARILY slower than a pixel shader, but it does likely depend at least partly on how you've got it set up.

In Topic: [D3D12] Use compute shader to write to swap chain backbuffer?

06 December 2015 - 08:00 PM

Thanks for the info. Yeah, that kinda sucks (it's a sad regression from D3D11), but I've at least worked around it in the short term by having a simple copy postprocess (via a pixel shader) that gets things onto the backbuffer and still allows all of my postproc to run as compute (as you suggested).


Thanks again!


EDIT: I suppose I could use CopyTextureRegion instead and use that fancy DMA hardware that may or may exist, if I'm already using a backbuffer-format-compatible texture by the time I'm at the end of the postproc chain. But a pixel shader works well enough for now.

In Topic: methods for drawing rain

30 March 2014 - 11:28 PM

For what it's worth, Infamous: Second Son used the particle system to render up to 25,000 raindrops near your field of view, and uses a rain "shadow map" to determine where the particles should spawn (and end). That includes, I believe, the particles for the splashes on objects (which are randomly scattered throughout the view and spawned wherever the rain shadow map's depth says they should be for that point). The splashes, I should note, are not tied to where the actual raindrops intersect the ground - it turns out that totally doesn't matter.


Using a nice GPU-driven particle system on relatively modern hardware, you should be able to handle particle rain like that fairly efficiently.

In Topic: What to write with now?

26 February 2013 - 12:58 PM

You need to sign up for a creator's club account to be able to submit to Xbox Live Indie Games. It's $99/year, but it's what allows you to develop and release on the Xbox.


People are still releasing XBLIGs, so it's definitely not disabled :)

In Topic: What to write with now?

26 February 2013 - 12:33 PM

To expand on Jutaris' comments, XNA is not DEAD. It's just not being developed anymore.


However, everything that XNA has done in the past (PC/Xbox/Windows Phone 7 games), you can STILL DO. You can still get XNA, you can still write games with it, you can still release those games on any of the ever-supported platforms.


All "XNA is dead" really means, as it's stated is that Microsoft is no longer planning new revisions of it, so we're stuck with XNA 4.0 unless they change their minds.