DirectX 11 render system - work-in-progress

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
User avatar
_tommo_
Gnoll
Posts: 677
Joined: Tue Sep 19, 2006 6:09 pm
x 5
Contact:

Re: DirectX 11 render system - work-in-progress

Post by _tommo_ »

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...
OverMindGames Blog
IndieVault.it: Il nuovo portale italiano su Game Dev & Indie Games
User avatar
sinbad
OGRE Retired Team Member
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

Post by sinbad »

The Usage enum is already a bitmask anyway so you can separate these things already.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: DirectX 11 render system - work-in-progress

Post by dark_sylinc »

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.
I've thought of that too, but there's something that is bugging me, which is async transfers.
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.
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 was thinking of the first too. That's why I wrote "moderate to hard" difficulty.
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).
User avatar
sinbad
OGRE Retired Team Member
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

Post by sinbad »

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.
iFire
Gnoblar
Posts: 24
Joined: Mon Sep 26, 2005 6:39 am
x 1

Re: DirectX 11 render system - work-in-progress

Post by iFire »

On hg head is SampleBrowser supposed to be corrupted for both dx10 and dx11?

Image

I'm using VS9, Windows 7 and an Ati HD5850.
User avatar
Assaf Raman
OGRE Team Member
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

Post by Assaf Raman »

No problem on my system - just got a fresh hg head - compiled and run.
Watch out for my OGRE related tweets here.
iFire
Gnoblar
Posts: 24
Joined: Mon Sep 26, 2005 6:39 am
x 1

Re: DirectX 11 render system - work-in-progress

Post by iFire »

Assaf Raman what is your system specification?
User avatar
Assaf Raman
OGRE Team Member
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

Post by Assaf Raman »

dell m1330 with an Nvidia geforce 8400.
Seems like a driver issue on your computer - ATI\AMD allways have driver issues.
Watch out for my OGRE related tweets here.
iFire
Gnoblar
Posts: 24
Joined: Mon Sep 26, 2005 6:39 am
x 1

Re: DirectX 11 render system - work-in-progress

Post by iFire »

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.
User avatar
Assaf Raman
OGRE Team Member
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

Post by Assaf Raman »

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.
Watch out for my OGRE related tweets here.
User avatar
tuan kuranes
OGRE Retired Moderator
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

Post by tuan kuranes »

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.
FYI, nearly all nividia cards only goes up to 10.1, very few (only "fermi") does dx11...
User avatar
Assaf Raman
OGRE Team Member
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

Post by Assaf Raman »

d3d11 supports d3d9 and d3d10 hardware.
Watch out for my OGRE related tweets here.
User avatar
masterfalcon
OGRE Team Member
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

Post by masterfalcon »

Assaf, I don't have a system that can use DX11, are render textures working right now?
User avatar
Assaf Raman
OGRE Team Member
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

Post by Assaf Raman »

I don't think so.
Watch out for my OGRE related tweets here.
Teknoman117
Kobold
Posts: 26
Joined: Wed Mar 17, 2010 4:52 am
Contact:

Re: DirectX 11 render system - work-in-progress

Post by Teknoman117 »

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
User avatar
calsmurf2904
Orc
Posts: 401
Joined: Tue Sep 16, 2008 9:39 pm
Location: Netherlands

Re: DirectX 11 render system - work-in-progress

Post by calsmurf2904 »

Teknoman117 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.
http://gizmodo.com/5393053/directx-11-n ... dows-vista
Visit my blog at http://calsmurf2904.wordpress.com !
Got a Google Wave account? Add me as contact! (projectxgame <at> gmail <dot> com)
Image
User avatar
Assaf Raman
OGRE Team Member
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

Post by Assaf Raman »

Yes, d3d11 is supported on Vista.
Watch out for my OGRE related tweets here.
psquare
Hobgoblin
Posts: 554
Joined: Tue Nov 14, 2006 3:26 pm
x 7

Re: DirectX 11 render system - work-in-progress

Post by psquare »

@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
psquare
Hobgoblin
Posts: 554
Joined: Tue Nov 14, 2006 3:26 pm
x 7

Re: DirectX 11 render system - work-in-progress

Post by psquare »

@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.
User avatar
Assaf Raman
OGRE Team Member
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

Post by Assaf Raman »

I will review as soon as I can.
Watch out for my OGRE related tweets here.
stephanh
Kobold
Posts: 29
Joined: Tue Dec 19, 2006 3:24 pm
Location: germany

Re: DirectX 11 render system - work-in-progress

Post by stephanh »

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
User avatar
Assaf Raman
OGRE Team Member
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

Post by Assaf Raman »

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.
debdatta_basu
Kobold
Posts: 31
Joined: Thu Jun 10, 2010 4:32 am

Re: DirectX 11 render system - work-in-progress

Post by debdatta_basu »

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?
User avatar
Assaf Raman
OGRE Team Member
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

Post by Assaf Raman »

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.
Watch out for my OGRE related tweets here.
debdatta_basu
Kobold
Posts: 31
Joined: Thu Jun 10, 2010 4:32 am

Re: DirectX 11 render system - work-in-progress

Post by debdatta_basu »

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?
Post Reply