DirectX 11 - Status
by Lopuska · in Torque 3D Professional · 03/15/2014 (5:02 pm) · 118 replies
Hi All!
Ok, we have cleaned the entire DX9 Layer! thanks to all devs that help and support me.
Now we have a modern DirectX9 layer without fixed function and deprecated functionality.
I think that The DX9 layer was really unmodified since a long time (:
We can talk about DirectX 11...
Here you have DirectX 11 Status:
Note: at the moment there are no DX11 features, but just a port.
The goal is to have a working version of DirectX 11 so next, we can develop support for tipical nextgen features.
Contributors: Andrew Mac, ZeroFault
gfxD3D11CardProfiler - OK
gfxD3D11Cubemap - OK
gfxD3D11Device - OK
gfxD3D11EnumTranslate - OK
gfxD3D11IndexBuffer - OK
gfxD3D11OcclusionQuery - OK
gfxD3D11QueryFence - OK
gfxD3D11Shader - OK
gfxD3D11StateBlock - OK
gfxD3D11Target - OK
gfxD3D11TextureManager - OK
gfxD3D11TextureObject - OK
gfxD3D11VertexBuffer - OK
repository:
https://github.com/Lopuska/Torque3D/tree/D3D9_D3D11_R%26D
Ok, we have cleaned the entire DX9 Layer! thanks to all devs that help and support me.
Now we have a modern DirectX9 layer without fixed function and deprecated functionality.
I think that The DX9 layer was really unmodified since a long time (:
We can talk about DirectX 11...
Here you have DirectX 11 Status:
Note: at the moment there are no DX11 features, but just a port.
The goal is to have a working version of DirectX 11 so next, we can develop support for tipical nextgen features.
Contributors: Andrew Mac, ZeroFault
gfxD3D11CardProfiler - OK
gfxD3D11Cubemap - OK
gfxD3D11Device - OK
gfxD3D11EnumTranslate - OK
gfxD3D11IndexBuffer - OK
gfxD3D11OcclusionQuery - OK
gfxD3D11QueryFence - OK
gfxD3D11Shader - OK
gfxD3D11StateBlock - OK
gfxD3D11Target - OK
gfxD3D11TextureManager - OK
gfxD3D11TextureObject - OK
gfxD3D11VertexBuffer - OK
repository:
https://github.com/Lopuska/Torque3D/tree/D3D9_D3D11_R%26D
About the author
#2
If someone found some bugs or malfunctions, just email me! (:
03/15/2014 (5:12 pm)
DX9 Refactor should be ok. I've tested it a lot.If someone found some bugs or malfunctions, just email me! (:
#3
Thanks again so much!
Jeff
03/15/2014 (5:52 pm)
Anis, I can't thank you enough for taking out the time to do this. I will be testing it within the next week and letting you know if I have any issues.Thanks again so much!
Jeff
#4
It looks like you got about as far as I did when I was porting to DX11 a few months ago. Unfortunately, I wasn't able to continue because of how busy it got at work and didn't have enough time.
03/15/2014 (9:44 pm)
Great! Thanks a lot for this Anis. It looks like you got about as far as I did when I was porting to DX11 a few months ago. Unfortunately, I wasn't able to continue because of how busy it got at work and didn't have enough time.
#5
Impressive work with this. I hope you can work through all the issues with the DX11 port (I am seeing issues with the texture manager and the Texture Object sections). I am happy to say that the DX9c rework is STELLAR. I can now run my Conifer Forest Pack at 60+ FPS at true 1080p consistently. This is impressive because I worked my butt off trying to get a solid 30fps at (720p) 1280X720 back in the T3D 1.2 days. Also, my own efforts only yielded a minimal increase in FPS and MSPF.
Thanks for your efforts and I bow to your knowledge!
03/16/2014 (2:48 pm)
Anis, Impressive work with this. I hope you can work through all the issues with the DX11 port (I am seeing issues with the texture manager and the Texture Object sections). I am happy to say that the DX9c rework is STELLAR. I can now run my Conifer Forest Pack at 60+ FPS at true 1080p consistently. This is impressive because I worked my butt off trying to get a solid 30fps at (720p) 1280X720 back in the T3D 1.2 days. Also, my own efforts only yielded a minimal increase in FPS and MSPF.
Thanks for your efforts and I bow to your knowledge!
#6
I thought I'd have more time this weekend but life just keeps poppin up, but it spring break here in Indiana (columbus) so I'm looking to have some time here soon. Again great job!!!
03/16/2014 (3:12 pm)
I agree with Ron, thanks man! This really would be breathing some new life into the engine...I thought I'd have more time this weekend but life just keeps poppin up, but it spring break here in Indiana (columbus) so I'm looking to have some time here soon. Again great job!!!
#7
03/17/2014 (6:39 am)
Wouldn't it be nice if you could setup a donation button. I'll please (and I'm sure many others) supporting your work. Many thanks Anis!
#8
New updates for all :D
https://www.garagegames.com/community/forums/viewthread/136528
03/17/2014 (8:29 am)
Thank you all for your kind words! You give me the force to continue this work!! :DNew updates for all :D
https://www.garagegames.com/community/forums/viewthread/136528
#9
I'll get those latest changes up on the repos in a few hours.
Where should I begin in terms of development? I was going to start on XAudio 2.8 but you beat me to it :P so I started looking at the work that needs to be done in:
gfxD3D11TextureManager - TODO
gfxD3D11TextureObject - TODO
Should I work in this area? Or is there somewhere else I should focus my time?
03/17/2014 (11:00 am)
Hey Anis,I'll get those latest changes up on the repos in a few hours.
Where should I begin in terms of development? I was going to start on XAudio 2.8 but you beat me to it :P so I started looking at the work that needs to be done in:
gfxD3D11TextureManager - TODO
gfxD3D11TextureObject - TODO
Should I work in this area? Or is there somewhere else I should focus my time?
#10
03/17/2014 (11:23 am)
This is exciting news for the engine, DX11 support was something a lot of people have been asking for and this will definitely help to draw in some new faces I think, especially with the openGL & linux ports being done as well!
#11
So, for DX11 we have to map the texture to a D3D11_MAPPED_SUBRESOURCE using Map/Unmap through device context, make changes to pData within that structure, then unmapping it should return the results to the GPU. Sounds simple enough on paper. It even looks like GFXTextureObject and D3D11_MAPPED_SUBRESOURCE are very similar structures, so it shouldn't take much to replace the functionality.
Are there any flaws in my approach before I begin?
03/17/2014 (11:33 am)
I *think* I should be able to preserve the originally functionality of the GFXTextureObject while replacing its internals with D3D11 support. It seems the required functionality for the objects are the ability to lock/unlock which provides a pointer to an array of pixel values and a pitch for traversing it, and the ability to copy the contents to a GBitmap object. Let me know if I missed anything.So, for DX11 we have to map the texture to a D3D11_MAPPED_SUBRESOURCE using Map/Unmap through device context, make changes to pData within that structure, then unmapping it should return the results to the GPU. Sounds simple enough on paper. It even looks like GFXTextureObject and D3D11_MAPPED_SUBRESOURCE are very similar structures, so it shouldn't take much to replace the functionality.
Are there any flaws in my approach before I begin?
#12
But before start, I'm simplify the code of gfxD3D9TextureManager and gfxD3D9TextureObject. I'm introducing the automatic mipmap generation from device for all instead of using the mipmap generated by the artist (old solution used in 1995)!
I'm gonna make the same thing on gfxD3D9Cubemap....
DirectX11 and DirectX9 driver always generate mipmap automatically.
It's a totally waste of time to give manually the mipmap.
After that, the port will be easier!
I have tortoise GIT, so after that I can push my updates in the repo easily.
This is my github profile:
https://github.com/Lopuska
03/17/2014 (11:46 am)
Hi Andrew! Currently i'm not working here, you can help me here if you want :D thanks!But before start, I'm simplify the code of gfxD3D9TextureManager and gfxD3D9TextureObject. I'm introducing the automatic mipmap generation from device for all instead of using the mipmap generated by the artist (old solution used in 1995)!
I'm gonna make the same thing on gfxD3D9Cubemap....
DirectX11 and DirectX9 driver always generate mipmap automatically.
It's a totally waste of time to give manually the mipmap.
After that, the port will be easier!
I have tortoise GIT, so after that I can push my updates in the repo easily.
This is my github profile:
https://github.com/Lopuska
#13
One thing I overlooked in my proposed solution above is the the access rights for the texture. With D3D11 textures there's CPU access flags and Usage flags. For instance if the texture is known to be dynamic its handled differently than a texture that's never going to be updated by the CPU. There's many different combinations of options between the two flags and I imagine each are optimized for that situation.
I should be able to introduce these kinda of read/write access flags to the GFXTextureObject and still preserve original functionality ( I hope ) by having them ignored if they aren't required by the current graphics API. I'll also take a look at how OpenGL 4.0 handles these things so I can work on a solution that's not just DX-specific.
03/17/2014 (11:55 am)
I'll continue to research textures in the mean time to make sure we have the best approach.One thing I overlooked in my proposed solution above is the the access rights for the texture. With D3D11 textures there's CPU access flags and Usage flags. For instance if the texture is known to be dynamic its handled differently than a texture that's never going to be updated by the CPU. There's many different combinations of options between the two flags and I imagine each are optimized for that situation.
I should be able to introduce these kinda of read/write access flags to the GFXTextureObject and still preserve original functionality ( I hope ) by having them ignored if they aren't required by the current graphics API. I'll also take a look at how OpenGL 4.0 handles these things so I can work on a solution that's not just DX-specific.
#14
This branch is up to date with xaudio patch, a few fixes and missing pieces, and some work has been done on gfxD3D11TextureManager and gfxD3D11TextureObject.
03/17/2014 (5:30 pm)
github.com/andr3wmac/Torque3D/tree/d3d9-refactorThis branch is up to date with xaudio patch, a few fixes and missing pieces, and some work has been done on gfxD3D11TextureManager and gfxD3D11TextureObject.
#15
Good job on the work done with the TextureManager and TextureObject. However, I have a few suggestions.
For use of the context->Map method, you should only use it for Dynamic textures with that use the D3D11_USAGE_DYNAMIC flag. Everything else should use UpdateSubResource for performance reasons.
more information here D3D11_USAGE documentation
03/17/2014 (9:11 pm)
@AndrewGood job on the work done with the TextureManager and TextureObject. However, I have a few suggestions.
For use of the context->Map method, you should only use it for Dynamic textures with that use the D3D11_USAGE_DYNAMIC flag. Everything else should use UpdateSubResource for performance reasons.
more information here D3D11_USAGE documentation
#16
So in the case of a non-dynamic texture I get that UpdateSubResource would be used on unlock but am I still expected to provide the texel data on lock? Is that done with CopyResource or something? Maybe it's just late and I'm over-thinking this.
03/17/2014 (10:43 pm)
Please, keep the advise coming. I'm comfortable with DX9, but DX10/11 is new to me. No time like the present to learn though. I've been reading as much as I can about it for the past few days.So in the case of a non-dynamic texture I get that UpdateSubResource would be used on unlock but am I still expected to provide the texel data on lock? Is that done with CopyResource or something? Maybe it's just late and I'm over-thinking this.
#17
so basically
03/17/2014 (11:27 pm)
Yeah, sorry the UpdateSubResource would be used on the unlock method. For the lock function just create a temporary buffer so the texture data can be written and then sent to the card in the unlock method.so basically
TextureObject::lock()
{
if(isDynamic)
{
context->Map
mLockedRect.pBits = mapInfo.pData
}
else
{
//create temporary buffer
mLockedRect.pBits = tempBuffer
}
}
TextureObject::unlock()
{
if(isDynamic)
context->unmap
else
{
updateSubResource(mLockedRect.pBits)
//then delete temp buffer
}
}
#18
You guys should have a good chat with luis when the port is done and work out an updated GFX interface for nextgen features.
03/18/2014 (12:25 am)
Awesome work guys!You guys should have a good chat with luis when the port is done and work out an updated GFX interface for nextgen features.
#19
and running the generateAllproject...I got a fatal error: Class 'torquegenerator' not found in (path name)\tools\projectgenerator\modules\dsound.inc on line 26
Not sure why, did I miss something?
03/18/2014 (9:05 am)
OK off my first attempt (just downloading andrew's DX9 refactored branch)and running the generateAllproject...I got a fatal error: Class 'torquegenerator' not found in (path name)\tools\projectgenerator\modules\dsound.inc on line 26
Not sure why, did I miss something?
#20
03/18/2014 (9:29 am)
Oops, I must have copied it from another version that has the PHP5 bug fixed. I just pushed a working copy of dsound.inc, you could either download it or pull the changes. 
Torque Owner Kory Imaginism
innovative imaginations
Just to make sure would the DX 9 refactor be done first before starting this or could I dive right in?