DirectX 11 render system - work-in-progress
- _tommo_
- Gnoll
- Posts: 677
- Joined: Tue Sep 19, 2006 6:09 pm
- x 5
- Contact:
Re: DirectX 11 render system - work-in-progress
Maybe, it would make sense to break the D3D "double" enum to one enum and a boolean:
"bool static"
and
"enum AccessMode = { NONE, WRITE_ONLY, READ_ONLY, WRITE_READ }"
After all the current Ogre enum just maps to the OGL and DX ones because of the limited number of supported pairs of values, while it could actually map to two different concepts... but this would require a big interface change anyway...
"bool static"
and
"enum AccessMode = { NONE, WRITE_ONLY, READ_ONLY, WRITE_READ }"
After all the current Ogre enum just maps to the OGL and DX ones because of the limited number of supported pairs of values, while it could actually map to two different concepts... but this would require a big interface change anyway...
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: DirectX 11 render system - work-in-progress
The Usage enum is already a bitmask anyway so you can separate these things already.
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: DirectX 11 render system - work-in-progress
I've thought of that too, but there's something that is bugging me, which is async transfers.sinbad wrote: In principle yes, but actually what might be a good idea is to break the permanent 1:1 relationship between the GPU copy and the CPU-accessible version in both read and write modes. Given the same size & format for example, there's no reason why multiple textures couldn't be updated via one intermediate buffer, or why a read operation couldn't re-use an existing temporary surface used for all textures of the same dimensions and format. This could lead to more efficient staging of content which is presumably the idea behind the change.
Imagine we're loading two 512x512 textures, same format, let's call them A and B.
By using two intermediate buffers, the order should be this one (although in practice they may get serialized):
1) Load A into intermediate texture, CPU -> GPU (non-local)
2a) Copy A to the final texture, GPU (non-local) -> GPU
2b) While copying A, load B into intermediate texture, CPU -> GPU (non-local)
3) Wait for A to complete it's transfer
4) Copy B to the final texture, GPU (non-local) -> GPU
2a and 2b are happen concurrently. Again, I don't know in practice if this happens at all or if it's worth the benefit.
Also this needs loading gets done in batches, not scattered among portion of the code.
By using a global intermediate texture for boths, there's an unavoidable dependency:
1) Load A into intermediate texture, CPU -> GPU (non-local)
2) Copy A to the final texture, GPU (non-local) -> GPU
3) Wait for A to complete it's transfer
4) Repeat steps 1) & 2) for texture B
Not to mention that DX10 documentation clearly states that when this happen, we don't just have to wait for A to finish it's GPU->GPU copy, but actually wait for ALL operations in the command buffer. (see Copying and Accessing Resource Data (Direct3D 10), Performance Considerations section)
Either way, there's no big deal with either alternatives regarding coding them. We already share DepthBuffers across textures (that are render targets). This would be exactly the same for intermediate buffers. Just find a texture with matching resolution, format, and usage (staged vs dynamic); else a new one is created.
Bigger textures could be used to fit the smaller ones, though I'm worried mapping a (i.e.) 4096x4096 intermediate buffer just to load a 256x256 texture may cause several degrees of performance hits.
AMD suggets a 3rd alternative, see GPU Performance Programming with DirectX 10 slide 35 (sound starts at 20:34), where (i.e.) a 4096x4096 stage texture is created to upload 64 512x512 textures, then use CopySubresourceRegion to upload to the right GPU Default textures. But with this alternative, we still need 64x more memory for the intermediate texture. The memory problem still exists, and it's great for batch-uploading to the GPU, but very inflexible & Ogre unfriendly by the moment.
I was thinking of the first too. That's why I wrote "moderate to hard" difficulty.sinbad wrote: As for the D3D10_USAGE_IMMUTABLE flag, the key will be to defer creation of resources until the last possible moment (ie when data is available), which isn't that hard in principle except that the texture loading routines currently use a common loading path which assumes a create surfaces/populate data sequence. This could either be changed throughout to allow for unified implementations of create/populate, or the Dx11 implementation could simply override the common routines more fundamentally to change that assumed sequence. The former is better, but more complicated.
I'm certainly against overloading routines. I find it error prone and will most likely cause inconsistencies hard to spot when switching RenderSystems (because D3D11 plugin will follow a different code path).
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Re: DirectX 11 render system - work-in-progress
Yeah, good points - to re-use we'd have to ensure that a CopyResource call had actually been enacted before re-using the surface, which makes it complicated. Again the driver used to have the knowledge required to know what outstanding calls on a resource were in the command buffer, but now we have to do it. Lovely.
-
- Gnoblar
- Posts: 24
- Joined: Mon Sep 26, 2005 6:39 am
- x 1
Re: DirectX 11 render system - work-in-progress
On hg head is SampleBrowser supposed to be corrupted for both dx10 and dx11?
I'm using VS9, Windows 7 and an Ati HD5850.
I'm using VS9, Windows 7 and an Ati HD5850.
- 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
No problem on my system - just got a fresh hg head - compiled and run.
Watch out for my OGRE related tweets here.
-
- Gnoblar
- Posts: 24
- Joined: Mon Sep 26, 2005 6:39 am
- x 1
Re: DirectX 11 render system - work-in-progress
Assaf Raman what is your system specification?
- 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
dell m1330 with an Nvidia geforce 8400.
Seems like a driver issue on your computer - ATI\AMD allways have driver issues.
Seems like a driver issue on your computer - ATI\AMD allways have driver issues.
Watch out for my OGRE related tweets here.
-
- Gnoblar
- Posts: 24
- Joined: Mon Sep 26, 2005 6:39 am
- x 1
Re: DirectX 11 render system - work-in-progress
I want to target Direct X 11 and the Ati HD 5800 series is the only series available that supports dx11. Nvidia's cards will be faster when they come out. But the HD 5800 series will be a baseline.
- 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
iFire's problem should be fixed in the trunk.
I removed the old shader generator from the d3d11 render system and now the RTSS is used from the first frame.
BTW: I am going to delete the d3d10 render system from the trunk - we don't need both d3d10 and d3d11 render systems - d3d11 covers d3d10 and gives more options.
I removed the old shader generator from the d3d11 render system and now the RTSS is used from the first frame.
BTW: I am going to delete the d3d10 render system from the trunk - we don't need both d3d10 and d3d11 render systems - d3d11 covers d3d10 and gives more options.
Watch out for my OGRE related tweets here.
- tuan kuranes
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
- Contact:
Re: DirectX 11 render system - work-in-progress
FYI, nearly all nividia cards only goes up to 10.1, very few (only "fermi") does dx11...I am going to delete the d3d10 render system from the trunk - we don't need both d3d10 and d3d11 render systems - d3d11 covers d3d10 and gives more options.
- 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
d3d11 supports d3d9 and d3d10 hardware.
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
Assaf, I don't have a system that can use DX11, are render textures working right now?
- 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 don't think so.
Watch out for my OGRE related tweets here.
-
- Kobold
- Posts: 26
- Joined: Wed Mar 17, 2010 4:52 am
- Contact:
Re: DirectX 11 render system - work-in-progress
Maybe deleting it from the trunk would be a bad idea. DirectX 11 only works on Windows 7. You still need DX10 for Vista users.
Teknoman117 - a robot enthusiast
Just in case it helps anyone help me, my computer uses:
ATI Radeon HD 5770
AMD Athlon 64 X2
4 GB DDR 800 Ram
Ubuntu Linux 10.04 64 bit
Just in case it helps anyone help me, my computer uses:
ATI Radeon HD 5770
AMD Athlon 64 X2
4 GB DDR 800 Ram
Ubuntu Linux 10.04 64 bit
- calsmurf2904
- Orc
- Posts: 401
- Joined: Tue Sep 16, 2008 9:39 pm
- Location: Netherlands
Re: DirectX 11 render system - work-in-progress
http://gizmodo.com/5393053/directx-11-n ... dows-vistaTeknoman117 wrote:Maybe deleting it from the trunk would be a bad idea. DirectX 11 only works on Windows 7. You still need DX10 for Vista users.
Visit my blog at http://calsmurf2904.wordpress.com !
Got a Google Wave account? Add me as contact! (projectxgame <at> gmail <dot> com)
Got a Google Wave account? Add me as contact! (projectxgame <at> gmail <dot> com)
- 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, d3d11 is supported on Vista.
Watch out for my OGRE related tweets here.
-
- Hobgoblin
- Posts: 554
- Joined: Tue Nov 14, 2006 3:26 pm
- x 7
Re: DirectX 11 render system - work-in-progress
@Assaf
I wrote in this post (some time ago), that Geometry Shaders were not working properly. Here's a patch that fixes those problems. It also makes the IsoSurface example work with the hlsl code path in DX 11. (shaders included).
https://sourceforge.net/tracker/?func=d ... tid=302997
I wrote in this post (some time ago), that Geometry Shaders were not working properly. Here's a patch that fixes those problems. It also makes the IsoSurface example work with the hlsl code path in DX 11. (shaders included).
https://sourceforge.net/tracker/?func=d ... tid=302997
-
- Hobgoblin
- Posts: 554
- Joined: Tue Nov 14, 2006 3:26 pm
- x 7
Re: DirectX 11 render system - work-in-progress
@Assaf
I have added DX 11 stream out support and made it so that the ParticleGS sample now works with DX11 as well:
http://sourceforge.net/tracker/?func=de ... tid=302997
I think I am going to do more changes, so I will probably make a fork on bitbucket, instead of updating here.
I have added DX 11 stream out support and made it so that the ParticleGS sample now works with DX11 as well:
http://sourceforge.net/tracker/?func=de ... tid=302997
I think I am going to do more changes, so I will probably make a fork on bitbucket, instead of updating here.
- 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 as soon as I can.
Watch out for my OGRE related tweets here.
-
- Kobold
- Posts: 29
- Joined: Tue Dec 19, 2006 3:24 pm
- Location: germany
Re: DirectX 11 render system - work-in-progress
Hi there,
reading through the thread made me curious about the state of the DX11 render system in trunk. Is it already in a useable on a "DX9 feature-level"?
I wouldn't need Geometry or Hull-Shader Stages, just MRT (with MSAA) and the usual DX9 features.
Thanks alot!
regards,
stephan
reading through the thread made me curious about the state of the DX11 render system in trunk. Is it already in a useable on a "DX9 feature-level"?
I wouldn't need Geometry or Hull-Shader Stages, just MRT (with MSAA) and the usual DX9 features.
Thanks alot!
regards,
stephan
- 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
Well - there are still some unresolved issues with buffer updating issues and such, but - you can try out for yourself, you have all the code so if you get stuck try to solve the issue yourself. Also - you can always post and I will try to help.
Watch out for my OGRE related tweets here.
-
- Kobold
- Posts: 31
- Joined: Thu Jun 10, 2010 4:32 am
Re: DirectX 11 render system - work-in-progress
I was going through the dx11 code yest and superficially, it all seemed to be working... What are the specific issues that need to be resolved?
I observed that the current rendersystem abstraction doesnt map that well to dx10+ (or opengl).... theres the hardwarepixelbuffer class, which is far from the way textures are accessed in both underlying apis, and the new directx 10/11 rigidity seems to be getting more in the way.
And secondly, there is no way the current rs abstraction could be used to take advantage of the deferred contexts in dx11.... Whats the strategy on dealing with that?
I observed that the current rendersystem abstraction doesnt map that well to dx10+ (or opengl).... theres the hardwarepixelbuffer class, which is far from the way textures are accessed in both underlying apis, and the new directx 10/11 rigidity seems to be getting more in the way.
And secondly, there is no way the current rs abstraction could be used to take advantage of the deferred contexts in dx11.... Whats the strategy on dealing with that?
- 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
Well - if you want to see the problems - just try out the demos and see that some of them have issues.
Regarding dx11 features - well - we will be happy for any patch - I recommend discussing ideas in the forum before starting the work.
Regarding dx11 features - well - we will be happy for any patch - I recommend discussing ideas in the forum before starting the work.
Watch out for my OGRE related tweets here.
-
- Kobold
- Posts: 31
- Joined: Thu Jun 10, 2010 4:32 am
Re: DirectX 11 render system - work-in-progress
Well, we could use the deferred contexts internally to the rs, and let the user specify, for example, the number of threads they want. That would let us keep the current rs abstraction..... But I dont like that. That would be locking down the user to the internal threading architecture.
I want the rs to have an abstraction for something like a deferred context that the user can handle as he pleases. But then, that would need some api changes, and also, wouldnt work with the other rendersystems.
Any thoughts?
I want the rs to have an abstraction for something like a deferred context that the user can handle as he pleases. But then, that would need some api changes, and also, wouldnt work with the other rendersystems.
Any thoughts?