DirectX 11 render system - work-in-progress

[Assaf Raman]

Nice work!

[Crashy]

Some news on any new thing implemented?

I've seen that when creating a render to texture, the render target is created two times, one for the mip-level 0, and one for the mip-level 1, even if when created the render to texture I specifed that I wanted no mip maps.
I fixed that by doing:

Code: Select all

if (mUsage & TU_RENDERTARGET)
		{
			bufusage |= TU_RENDERTARGET;
			mNumMipmaps=0;
		}

But it's not really good looking to me.

[Assaf Raman]

Soon a Google Summer of Code project on this topic is going to begin. Then there will be progress, read more here.

[Eugene]

1. I found crash caused by negative mipmaps count requested from D3D runtime. Fix as well as related cleanups is here:
https://bitbucket.org/eugene_gff/ogre-winrt/changeset/09e2a4531a61

2. D3D11 render system can use materials with HLSL shaders written for shader model 2 or 3 if their target model would be forced to 4 and source compiled with compatibility flag. Patch that do this is located here:
https://bitbucket.org/eugene_gff/ogre-winrt/changeset/82a1d0e6843b

3. Sometimes material has two techniques - one high quality with shaders and other low quality without them. If shaders are incompatible (for example GLSL on D3D11 render system or CG when CG plugin is unavailable as for Metro style applications) than RTShaderSystem will try to generate compatible technique, but unfortunately will choose as source first technique with incompatible shaders, and than fail if flag overProgrammable is not set. Patch that fixes RTSS logic allowing to choose first non-programmable technique if flag overProgrammable is not passed, and still choose first technique if flag overProgrammable is set located here:
https://bitbucket.org/eugene_gff/ogre-winrt/changeset/87d72cadb859

4. I tried to tweak RTSS to generate shaders for shader model 4 so that it can be compiled without compatibility flag. There were two problems: shader parameters semantic should be SM4 compatible, i.e. SV_Position instead POSITION and so on. Patch that do this is located here: https://bitbucket.org/eugene_gff/ogre-winrt/changeset/c8cd489db064.
Other issue is related to the splitting SM2 texture sampler into the separate texture and sampler state in shader model 4. This requires passing them separately into the FFP_SampleTextureXxx() functions family using additional parameter as well as another implementation for those functions. This requires careful planning and is not yet done. May be now it even don`t worth the efforts.

Some more patches are on top of https://bitbucket.org/eugene_gff/ogre-winrt branch, such as fixed uninitialized variable bool EdjeData::isClosed that causes different binary serialization of mesh even if edge data are not used at all, moving HardwareBufferLockGuards from OgreProgressiveMesh.h to their guarded resources declarations, and operator -= for atomic wrappers to avoid applying unary minus to possibly unsigned value that leads to catastrophe if subtracted value has smaller size than destination:

Code: Select all

AtomicScalar<unsigned long> value; unsigned short delta; value += -delta;

5. Yet another one problem was fixed: freed memory usage in HLSL #defines extraction code. https://bitbucket.org/eugene_gff/ogre-winrt/changeset/1715a541bac4

P.S. As I periodically rebase my work on top of the current branch, direct links became broken, but changesets can be found easily.

[Fedyakin]

I was getting an error message "ID3D11Device::CreateVertexShader: Invalid shader version provided: vs_5_0 [ STATE_CREATION ERROR #167: CREATEVERTEXSHADER_INVALIDSHADERTYPE ]" with the dx11 renderer. I believe the cause is that the renderer always indicates that it supports shader model 5, even if the created device doesn't support it (see http://msdn.microsoft.com/en-us/library ... 85%29.aspx). I modified D3D11RenderSystem::convertVertexShaderCaps and D3D11RenderSystem::convertPixelShaderCaps slightly, and it fixed the problem for me.

I replaced the unconditional calls in both functions

Code: Select all

rsc->addShaderProfile("ps_4_0");
rsc->addShaderProfile("ps_4_1");
rsc->addShaderProfile("ps_5_0");

with a test that looks like the following (ps_x_x and vs_x_x based on function)

Code: Select all

        switch( mDevice->GetFeatureLevel() )
        {
        case D3D_FEATURE_LEVEL_11_1:
        case D3D_FEATURE_LEVEL_11_0:
            rsc->addShaderProfile("ps_5_0");    
            // Fallthrough
        case D3D_FEATURE_LEVEL_10_1:    
            rsc->addShaderProfile("ps_4_1");    
            // Fallthrough
        case D3D_FEATURE_LEVEL_10_0:    
            rsc->addShaderProfile("ps_4_0");    
            // Fallthrough
        }

[Assaf Raman]

Good.

[Crashy]

Does anybody else than me has problems with the hardware occlusion queries?

I use the GpuCommandBufferFlush class (http://www.ogre3d.org/tikiwiki/tiki-ind ... ufferFlush) to avoid some jittering, it works nice but sometimes the program is stuck here (in D3D11HardwareOcclusionQuery::pullOcclusionQuery)

Code: Select all

 

const HRESULT hr = mDevice.GetImmediateContext()->GetData(mQuery, (void *)&pixels, dataSize, 0);//D3DGETDATA_FLUSH

                if  (hr == S_FALSE)
                    continue;
                if  (hr == S_OK)
                {
                    mPixelCount = pixels;
                    *NumOfFragments = pixels;
                    break;
                }

getData() always return S_FALSE so it never goes out of the while(1) loop.

[Assaf Raman]

Never tried it, I don't know if I implemented it currently, you may want to look at the relevant DX SDK sample and see what they do there...

[Crashy]

I cannot find a way to solve the problem. I don't understand why getData always returns S_FALSE. From what I've seen on different forums, implementation in Ogre is fine. I'll check that later.


I have another problem I've encountered when I'm editing the geometry of the terrain: the call of ID3D11Device::Map in "3D11HardwareBuffer::lockImpl" is really slow. This issue is also visible in the Ogre Terrain Sample when editing terrain: whereas editing terrain is quite fast with DirectX 9 render system, it is much slower with DirectX 11 rendersystem.


When the TerrainQuadTreeNode vertex buffer( which usage is D3D11_USAGE_DEFAULT) is locked, it creates a staging hardware buffer, copy the first buffer into this staging buffer, and when unlocking, it copy from the staging buffer to the first buffer, which is what is described here

So the bottleneck in my case is the ID3D11Device::Map called with the staging buffer as a parameter. Why is it so slow?
The documentation says:

Don't read from a subresource mapped for writing
When you pass D3D11_MAP_WRITE, D3D11_MAP_WRITE_DISCARD, or D3D11_MAP_WRITE_NO_OVERWRITE to the MapType parameter, you must ensure that your app does not read the subresource data to which the pData member of D3D11_MAPPED_SUBRESOURCE points because doing so can cause a significant performance penalty

.

When the staging buffer is locked, the mapType is D3D11_MAP_READ_WRITE, so none of the list given above.

I don't get it

[gfxguy25]

While working on Direct3D on XAML I implemented D3D11RenderWindowImageSource using two SurfaceImageSource-s and one ImageBrush to emulate swapchain, so that UI thread would not be blocked while 3D scene is rendered in background thread.

But there are some issues:
1) SurfaceImageSource can return surface larger than requested, and active rectangle can be offset. For example, when I requested surface with size 800x600 I got 832x640 and update rectangle origin was located at (31,39). This would require Viewport tweaking before rendering with some amount of messy code.
2) As surface can be different each frame I should each time recreate render target view and recreate depth stencil and corresponded view if surface size is changed.
3) Probably resetting ImageBrush->ImageSource should be done via Dispatcher if rendering is done from another thread, and this would complicate the story further.

Therefore I decided that I don`t like this approach. I`ll implement another one - instead of two SurfaceImageSources there would be one and intermediate ID3DTexture2D with exactly required size thus avoiding messing up with viewports. As texture would be mine, depth stencil and both views would be reused. Swapping would be done via copying that texture into the SurfaceImageSource`s IDXGISurface using provided update rectangle.

