Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Mar 2005
Offline Last Active Today, 04:36 AM

Posts I've Made

In Topic: Compute shader values

17 August 2014 - 11:46 AM

Once you've written your computation results to a buffer (or texture) you can Map() the buffer/texture and read back the results.

Note that for some resource types (depending on the creation flags) you may first need to copy your results to a staging resource and then Map() this intermediate resource.


This link (even though for DX10) contains some pointers to related topics: http://msdn.microsoft.com/en-us/library/windows/desktop/bb205132(v=vs.85).aspx


One thing to keep in mind: If you read back the results in the same frame as the computation happens you will probably introduce stalls in your CPU-GPU communication which can lead to performance problems. So wait at least a frame before reading back data. Even better would be to issue a query after your Dispatch() call and then asynchronously ask DirectX if the query is finished so you know your computation you did before is finished as well.

In Topic: Vertex Shader responsabilities if I have Tessellation Shader

19 July 2014 - 05:41 AM

It helps to think of the shader pipeline as a set of refinement steps in my experience.


The earlier you can calculate something in the pipeline the cheaper it usually is (barring interpolator costs etc. so caveat empor).


If you have a calculation you can do in the vertex shader because it affects all triangle emitted by the tesselation the same then do it there instead of in the tesselation stage.

One example would be shader based skinning. Usually your vertices are affected by the bones and all tesselation generated triangles move the same based on the "basis" triangle coming from the vertex shader stage. This would speak for performing the skinning calculations in the vertex shader as it is called less often (and you benefit from the vertex reuse cache as well).


It always depends on what exactly you want to achieve. For example your vertex shader can transform all vertices to world space and then your tesselation stuff can do it's operation in world space. If on the other hand you have some calculation which needs to happen in object space (in the tesselation stage) you need to move the transform step further back.


The usual implementations I have seen have used world space for most operations after the vertex shader so it was safe to have TBN calculations etc. in the vertex shader stage. Often you can also find transformations to move your problem between the stages even if it doesn't look like that first.




In Topic: What's the next step after LZ77?

17 July 2014 - 05:56 AM

Like just said before: Take a look at LZ4 - it's used by Frostbite on PS4 and XBox One:





"LZ4 is a very fast lossless compression algorithm, providing compression speed at 400 MB/s per core, scalable with multi-cores CPU. It also features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems."

In Topic: Loading Screens

03 August 2010 - 08:16 AM

The simplest solution would be actually to load your assets piece for piece.

It could boil down to something like this:


So you would load the loading screen, show it and then start loading the assets.

You load a texture and update the loading screen, then you load another thing (e.g. a model) and update the screen again. Do this until everything you need is loaded.

If you look at the FPS while loading in many commercial games with Fraps for example you see that they fluctuate wildly.


In Topic: What are multiple Vertex Streams used for?

30 May 2010 - 10:09 PM

You can use the multiple stream feature for terrain rendering as well.

Your first stream has X,Y coordinates and contains all vertices necessary for a 2d grid of one terrain sector. In a second stream you have the actual height stored. This way you can save quite some graphics memory since the first stream is the same for every terrain tile.