[GSoC 2012] Complete the DirectX 11 render system

[ja0335]

This new feature in Ogre is really awesome.

Bellow is a video about the implementation i have done in Parametric PN-Triangles Tessellation

Really, really congratulation to robert_sasu and the previous work from Assaf Raman

http://www.youtube.com/watch?v=miKcF1vs ... e=youtu.be

[youtube]http://www.youtube.com/watch?v=miKcF1vs ... e=youtu.be[/youtube]

[Evandro Millian]

Hi Robert.

I was away from the project, now working with Unity3d. But I'm very pleased that my work can help you in this GSoC.

Congratulations, this is a great work that will greatly improve Ogre.

[robert_sasu]

Thanks . ja0335 that is a really nice video and sample . I was away for the last 10 days. I will start again to work here (a little bit slower), on bugfixes and further feature implementations .

[Xavyiy]

Thanks . ja0335 that is a really nice video and sample . I was away for the last 10 days. I will start again to work here (a little bit slower), on bugfixes and further feature implementations .

Awesome! Can't wait to see the DX11 RS a little more tested and showcased!

[Assaf Raman]

We do needed some better d3d11 features samples in the sample browser.

[gfxguy25]

This is awesome work. Serious congrats to robert_sasu and Assaf!

I have been playing with the few samples (that are currently working - I realize more work is to be done) - noticed that the performance is really bad (hardly getting 20fps).
I am looking at the WinRT D3D11 render system code and it was strange to see the use of a SurfaceImageSource. MSDN says that this is going to be slow. Is there a preference to use this instead of the high-performance SwapChainBackgroundPanel?

Every time you call BeginDraw/EndDraw, the surface is going to be blitted on the XAML end - plus the allocation of a new surface each frame. I believe this was intended for small surface updates (hence the rect being passed to begindraw) as the MSDN site explains. Plus there is an extra CopySubresourceRegion call as well from Ogre end (see swapBuffers).

Am I the only one seeing bad perf?

[Assaf Raman]

Yes, give us some specs and also, try to run in release and not debug.
BTW: What do you mean by XAML? are you running the WinRT compile?

[gfxguy25]

Yep, I run in release - either gives about the same perf. Around 15fps - 20fps max.
Running the desktop version nets 100 or more fps for the same samples.

So, the WinRT port of the sample browser uses native XAML - the code passes in the CoreWindow and such to the D3D11 code and then the D3D code connects its swapchain with a XAML element inside this CoreWindow that the sample browser passes in. All of this is in native C++, but the XAML higher-level UI code is in C++ /Cx which has language extensions (sorry if I am repeating things you already know). The underlying DLLs that are in pure C++ talking with actual D3D code interface with this C++ /Cx code using ABIs exported by the OgreMain, RenderSystem DLLs.


See http://msdn.microsoft.com/en-US/library ... s/hh825871 for more details - especially the last part about SwapChainBackgroundPanel. You could avoid extra texture copies - which is currently being done.

[Assaf Raman]

Can you post this issue on this thread: http://www.ogre3d.org/forums/viewtopic.php?f=4&t=69209 ?
as this is becoming off topic from the current thread.

[Eugene]

I have been playing with the few samples (that are currently working - I realize more work is to be done) - noticed that the performance is really bad (hardly getting 20fps).
I am looking at the WinRT D3D11 render system code and it was strange to see the use of a SurfaceImageSource. MSDN says that this is going to be slow. Is there a preference to use this instead of the high-performance SwapChainBackgroundPanel?

Every time you call BeginDraw/EndDraw, the surface is going to be blitted on the XAML end - plus the allocation of a new surface each frame. I believe this was intended for small surface updates (hence the rect being passed to begindraw) as the MSDN site explains. Plus there is an extra CopySubresourceRegion call as well from Ogre end (see swapBuffers).

Am I the only one seeing bad perf?

If you take a look at http://www.ogre3d.org/forums/viewtopic. ... 50#p455327 you`ll see that planned hierarchy at those times was

D3D11RenderWindowBase

• D3D11RenderWindowSwapChainBased
  • D3D11RenderWindowHwnd
    D3D11RenderWindowCoreWindow
    D3D11RenderWindowComposition (not yet implemented)
  D3D11RenderWindowImageSource (not yet implemented, WIP)
  D3D11RenderWindowVirtualImageSource (not yet implemented)

