Issue with text output: not shown on screen

Nov 6, 2011 at 3:37 PM

I'm working with ImageProcessor demo, but the issue described below is the same for all demos.

There is no text message shown on screen. Sometimes when I use the debugger to single-step the code, I see the output in front of the image but it is gone at some later point. I was not able to find out what makes the text appears and what make it disapears. It is like the images are drawn above the text output.

Using the reference device doesn't change anything. No text is seen.

Coordinator
Nov 7, 2011 at 5:57 AM

Would it be possible for you to take a PIX frame capture?  Then I could look through the API calls and see what else is going on.  I just double checked, and it seems to be working ok on my end, so I suspect this may still have something to do with drivers - although if it really works on the reference device, then it should be independent of the driver.

Nov 7, 2011 at 6:28 AM

What is a PIX frame capture ?

 

Coordinator
Nov 7, 2011 at 6:34 PM

PIX is a tool that comes with the DirectX SDK that can capture information about how an application is using Direct3D.  The way you would use it for Hieroglyph 3 is as follows:

  1. Build the executable in question, and copy the resulting .exe file to the Hieroglyph3/Applications/Bin folder.
  2. Start PIX (you can find it in the SDK install directory, under DirectX Utilities.
  3. Click the new document icon to create a new configuration (looks like a blank paper).
  4. At the top of the dialog, select the desired .exe file from the bin folder.
  5. Choose the second option below, called "A single-frame capture whenever F12 is pressed"
  6. Start the experiment, and then press F12 anytime something unexpected is happening.
  7. Press escape to end the application, and then save the resulting PIXRun file and send it to me!

You can also use this to inspect which API calls are made and in what order, plus examining what the state of the device is during a particular point in a frame rendering.

One thing I forgot to ask - are you using an unmodified version of the engine/ImageProcessor sample, or are you running with some changes?  If the latter, then perhaps we could diagnose the issue based on what is changed.

- Jason

Nov 7, 2011 at 8:53 PM

Thanks for explanations.

I'm using the unmodified demo.

I sent the file by email. Let me know if you received it.

 

Coordinator
Nov 9, 2011 at 8:41 PM

Hi Francois,

I received the file, but unfortunately I can't replay what is happening in the file since it is running in multithreaded mode (this is a limitation of the PIX tool).  Can you add the following line of code to the initialization method of your sample and generate a new PIXRun file:

m_pRenderer11->SetMultiThreadingState( false );
This will utilize the single threaded rendering path, and allow me to completely replay what is happening on your machine.  Sorry I didn't think of it earlier....

Nov 9, 2011 at 9:03 PM

Adding this code line makes the sample work as expected ! I see the text displayed.

Just to be sure, I removed the line and the text isn't shown anymore. Clearly the issue is related to multithreading.

FYI, my computer is a HP Z600 Workstation with dual Xeon E5620 (2 x 4 cores) and NVidia Quadro 4000 from HP.

-- François Piette

 

Coordinator
Nov 9, 2011 at 9:25 PM

Very interesting - and you have tried to run the same frame in multithreaded mode on the reference device???  There is clearly something wrong, as I have just tried it again and there doesn't seem to be any issue...  Can you try to pull a clean copy of the repository and try to rebuild that?  When it runs on the reference device, there should be zero influence from the drivers - which means that unless a project/compiler setting is different then it should be exactly the same in both cases.

Please let me know what you find!

Nov 10, 2011 at 7:53 PM

I have done a SVN update to get the latest changes. Now text are displayed using the reference device, regardless of multithreading. Without reference device, text is shown only when multithreading is disabled.

btw: On my computer, without multithreading, I get 870 fps with the imageProcessor demo using the separable gaussian alorithm which is the fastest.

 

Coordinator
Nov 10, 2011 at 9:41 PM

That is good news - sort of.  It means that the driver has some issues with the multithreading, and it should be corrected with improving driver updates.  I am still waiting on hearing about the Nvidia registered developer status (I should hear by the end of tomorrow...).  Until then, you will have to either rely on the single threaded mode, or simply run without the text being displayed...  Sorry for the inconvenience.

Nov 11, 2011 at 6:10 AM

Which multithreading is it ? CPU, GPU or both ?

 

Coordinator
Nov 11, 2011 at 1:45 PM

The multithreading that I am referring to (and which is switched on or off with the method described above) refers to the CPU side.  Essentially each render view that is used in a scene is used to generate a command list on its own thread with a deferred context, followed by the execution of those command lists on the immediate context.  In single threaded mode, all the code is directly executed on the immediate context without generating command lists.

This can occasionally lead to improved performance when you are CPU bound in applications.  However, from a rendering standpoint, the algorithm is exactly the same - the same shaders are used with the same pipeline configurations. 

The compute shader code for filtering is all multi-threaded on the GPU, which is specified at the shader level.

Dec 3, 2011 at 8:20 AM

Hello Jason,

I updated Hieroglyph3 to revison 72003 (SVN revision) and now the issue with text not rendered on screen is fixed. I have not updated my system, so IMO, it was not a driver problem but something into Hieroglyph3. Do you what you have changed which could has solved the issue ?

Thanks.

Dec 3, 2011 at 10:26 AM

I believe that this issue was fixed in the revision 71597. From the changelog: "Fixed a concurrency bug in GeometryDX11. Now the input assembler state is declared on the stack in the execute function call instead of using a member variable. This was interfering in MT mode when more than one view tried to simultaneously render the same GeometryDX11 instance." At least it fixed my problems with multithreading, including the issue with text not being shown on screen.

Coordinator
Dec 3, 2011 at 3:12 PM

Yes, I am pretty sure that Sephirothusi is right - the issue was due to a multithreaded access of a member variable in the GeometryDX11 class, which was being accessed in multiple threads and it was being overwritten.  It just happened that the text rendering thread was a little faster than another one, so it lost the battle...

Anyhow, this point went to show that the debugging of issues can't simply be switched to the reference device.  It can prove the submission of rendering calls, but can't guarantee that there is no timing issues in a MT environment.