Moving on from DX9
#1
Now that Windows XP support seems to have finally been dropped. [3] It is might be a good idea to move away from DX9 and the use/need of the Jun10 DirectX SDK. The windows SDK now contains the DirectX headers and libraries.

Now I have tried to dig into to the code to see what makes use of the DirectX API, it's a lot. According to microsoft it would be mostly a search-replace effort. [2] The features implemented by d3dx9 will need to be replaced with other libraries [2]. For example DirectX Tool Kit or DirectXTex or custom libraries [2]. Or just try to refactor the functionality out of the project, but that would ask for some serious re-coding work in some places.

d3dx9.h is used in 8 places and the (still supported) d3d9.h in 14.

To start using the newer version of the provided headers in de Windows SDK I have already reversed the include and library paths on the project files. [1]

If anyone already started this effort or if there is no interest for this then please let me know, rather not go and try for nothing.

References:
[1] http://msdn.microsoft.com/en-us/library/...85%29.aspx (About the deprecation of older libraries and such an best practices in moving on)
[2] http://msdn.microsoft.com/en-us/library/...66870.aspx (The porting guide for apps but the directx part applies to kodi too)
[3] http://kodi.wiki/view/Windows


Note: I'm using a VS2013Ultimate (Yay for student licences) on a Windows 8.1 64-bit installation.
PS. Or of course go to OpenGL even for windows, no idea about the implications though.
Reply
#2
All I know no one started on it. Some looked at it but as you said it's a lot of work.
It would certainly be welcome to move to a higher version. Sadly at the moment we don't really have a dev with expertise in this area who has enough time to work on it.
If you need any pointers I'm sure some of our devs can help. Don't underestimate the work though for pulling this of Smile

You should always work against our master branch on github. Create enough commits/chunks in logical order to make work reviewable for others. Should you find small bugs in the process don't hesitate to share and fix them separate from the directx work.

Best of luck and looking forward to it.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#3
The problem with this the effort is that you can not really link to two versions of DirectX, at least not to my knowledge, for this project. It need to be an all in one conversion. And there doesn't seem to be any real graphics API abstraction in the code base (the headers are referenced in multiple subprojects and stuff like this)

If anyone has any pointers to maybe old DX8 code/leftovers that would be really appreciated, because that is the first thing that needs to be done.

Also might be a great resource: [4] http://blogs.msdn.com/b/chuckw/archive/2...-d3dx.aspx
Reply
#4
opengl was in there and dropped - don't readd it Wink
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#5
Was there a specific reason not to use OpenGL? It's not like I'm an OpenGl fanboy, the only GL programming I did was some basic 3D stuff, but just wondering.
Reply
#6
broken and not maintained Smile
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#7
OpenGL is pointless on Windows because we need DXVA accelerated video decoding
Reply
#8
I've thought about this and the issue I found is that the dxva code is dx9 and uses the dx9 interfaces, I didn't find a way to use dxva/2/hd with dx10(vista). I'm not a DirectX expert so I may be wrong but this is the issue I found at least.
Reply
#9
my windows knowledge is pretty nonexistent but i do recall some fuzz about a DX11 video api replacing dxva ?
Reply
#10
Please remember that older graphics controllers from AMD/ATI, Intel, and Nvidia probably also only supports DX9 drivers.

If you force the use of DX10 or higher then you may also change the minimum hardware requirements too, all dependent on how the backwards compatibility features used.

Nvidia GeForce 8000-series was for example the first GPU to fully support DX10, and Windows Vista the first OS.
Reply
#11
Is this what you were thinking about http://msdn.microsoft.com/en-us/library/...85%29.aspx ? Dome docs mention dx11 but, we need dx10 though and according to the link the api didn't really get any good until W7. It would also be a complete rewrite, not a bit of search and replace.
Reply
#12
@trem sorta. mmf (wasnt that wmf before?) is built on top of the dx11 video api. i don't remember much more details, it was a slashdot or the likes article years ago..
Reply
#13
I think I misunderstood the intent of this post, I thought you meant moving to dx11 but re-reading the post you seem to talk about staying with dx9 but porting the deprecated functions to drop the old Sdk dependency? This seems a lot more like a doable task.
Reply
#14
You can actually build it using the DX11 SDK (Windows SDK) but have the DX9 (eg. 9_3) feature set. The big improvement that gives is the abandonment of the DirectX SDK (less build deps) and thus the use of newer (hopefully better) SDKs. And the opportunity to, later, implement fancier newer features. The thing is you do need to change the video devices definition and most of all initialization. Something with the last parameter being dropped in DX11 because the driver will figure the best option out by it self. The DX11 seems friendlier to me than the DX9 API, at least more "clean" in a sense.

Windows/Microsoft Media Foundation has something to do with the DirectShow plugins/codecs. I have written an MS Media Foundation app to display GIFs (animated), when I wanted to add webm play I just had to install a codec pack (DirectShow codec for webm). And seeing as kodi has it's own player/codecs on board, I don't think that would be the route that the project needs to take.

The ID3D11VideoDevice/ID3D11VideoContext requires at least feature level 9_3 on windows 7 and of windows 8 it just works. The problem for me in implementing that. The DVXA code is already "pretty magic" to me.

I now have a non-building mess because apparently D3D_FORMAT no longer exists. There are more than one now missing data structures, that didn't even have a 9 in the name. MS's docs on these "differences" are sparse to say the least.

The time I have is not enough to do it quickly. So later more.. I guess.

Quote:I think I misunderstood the intent of this post, I thought you meant moving to dx11 but re-reading the post you seem to talk about staying with dx9 but porting the deprecated functions to drop the old Sdk dependency? This seems a lot more like a doable task.

That would also be an option. Then all d3dx9.h functionality would need to be ported and made dx11 ready. Eventually we will have to move to dx11 anyway and it's mostly backwards compatible with older hardware until you up the feature level.

EDIT: http://stackoverflow.com/questions/19846...-and-windo The accepted anwser has some nice info, but also as soon as they start talking about separate frames handling I feel out of my comfort zone. That is the part that also is performance critical. But as stated in the post we might be able to get the basic code elsewhere..
Reply
#15
For video decoding we need to stay with DXVA until FFmpeg supports D3D11 video decoding.
The sooner we start with moving away from the old SDK the better it is. Work on this is highly appreciated.
Reply

Logout Mark Read Team Forum Stats Members Help
Moving on from DX90