I think the swap chain model will be better here as the MSDN site recommends. The image source looks to be targeted mainly at low usage scenarios - where you render content once but update it infrequently, not every frame.

Using two image sources will only be bad btw, as it will entail many copies and updates.....

[Eugene]

I think the swap chain model will be better here as the MSDN site recommends. The image source looks to be targeted mainly at low usage scenarios - where you render content once but update it infrequently, not every frame.

Using two image sources will only be bad btw, as it will entail many copies and updates.....

It`s exactly the scenario for which D3D11RenderWindowImageSource was implemented. If you need something for real-time full screen game - look at D3D11RenderWindowCoreWindow which is swapchain based.

[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).

This post also appears on the GSoC thread http://www.ogre3d.org/forums/viewtopic. ... &start=250 and you can answer wherever you want. It is really important to debug these errors so as to continue with further feature implementation and to finish D3D11 Render System.

Thanks

[ahmedismaiel]

please refer to my patch
http://www.ogre3d.org/forums/viewtopic. ... 00#p445333

and crashy's patch
http://sourceforge.net/tracker/?func=de ... tid=302997

they should cover compositor (MRT ,deferred) and shader system issues.

[robert_sasu]

Please read the forum thread from Google Summer of Code, these patches are included already (or look at the wiki page of this project.)

[ahmedismaiel]

oh cool ,i didn't know that .i'll start syncing my trunk and check it out with our project

[robert_sasu]

I have added your changeset to my repo, see the link on the first post. I have also added a bugfix (now the rain from particle effects works correctly).
Neither of the Terrain samples are working for the current DirectX 11 Render System. I got this error while running:


In every render system, if you run the Water sample put the skybox on and press space to have rain, the rain particles are green.

[ahmedismaiel]

what happens when Information Queue Exceptions to No information queue exception ?
i have seen errors like this one while porting stuntrally terrain code to d3d11,but those are not errors per say (ogre is just surfacing them as errors) .first you have to make sure the app can go on without them then the right fix is create the vertex buffer with the appropriate vertex format which in this case will prevent the sint to float conversion potentially saving some performance (but negligible). at least it'll get rid of the warning .keep in mind that those warnings only show up with debug devices and shouldn't show up in release builds

[Assaf Raman]

In release or debug you can set the error log level in the OGRE cfg.

[robert_sasu]

By setting that I will not see anything on running the terrain sample just blakc and some white point in the center. This is probably because of the conversion between SINT and FLOAT. If you try to put the shadows on you will get an immense error:

[Assaf Raman]

well, this message is clear, right?

[robert_sasu]

Yes it is clear. Those shaders needs to be rewritten to be compatible with direct 11 render systyem.

[Assaf Raman]

yes

[robert_sasu]

I have some news . I have asked ja0335 for his source code of the Ogre Parametric PN-triangles Tessellation, which uses the new shader models. Here is a link for showcase:http://www.youtube.com/watch?v=miKcF1vsHiY

He was really kind and gave it to the community, so I will add the sample to the Sample Browser to have another sample for DirectX 11 Tessellation. I have an almost free weekend , so I will try to finish it

[PhilipLB]

Btw, I'm curious. What's the general state of the DX11 rendersystem? Is it featurecomplete now?

[Assaf Raman]

work-in-progress