[GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Threads related to Google Summer of Code
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

I think it is not a bug. It really depends on how the elements are bound to the GPU buffer from the object (in this case the sky object). In general they are bounded with (position, texcoord, normals, etc.). So you need to read them out from the GPU in the same order. In your case if you delete that line with SV_position, the texcoord will always be x and y from the SV_position.
The DX11 Render System does not optimize it out this, and there is no need to do it as the developer was the one who thought he will need everything (position,texcoord .. ) when he bound his object to the GPU buffer.
Look at all of the Ogre / Microsoft Samples with Shader Model 4.0, 5.0 and DirectX 11. Even that you do not use the position of an object it is always there, because at init time/loading the object was bounded to GPU with all the information.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by lunkhound »

@dark_sylinc:

Thanks for that link, very informative!

@robert_sasu:

I'm not sure I understand what you wrote. It seems like you are saying that it has something to do with the vertex shader input parameters, but that isn't the problem. The vertex shader needs the SV_Position input and can't work without it. The vertex shader works fine, inputs and outputs look good (checked with a GPU debugger).
The problem lies with how the vertex shader OUTPUTS are mapped to pixel shader inputs. The main purpose of semantics is to allow this mapping, but you seem to be suggesting that the semantics don't matter and rather that it is the ordering of parameters that matters.

Note that because pixel shaders need this extra dummy input parameter in order to get the other inputs properly mapped, this means that using D3DCOMPILE_ENABLE_BACKWARDS_COMPATIBILITY is not possible because DX9 doesn't permit pixel shaders to take a POSITION input, whereas now its REQUIRED!
That's a shame, because it would be so much easier to start using the DX11 render system if backwards compatibility worked.
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by lunkhound »

Reading further on linking shaders, it seems that both the semantics (and type) as well as the ordering of the parameters needs to match exactly between the shader stages or you get a broken linkage. The only exception being that the pixel shader can omit some parameters at the end of the list of the vertex shader outputs.

Seems its not a bug. I'm not sure how that is supposed to work with the backwards compatibility mode though.

However, I'm surprised that there isn't any kind of warning or error message when I draw stuff with a broken linkage--instead I just get garbage output.
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

Sorry for misunderstanding your problem.

During the development of the DirectX 11 Render System and bugfixing the samples I have had a lot of similar problem with the shaders.
After that I have passed the parameters through structures, so to handle better this linkage errors.
Look at the Ogre Samples and the associated materials, shaders to them (targets or profiles of ps_4_0_level_9_1 and so for.): for example
Dynamic Texture (material: https://bitbucket.org/sasu_robert/ogre3 ... at=default
shader:https://bitbucket.org/sasu_robert/ogre3 ... at=default)
or the basic shaders from (material: https://bitbucket.org/sasu_robert/ogre3 ... at=default
shaders:https://bitbucket.org/sasu_robert/ogre3 ... at=default).
All of these are compatible with systems of Direct3D 9.1, 9.2, and 9.3 feature levels.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by lunkhound »

Using structures to pass parameters seems like a really good idea. That cleans things up and ensures that the ordering and semantics match perfectly.
All of my shader code was written for DX9/SM3 however, and you couldn't do that because you can't pass the POSITION parameter to the pixel shader. So for most code I used structures to pass all of the parameters--except for POSITION.
When I adapted this code over to DX11 I didn't understand the changes in shader-linkage, and most of all I didn't expect that there would be no error checking whatsoever!

I'd like to add some shader signature checking, most likely in D3D11RenderSystem::_render(...), to throw an exception if the shader signatures are incompatible. Perhaps only in DEBUG builds to avoid impacting performance.
Ideally it should only be done when a Technique/Pass is compiled, but I think that would generate alot of false exceptions for Passes that aren't actually used.
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by lunkhound »

So I created a pull request for the shader signature checking.

On an unrelated note, I noticed that hardware gamma didn't seem to be working for DX11. I made a pull request for that too.
jammm
Gnoblar
Posts: 3
Joined: Sun Jan 11, 2015 10:07 am

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by jammm »

Is the DirectX11 renderer complete yet? Maybe it could go on as another GSoC project for this year, as I feel I can help contribute to this :D
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by lunkhound »

jammm wrote:Is the DirectX11 renderer complete yet? Maybe it could go on as another GSoC project for this year, as I feel I can help contribute to this :D
The DX11 in the default branch (that's Ogre 1.10) has received a good number of fixes and enhancements over the past year. I would say it is pretty much complete.

Note that the 2.0 branch and others are lagging behind in getting the latest changes to the DX11 render system.
Crashy
Google Summer of Code Student
Google Summer of Code Student
Posts: 1005
Joined: Wed Jan 08, 2003 9:15 pm
Location: Lyon, France
x 49

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by Crashy »

Hi,

I've made some benchmarks, and I've noticed that the D3D11 rendersystem is by far slower than the two other when dealing with a high number of - even simple - objects.

My sample scene is a modification of the skydome sample, and creating 20*20 cubes with a super simple material (no textures, no lighting, RTSS used to generate the shaders on D3D11)
I've got almost the same performance difference with both ogre 1.10 and Ogre 2.0(although performance are a bit better with Ogre 2.0 due to the various optimizations in the scene manager)

Here are the results I have on a Core 2 Duo 6850 + AMD HD 4870:
D3D 9 : 449 FPS
Open Gl : 238 FPS
D3D 11: 111 FPS

I'm not that surprised by the Open Gl performance drop because of my AMD graphic card, but having my frame rate divided by 4 (!) switching from D3D9 to D3d11 is really annoying.

It really seems to be related to the fact I'm rendering a lot of objects, but I don't really see what's would cause the problem.

I've a only two leads:
  • Setting the pass/material properties is slow.
  • Current implementation of constant buffers is not optimal, but I don't think it can be this time consuming...
I've got some extra time right now to make deeper investigations/optimizations but I've no idea on how to find what's the bottleneck.
Follow la Moustache on Twitter or on Facebook
Image
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by holocronweaver »

To profile a render system, I would start with an automated CPU profiler and see if there are any unusually taxing calls. If the CPU does not appear to be misused, then the GPU might be. While there are automated GPU profilers for DX11, most I tried a couple years ago were buggy so you may be better off just littering DX11 queries at key points of the render system. You can start by querying around the render (a.k.a. draw) routine itself, then add queries for subcomponents if you find the draws taking to long and want to know why.

Edit: you mention relying on RTSS to generate shaders. That could very well be the source of your problem since the quality of the shaders may drastically differ.
Crashy
Google Summer of Code Student
Google Summer of Code Student
Posts: 1005
Joined: Wed Jan 08, 2003 9:15 pm
Location: Lyon, France
x 49

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by Crashy »

Edit: you mention relying on RTSS to generate shaders. That could very well be the source of your problem since the quality of the shaders may drastically differ.
i've made other tests using a very simple hand made shader, same thing is happening.
Follow la Moustache on Twitter or on Facebook
Image
Crashy
Google Summer of Code Student
Google Summer of Code Student
Posts: 1005
Joined: Wed Jan 08, 2003 9:15 pm
Location: Lyon, France
x 49

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by Crashy »

Hi,

I've made some more test, and I've a few leads.
The point here is to reduce api calls/cpu load as much as possible when rendering a lot of simple objects sharing the same material/geometry (but in my case I cannot use static geometry nor instancing).

Sometimes the problem is not where we'd think it is. For example, in

Code: Select all

 ID3D11Buffer* D3D11HLSLProgram::getConstantBuffer(GpuProgramParametersSharedPtr params, uint16 variabilityMask)
This line -> BufferInfoIterator it = mBufferInfoMap.find(0);
Is really slow, and replacing it by:

Code: Select all

if(mBufferInfoMap.size() > 0 )
        {
			BufferInfoIterator it = mBufferInfoMap.begin();
...
Saves a few milliseconds per object.

Once I've finished my current changes I'll post some news :)
Follow la Moustache on Twitter or on Facebook
Image
User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2703
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 51

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by syedhs »

Code: Select all

if(mBufferInfoMap.size() > 0 )
A few further nanosecond save :D.. replace the above with

Code: Select all

if(!mBufferInfoMap.empty() )
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
Crashy
Google Summer of Code Student
Google Summer of Code Student
Posts: 1005
Joined: Wed Jan 08, 2003 9:15 pm
Location: Lyon, France
x 49

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by Crashy »

Haha yes !

I think I'm done scratching some ms. Now I reach 420 fps instead of 111 for the same scene, that's about 6.7 ms saved for 400 objects.

Okay, that doesn't sound that exciting, but in some case (when rendering a lot of identical objects) it could be very useful, as In my project where I use both shadows and reflections, this saves a lot of framerate: from 36 FPS to 55 FPS.


Basically what I've done is to reduce as much as possible state changes and don't send the blending/rasterizer/stencil/texture unit states at EACH ::_render call but only if the material has changed. Most of this work was already there but in an unfinished state. For shadows rendering passes, this is really interesting as 90% of typical shadow caster objects are using the same material.


There are a lot of differences between the default and 2.0 and the default branch seems to be the most recent one for the D3D11 rendersystem, so should I make a pull request on this one ? (I'm working on 2.0, but can port the modifications on default if needed)
Follow la Moustache on Twitter or on Facebook
Image
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by lunkhound »

I suggest porting it to the default branch. It has the most up to date DX11 render system, and all of those changes will be getting merged into 2.x pretty soon I would think.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5429
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1337

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by dark_sylinc »

Indeed. D3D11 has been barely touched in 2.x branch while default (1.10) branch has received tremendous development.
I will probably merge default -> 2.0 -> 2.1 by just telling "Take other" to all of the files.