Jump to content

  • Log In with Google      Sign In   
  • Create Account

Jason Z

Member Since 04 Feb 2004
Offline Last Active May 14 2016 05:17 AM

#5219736 Particle Z Fighting

Posted by Jason Z on 27 March 2015 - 05:13 PM


Hi MJP, I'm actually using a very similar technique to the one in your book. Do you know of an efficient way to sort all those particles? I might be able to use a different render mode than standard alpha blending as C0lumbo suggested, these particles are representational more than realistic.

If you will be using append / consume buffers, then it is probably not going to be very easy to keep a maintained sorted list.  You would be better off with a structured buffer that you maintained sorted order in, or using a round robin approach on the structured buffer to let you keep the particles in roughly correct order.




#5218077 SetTexture question

Posted by Jason Z on 21 March 2015 - 10:20 AM

 

You can avoid redundant calls in your code, in any case.

if( texPtr != lastSetTexPtr ) // lastSetTexPtr is a static or class variable initialized to nullptr
{
   Device->SetTexture( texPtr );
   lastSetTexPtr = texPtr;
   // or even Device->SetTexture( (lastSetTexPtr = texPtr) );
}

 

You can also have a generic way to handle different types of states: Pipeline State Monitoring

 

Also, this is the type of thing that is completely trivial to test out on your own - give it a try and see what type of results you can get.  If you manage to identify a measureable difference, then that would make a much better discussion here than simply asking which one is faster.

 

EDIT: With that said, I would guess that they are equally fast since you are only setting a pointer in either case...




#5218075 Compute Shader not running

Posted by Jason Z on 21 March 2015 - 10:16 AM

What feature level does your card support?  For some reason, I seem to remember that series of graphics cards only supporting a subset of the complete D3D11 compute shader features.  What is the response when you query for support of compute shaders like this:

    D3D11_FEATURE_DATA_D3D10_X_HARDWARE_OPTIONS Options;
    m_pDevice->CheckFeatureSupport(D3D11_FEATURE_D3D10_X_HARDWARE_OPTIONS, &Options, sizeof(Options));
	if ( Options.ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x )
		Log::Get().Write( L"Device supports compute shaders plus raw and structured buffers via shader 4.x" );





#5217978 Compute Shader not running

Posted by Jason Z on 20 March 2015 - 06:22 PM

Have you tried to run your original code on the reference device?  That would eliminate the driver from the equation.  Also, keep in mind that just because it runs on another computer doesn't put you in the clear.  It could be that the other computer has a more lenient driver than it should be.  Many, many thing can affect the system's stability including what other processes are running, how many processors you have, which GPU, and so on.  There could still be an issue in your code, but if you can verify with the reference device it is a good start.

 

Do you happen to do any multithreading in your code?




#5216683 Visual studio 2013 and DirectX.

Posted by Jason Z on 15 March 2015 - 01:06 PM

Most of the removed functionality can be found in other open libraries, such as DirectXTK though.




#5215123 Memory leaks when Windows shuts down the display

Posted by Jason Z on 07 March 2015 - 06:59 AM

You shouldn't be creating new buffers every frame!  I know you are hesitant to move away from that solution, but it is quite simple to use UpdateSubresource and achieve the same effect.  If nothing else, it is worth trying so that you can see if this issue also affects your application when you aren't creating buffers every frame.

 

I have seen something similar to this before using the Memory Diagnostic feature of VS2015.  Every time you create a resource, your process's private bytes will be increased, and it doesn't immediately go back down right afterwards.  This is probably due to the fact that the runtime/driver doesn't immediately release the buffer memory, even though from the application side it is released.  I haven't confirmed this suspicion officially yet, but it would makes sense in your case too.

 

Are you getting any diagnostic messages at application exit time?  If you are leaking resources, you will get a live device object report in the output window.  As long as you don't get that message, then your app is not the source of the additional memory.




#5214620 Concept for an input library - thoughts?