Now D3D11RenderWindowImageSource is already implemented as I needed it.
All you need to do to use SwapChainBackgroundPanel - is D3D11RenderWindowComposition implementation that would do dxgiFactory->CreateSwapChainForComposition(); bgPanel->SetSwapChain(). It`s not a choice - different applications needs different kinds of render targets.

[gfxguy25]

I see. Thanks Eugene. I will move this thread there.
SwapChainBackgroundPanel should be the default IMO, because it is the fastest.

[Eugene]

I see. Thanks Eugene. I will move this thread there.
SwapChainBackgroundPanel should be the default IMO, because it is the fastest.

D3D11RenderWindowCoreWindow is the fastest, and is default.
SwapChainBackgroundPanel allows some XAML on top of 3D window, but causes big overdraw. Could be only one, could not be drawn to in background (as UI is still locked).
SurfaceImageSource useful for small 3D views embedded in generally not 3D app, could be several, updated in background - think about CADs instead of games.

[gfxguy25]

ah, I see that makes perfect sense now, thanks Eugene!..

Is there a sample that uses D3D11RenderWindowCoreWindow? The default one uses a SurfaceImageSource, and hence my confusion. Sorry about that.

[Eugene]

ah, I see that makes perfect sense now, thanks Eugene!..

Is there a sample that uses D3D11RenderWindowCoreWindow? The default one uses a SurfaceImageSource, and hence my confusion. Sorry about that.

Yes, SampleBrowserWinRT works over D3D11RenderWindowCoreWindow and SampleBrowserWinRTXaml works over SurfaceImageSource, they are located near each other.

[robert_sasu]

Hi,

I have started to work again on the DirectX 11 Render System. The new code fork of the project is: https://bitbucket.org/sasu_robert/ogre3d-directx11
I will add the first changeset tomorrow. There are a few more issues, bugs on the current DirectX 11 Render System. The first thing to do is resolving all these problems (there are a few samples which are not working). After that I will finish the multi-device support for this render system. There was a lot to do in the summer and I had no time for these issues, some of them are trivial (probably), but it is hard to find.

Here is the list of the samples which are currently not working ( error describe for some of them):
1. Compositor - bad color for the OldTV compositor
2. Deferred shading - crash on start
3. Dual Quaternion - crash on start
4. Dynamic Texture - wrong color of the frost texture (red, and it is supposed to be blue)
5. Instancing - there is just only one model rendered (or 2 if you set to render 160.)
6. Isosurf - crash on start
7. NewInstancing - a lot of visual bugs, you can't see any of the models.
8. SSAO techniques - crash on start
9. Shader system - sometimes bad skybox, error when trying multiple viewports or shadows.
10. Shader system texture fog - sky box does not appear on initializing, if you deselect and select again it will work
11. Grass sample - there is no animation on the grass, ogre head is rendered incorrectly (no normal mapping, I think.)
12. Shadow sample - missing shaders which are supported by D3D11RS (there is no fixed pipeline in D3D11)
13. Terrain sample and volume rendering with LOD aimed terrain - crashes on start

It would be great if the community would help by resolving those bugs. If someone wants to send a patch, post it here or if you ask and you have no permission to push changeset to the repository I will add it. (Currently I have inherited all the permissions from the official ogre trunk, so many of you can directly push his work.).

I will post regularly about the work what have been done and the work which is proposed to be done in the next 3 days (maximum).

Thanks

[robert_sasu]

Today I have resolved I have pushed my code to the repo, in which I have resolved a compiling error (if you build it on 64bit machine with VS 2010.). I have also resolved a bug which regards the particle effects sample, when turning rain on (error of alpha-blending).

[gfxguy25]

ah, I see that makes perfect sense now, thanks Eugene!..

Is there a sample that uses D3D11RenderWindowCoreWindow? The default one uses a SurfaceImageSource, and hence my confusion. Sorry about that.

Yes, SampleBrowserWinRT works over D3D11RenderWindowCoreWindow and SampleBrowserWinRTXaml works over SurfaceImageSource, they are located near each other.

OK, I figured out the cause for the performance drop when using the XAML sample. What happens is that when you Present to the Ogre Swap Chain, it needs to be 'picked up' by the XAML swapchain as well (to lay its contents out). If you use your own timer, then you are going to be throttled, because you are going to be out-of-order and the app requiring multiple presents.

All this, I figured by looking at the awesome Simple3DGameXaml out there in MSDN - use CompositionTarget::Render::add() instead of the DispatchTimer. This FINALLY gets 60fps for SurfaceImageSource.

[Assaf Raman]

Nice, can you submit a patch?

[gfxguy25]

Nice, can you submit a patch?

I do not know how to do that, sorry. This is a two-line change though:

Code: Select all

void SampleBrowserWinRT::StartRendering()
{
...
    m_onRenderingEventToken = CompositionTarget::Rendering::add(ref new EventHandler<Object^>(this, &SampleBrowserWinRT::DisplayCurrentFrame));
}

and remove the existing DispatchTimer call in the constructor.

[Eugene]

OK, I figured out the cause for the performance drop when using the XAML sample. What happens is that when you Present to the Ogre Swap Chain, it needs to be 'picked up' by the XAML swapchain as well (to lay its contents out). If you use your own timer, then you are going to be throttled, because you are going to be out-of-order and the app requiring multiple presents.

All this, I figured by looking at the awesome Simple3DGameXaml out there in MSDN - use CompositionTarget::Render::add() instead of the DispatchTimer. This FINALLY gets 60fps for SurfaceImageSource.

Nice finding!