DirectX 11 render system - work-in-progress
-
- Gnoblar
- Posts: 10
- Joined: Mon Jun 06, 2011 9:42 pm
Re: DirectX 11 render system - work-in-progress
Yes, I made this in Irrlicht Dx11.
There's no need to use pass, this can be done internally in D3D11RenderSystem, based on how the descriptions is filled during frame.
In fact, the state cache is already done by D3D11 driver internally, but Microsoft recommends we don't rely on this behavior.
There's no need to use pass, this can be done internally in D3D11RenderSystem, based on how the descriptions is filled during frame.
In fact, the state cache is already done by D3D11 driver internally, but Microsoft recommends we don't rely on this behavior.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: DirectX 11 render system - work-in-progress
I wrote this type of cache manager in the past, identifying the state was too costly.
I guess the bast solution is a new ogre "state" class, but it will be a big architectural change.
I guess the bast solution is a new ogre "state" class, but it will be a big architectural change.
Watch out for my OGRE related tweets here.
- boyamer
- Orc
- Posts: 459
- Joined: Sat Jan 24, 2009 11:16 am
- Location: Italy
- x 6
Re: DirectX 11 render system - work-in-progress
And what about adding all those state into ogre?
I mean ogre will have BlendState, RasterizerState, DepthStencilState and then map one by one with DirectX 11, in DirectX 9, OpenGL will be mapped as before?
I mean ogre will have BlendState, RasterizerState, DepthStencilState and then map one by one with DirectX 11, in DirectX 9, OpenGL will be mapped as before?
-
- Gnoblar
- Posts: 10
- Joined: Mon Jun 06, 2011 9:42 pm
Re: DirectX 11 render system - work-in-progress
I agree, Assaf. The greatest problem is that I used the description as key, and comparison made by memcmp !! There's no simple way to do this.
I don't think this is the best way, cause the APIs have different ways to do this. OGRE already abstract this behavior via _set state methods. Maybe we can expose the new states, as they exists in DirectX 11 and OpenGL 3+.
One thing that will help a lot is to expose the read-only depth buffer, allowing this to be bound as a texture unit and as depth-stencil buffer at the same time. This can accelerated some effects like deferred rendering.
I don't think this is the best way, cause the APIs have different ways to do this. OGRE already abstract this behavior via _set state methods. Maybe we can expose the new states, as they exists in DirectX 11 and OpenGL 3+.
One thing that will help a lot is to expose the read-only depth buffer, allowing this to be bound as a texture unit and as depth-stencil buffer at the same time. This can accelerated some effects like deferred rendering.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: DirectX 11 render system - work-in-progress
I also memcmp it, it was worse performance then creating them every call.
Watch out for my OGRE related tweets here.
- boyamer
- Orc
- Posts: 459
- Joined: Sat Jan 24, 2009 11:16 am
- Location: Italy
- x 6
Re: DirectX 11 render system - work-in-progress
I have a question about StateObject in DX11 RenderSystem, i saw that every time you _render(RenderOperation) method there is call for creation of BlendState,RasterizerState,DepthStencilState,SamplerState etc, i know that DX 11 inself pools creation of them and if any state object with the same description exists, it does not creates it but returns the same one, so basically into Ogre3D DX11 implementation is right the way in which they are handled or new way need to be added?
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: DirectX 11 render system - work-in-progress
I think that for now we can live with the current code, meaning I don't think this is a big issue - from the performance point of view.
Watch out for my OGRE related tweets here.
-
- Gnoblar
- Posts: 10
- Joined: Mon Jun 06, 2011 9:42 pm
Re: DirectX 11 render system - work-in-progress
I found an issue that impact not only Dx 11, but also the new OpenGL3+ Render System.
To implement CubeMap GS sample from DX 10 SDK (that render to all six faces of a cubic texture), I must create a render target array (that is different from multi render target). But, I can't do this in Ogre, because I pick render target from HardwarePixelBuffer, that is create for each face.
We must change this model to support this feature. Maybe a method like Texture::getSliceBuffer(int mipLevel), in addition to Texture::getBuffer(int slice, int mipLevel), what do you think?
To implement CubeMap GS sample from DX 10 SDK (that render to all six faces of a cubic texture), I must create a render target array (that is different from multi render target). But, I can't do this in Ogre, because I pick render target from HardwarePixelBuffer, that is create for each face.
We must change this model to support this feature. Maybe a method like Texture::getSliceBuffer(int mipLevel), in addition to Texture::getBuffer(int slice, int mipLevel), what do you think?
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: DirectX 11 render system - work-in-progress
Try it, and let us see it in your fork, if the change will look good - I am for it.
Watch out for my OGRE related tweets here.
-
- Gnoblar
- Posts: 10
- Joined: Mon Jun 06, 2011 9:42 pm
Re: DirectX 11 render system - work-in-progress
Hi people.
I'm developing the change to CubeMap GS, and was think to add, in MultiRenderTarget, the methods bindSurfaceArray(int attachment, RenderTarget* firstSlice, RenderTarget* lastSlice) and bindSurfaceCube(int attachment, RenderTarget* firstFace, RenderTarget* lastFace). Of course, the slices/faces shall be from the same texture and same mip level.
So, we just pass the 6 view matrices during rendering to render the scene to cube map. I think that, to make this automatic in the Viewport class, the change became too big in this moment.
I'm developing the change to CubeMap GS, and was think to add, in MultiRenderTarget, the methods bindSurfaceArray(int attachment, RenderTarget* firstSlice, RenderTarget* lastSlice) and bindSurfaceCube(int attachment, RenderTarget* firstFace, RenderTarget* lastFace). Of course, the slices/faces shall be from the same texture and same mip level.
So, we just pass the 6 view matrices during rendering to render the scene to cube map. I think that, to make this automatic in the Viewport class, the change became too big in this moment.
-
- Halfling
- Posts: 50
- Joined: Mon Mar 10, 2008 12:08 am
- Location: Stuttgart|Germany
- x 1
- Contact:
Re: DirectX 11 render system - work-in-progress
Hi I added texture2d-array support and fixed the unlockimpl and some other stuff,
here is the patch https://sourceforge.net/tracker/?func=d ... tid=302997.
Zero
here is the patch https://sourceforge.net/tracker/?func=d ... tid=302997.
Zero
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: DirectX 11 render system - work-in-progress
I will review and add this weekend.
Watch out for my OGRE related tweets here.
-
- Google Summer of Code Student
- Posts: 1005
- Joined: Wed Jan 08, 2003 9:15 pm
- Location: Lyon, France
- x 49
- Contact:
Re: DirectX 11 render system - work-in-progress
Hello,
I'm moving my game engine from DX9 to Dx11 render system and I'd like to have some infos about the state of the DirectX 11 render system.
First, is it possible to bind texture units to geometry program. As far as I see in the texture unit source code, there is only support for vertex and fragment program bindings, but I may have missed something.
This leads to the second question: Is there a todo list of things that are still not implemented somewhere, as I have some time to spend to help debug/finish the DirectX 11 render system.
I'm moving my game engine from DX9 to Dx11 render system and I'd like to have some infos about the state of the DirectX 11 render system.
First, is it possible to bind texture units to geometry program. As far as I see in the texture unit source code, there is only support for vertex and fragment program bindings, but I may have missed something.
This leads to the second question: Is there a todo list of things that are still not implemented somewhere, as I have some time to spend to help debug/finish the DirectX 11 render system.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: DirectX 11 render system - work-in-progress
Sounds good.
The main things that are not finished are the tessellation shader and multi monitor support.
I guess that you can benefit from the abstraction of the resources in d3d11 like you would like also... But I am not sure how much it is needed.
I have a few patches I need to integrate regarding geometry shader and other small things (possibly it includes the texture binding for geometry shader).
I guess the best way to know the status is to try to run your current product - but use the d3d11 render system and see issues.
The main things that are not finished are the tessellation shader and multi monitor support.
I guess that you can benefit from the abstraction of the resources in d3d11 like you would like also... But I am not sure how much it is needed.
I have a few patches I need to integrate regarding geometry shader and other small things (possibly it includes the texture binding for geometry shader).
I guess the best way to know the status is to try to run your current product - but use the d3d11 render system and see issues.
Watch out for my OGRE related tweets here.
-
- Google Summer of Code Student
- Posts: 1005
- Joined: Wed Jan 08, 2003 9:15 pm
- Location: Lyon, France
- x 49
- Contact:
Re: DirectX 11 render system - work-in-progress
You mean the fact that there is no more per-program-type resources and that the textures are usable for erveryone with the unified pipeline?I guess that you can benefit from the abstraction of the resources in d3d11 like you would like also... But I am not sure how much it is needed.
The main things that are not finished are the tessellation shader and multi monitor support.
Ok, I don't need multi monitor support for the moment, neither tesselation shader but I'd really like to play with this one, I'm going to look if I can add this.I guess the best way to know the status is to try to run your current product - but use the d3d11 render system and see issues.
Thanks.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: DirectX 11 render system - work-in-progress
Yes, no more per-program-type resources.
Compile and run the sample browser - it gives a good progress status.
Compile and run the sample browser - it gives a good progress status.
Watch out for my OGRE related tweets here.
- boyamer
- Orc
- Posts: 459
- Joined: Sat Jan 24, 2009 11:16 am
- Location: Italy
- x 6
Re: DirectX 11 render system - work-in-progress
Assaf, when do you plan to apply patches to DX11 RenderSystem?
One from Zero too.
Thanks
One from Zero too.
Thanks
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
-
- Google Summer of Code Student
- Posts: 1005
- Joined: Wed Jan 08, 2003 9:15 pm
- Location: Lyon, France
- x 49
- Contact:
Re: DirectX 11 render system - work-in-progress
Is the handling of multiple constant buffers in your todo list Assaf? If not this is something I could add as it seems to be important for performance, although I don't see any implementation proposal apart from this old post from Sinbad
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: DirectX 11 render system - work-in-progress
Feel free to help.
Watch out for my OGRE related tweets here.
- masterfalcon
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
- Contact:
Re: DirectX 11 render system - work-in-progress
I've actually been working on something to that effect for the uniform buffer support in gl3plus.
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
- Assaf Raman
- OGRE Team Member
- Posts: 3092
- Joined: Tue Apr 11, 2006 3:58 pm
- Location: TLV, Israel
- x 76
Re: DirectX 11 render system - work-in-progress
I just committed Zero's patch, I also fixed the texture atlas sample to support both gl and d3d11.
I am waiting for Evandro to sign the OGRE Contributor License Agreement before I can marge his fork. I sent him an e-mail.
I am waiting for Evandro to sign the OGRE Contributor License Agreement before I can marge his fork. I sent him an e-mail.
Watch out for my OGRE related tweets here.
-
- Google Summer of Code Student
- Posts: 1005
- Joined: Wed Jan 08, 2003 9:15 pm
- Location: Lyon, France
- x 49
- Contact:
Re: DirectX 11 render system - work-in-progress
Ok I'm going to make a design proposal for the multiple constant buffers, however it should take some time as it is not a trivial thing because it may be really different from previous Ogre implementation of shader parameters.
Before that, I got two errors, one when my Ogre::Terrain finalizes its normal map:
And another, really similar, when the setRenderTarget is called to se the shadow map render target.
EDIT: Bad error report sorry, it was just an occlusion query made in my engine to flush the gpu command buffer that was not done correctly.
Before that, I got two errors, one when my Ogre::Terrain finalizes its normal map:
The exception is thrown by these lines:ID3D11DeviceContext::GetData: GetData is being invoked on a Query/ Predicate/ Counter, after invoking Begin, but not yet after End. The range of commands must be completed by invoking End, before invoking GetData.
Code: Select all
case TEX_TYPE_CUBE_MAP:
case TEX_TYPE_2D:
case TEX_TYPE_2D_ARRAY:
{
mDevice.GetImmediateContext()->UpdateSubresource(
mParentTexture->GetTex2D(),
D3D11CalcSubresource(static_cast<UINT>(mSubresourceIndex), mFace, mParentTexture->getNumMipmaps()),
&dstBoxDx11,
converted.data,
d3dRowPitch,
0 );
if (mDevice.isError())
{
String errorDescription = mDevice.getErrorDescription();
OGRE_EXCEPT(Exception::ERR_RENDERINGAPI_ERROR,
"D3D11 device cannot update 2d subresource\nError Description:" + errorDescription,
"D3D11HardwarePixelBuffer::blitFromMemory");
}
}
Error Description:ID3D11DeviceContext::GetData: GetData is being invoked on a Query/ Predicate/ Counter, after invoking Begin, but not yet after End. The range of commands must be completed by invoking End, before invoking GetData.
in D3D11RenderSystem::_setViewport at .\src\OgreD3D11RenderSystem.cpp (line 1674)
EDIT: Bad error report sorry, it was just an occlusion query made in my engine to flush the gpu command buffer that was not done correctly.
-
- Google Summer of Code Student
- Posts: 1005
- Joined: Wed Jan 08, 2003 9:15 pm
- Location: Lyon, France
- x 49
- Contact:
Re: DirectX 11 render system - work-in-progress
Hello,
I'm trying to add the support of comparison samplers, I've succeded to handle the comparison filtering, but I'm stuck with the code managing samplers comparison function.
For the moment, the comparison function of a sampler is retrieved from the pass's alpha rejection setting(and alpha test is deprecated in DirectX11 ), though for comparison samplers it should be nice to have this value stored per texture unit, but it is not a trivial modification of Ogre.
Any idea? Of course this modification must preserve the compatibility for other renderers.
By the way, I'm still thinking about how to add the multiple constant buffer support, somes ideas emerged
I'm trying to add the support of comparison samplers, I've succeded to handle the comparison filtering, but I'm stuck with the code managing samplers comparison function.
For the moment, the comparison function of a sampler is retrieved from the pass's alpha rejection setting(and alpha test is deprecated in DirectX11 ), though for comparison samplers it should be nice to have this value stored per texture unit, but it is not a trivial modification of Ogre.
Any idea? Of course this modification must preserve the compatibility for other renderers.
By the way, I'm still thinking about how to add the multiple constant buffer support, somes ideas emerged