Posted by Jason Z on 04 March 2015 - 08:41 PM


You're right. I do touch on that issue here, but since it's not a performance critical area, another solution is not making them actual enums, but lightweight classes (so you can support other things beside just keys), and overload the | operator.

An enum class would work for that, right?




#5214606 NVIDIA NSight vs Visual Studio 2013 Graphics Debugger?

Posted by Jason Z on 04 March 2015 - 07:48 PM

Why don't you just give it a try?  Even if we tell you it is faster / better, wouldn't you want to try it out for yourself???




#5211773 Converting between coordinate systems

Posted by Jason Z on 19 February 2015 - 05:08 PM

 

Hummm... turns out the documentation I had was wrong, and both coordinate systems were already left-handed, with same axes and everything. My problems was with the aspect ratio. If you ever do viewPort.Width/viewPort.Height to get the aspect ratio, you're doing it wrong! Int/Int gives an int.

Better to do:

float(viewPort.Width)/float(viewPort.Height)

 

Even better is to use C++ style casts:

static_cast<float>(viewport.Width) / static_cast<float>(viewport.Height)



#5211772 Graphics Programming book?

Posted by Jason Z on 19 February 2015 - 05:05 PM

I won't give my opinion (since it is obviously biased toward Practical Rendering & Computation), but if you are interested in checking out the source code that goes along with it, then go here!




#5211077 compute shader resource slot allocation across multiple files

Posted by Jason Z on 16 February 2015 - 05:50 PM

The slots that you consume in a shader are independent of one another.  What matters more is what you have bound to the pipeline at those slots.  So you can change the ordering from one shader to the next, but then you have to rebind the SRVs to match the desired inputs.

 

In general, if you don't have to change the location it is better to make as few changes between dispatch calls as possible.




#5210689 Weird behavior when getting data from structured buffer

Posted by Jason Z on 14 February 2015 - 10:53 AM

Just as a first hunch, have you initialized your entire buffer with a known value at creation time?  Sometimes if your structure count gets out of whack you can easily index uninitialized parts of the buffer...




#5207952 Sending World, View and Projection Matrices To D3D9 Vertex Shader

Posted by Jason Z on 31 January 2015 - 04:14 PM


If you're looking for the function call SetMatrixWithEitherD3D9OrD3D11(...) there ain't no such thing. They are different APIs and they have different methods to accomplish things.

If you choose D3D9, use D3D9 methods. If you choose D3D11, use D3D11 methods.

This, in particular, is the answer to your question.  The point is that you would need to build a small wrapper layer to abstract this particular feature away in order to communize the two APIs. 




#5207887 Ways to render a massive amount of sprites.

Posted by Jason Z on 31 January 2015 - 12:09 PM

Another potential method is to store the sprite info in a buffer resources, and then use an SRV in the vertex shader to grab the data out of it.  The interesting thing that you can do, is to create the vertices completely in the vertex shader, with no vertex buffers required at all!  The general idea is to use your draw call to specify how many vertices are generated, and then use the SV_VertexID semantic value to grab the appropriate data from the SRV.  You would use 4 vertex shader invocations for each of the quads, and the method is relatively efficient.  If you check out the particle storm demo from Hieroglyph 3, there is an example of creating vertices without vertex buffers (although I expand the vertices in the GS as mentioned above).

 

Regarding the use of instancing, you are probably not going to see an improvement for the use of 4 vertices as your instanced geometry.  In general, unless you are using geometry with 100 or more vertices you won't see much improvement (at least that is general advice, but your particular situation may or may not reflect the general rule of thumb...).




#5207883 Sending World, View and Projection Matrices To D3D9 Vertex Shader

Posted by Jason Z on 31 January 2015 - 11:58 AM

There is no such thing as a constant buffer in D3D9 - instead you set individual registers.  Have you taken a look at some starter D3D9 tutorials yet?






PARTNERS