Pretending D3D video memory capabilities
Opened this issue · 1 comments
I got a case (here: https://sourceforge.net/p/dxwnd/discussion/general/thread/6d74dbdff0/?page=1#821c ) where a DirectShow movie rendering doesn't work unless we make some tricks. Someone noted that the rendering is good when the video adapter exposes some capabilities that are not present on the failed situations, in particular these:
D3DDEVCAPS_TEXTUREVIDEOMEMORY
D3DDEVCAPS_SEPARATETEXTUREMEMORIES
D3DDEVCAPS_PUREDEVICE
Now, assuming (but not for granted) that the problem is about the missing separated texture video memory, the question is: is there an easy way to try pretending to have these capabilities?
The implementation in the GetDeviceCaps wrapper is rather trivial, but once I pretend that these capabilities are present, how should I redirect a request for texture (separated) video memory to system memory and avoid a failure?
More in general, what do you think about the idea? Is it sound or are we just wasting our time?
Thanks.
p.s. the DirectShow rendering doesn't throw any error, it works but simply shows a light-blue screen and no errors are reaching the application interface level.
D3DDEVCAPS_TEXTUREVIDEOMEMORY
This should always be present for any 3D capable GPU, so I doubt any software even checks for it. Hardware that supports texturing directly from system memory probably never existed. Yes, integrated graphics may be technically using system RAM, but it's dedicated RAM that the drivers treat as video memory, so you still have to create textures in "video memory" (from DX point of view) as far as I know.
D3DDEVCAPS_SEPARATETEXTUREMEMORIES
D3DDEVCAPS_PUREDEVICE
It seems the meaning of the first flag changes depending on which docs and DX version you check, and the second one is not very descriptive in DX9, so I won't even try to guess what these are supposed to do. I never bothered with them.
More in general, what do you think about the idea? Is it sound or are we just wasting our time?
Sounds like a waste of time to me. That user may have one of those GPUs that use D3D9On12 unless they are using very recent drivers, so the problem may be with that. If he does have very recent drivers that uses igdumdim32.dll / igd9trinity32.dll instead, then that might be the culprit.
I doubt it has anything to do with those caps.