critical bugs in d3d surfaces sharing technology RRS feed

  • Question

  • Hi. I'm using surfaces sharing technology very actively and find that it have serious troubles with switchable graphics laptops. I tried official laptop drivers, and latest GPU drivers but issues still happens.
    These switchable graphics systems have 2 adapters installed. But all applications can see only 1 adapter. Drivers redirects all calls to one GPU or another depends from switchable graphics settings for specific application. Lets decide that iGPU means integrated GPU (power saving), dGPU - discrete GPU (high performance). Each application may stick to iGPU or dGPU. I trying to share surface between two applications and have following issues:
    1. NVidia Optimus technology (Intel HD + NVidia GPU) - iGPU to iGPU, dGPU to dGPU works, iGPU to dGPU, dGPU to iGPU does not work.
    2. AMD Enduro technology (Intel HD + AMD GPU) - iGPU to iGPU works, dGPU to dGPU, iGPU to dGPU, dGPU to iGPU does not work. So even inside same application I can not share surface if it runs on dGPU.
    3. Another AMD Enduro technology (AMD APU + AMD GPU) - iGPU to iGPU, dGPU to dGPU, dGPU to iGPU works, iGPU to dGPU does not work.

    "Does not work" means that OpenSharedResource returns S_OK but opened resource just black (or white). So if you try to copy it or render - you will get black (or white) and it is not possible to understand when surfaces sharing doesn't work. For example, CopyResource method do not return result value (void). So application "think" that everything fine, but user see black/white screen. So in my understanding OpenSharedResource must fail else surface sharing must work. It is ok to return E_FAIL. But it is not ok to return S_OK in case when resource can not be shared.
    Even if I want to work around this - I did not find working API that I can use to detect not working situations. It is a little bit tricky to collect all symptoms and develop detection code. I posted to AMD forum 1 year ago but no response yet.
    However, I'm sure that this is very critical bugs. Can Microsoft handle this situation somehow?
    Monday, April 21, 2014 9:07 AM

All replies

  • I can not find right forum to post. And since Microsoft certified drivers with critical issues I'm posting here.

    I tried to create post in Direct3D section of XBOX forums but I'm gettings UnhandledException 500 and can not create it. I tried to submit it to MS but it redirects to some home page in the end and I even can not submit. Crazy system that makes barriers for developers...

    Monday, April 21, 2014 9:14 AM
  • Hello,

    Did you ever find a solution to your problem?  We are experiencing a similar issue and looking for a solution.  Please let us know here if you found a workaround.

    Monday, November 24, 2014 8:40 PM
  • Sorry for late response. The only solution is to detect these systems and avoid using surface sharing technology. But it is a bit tricky. First of all, you must have equipment to test your solution on all systems, and then you must have many different hardware to avoid false detection (that we had sometimes).

    In ideal case this must be solved by driver developers and original post is some kind of complaint to MS regarding graphics hardware manufacturers, last chance. How they passed WHQL if they have issues like that? We already tried to contact NVidia and AMD but no luck.

    Friday, February 20, 2015 5:59 PM
  • We have the same problem. We use surface sharing to render video from DirectShow (which is D3D9 based) on to D3D11 textures. Some switchable graphics laptops work and some don't. Our latest purchase of an Alienware 15 laptop does not work. I think we will try working with AMD to see if they have any answers. I'll post again if I find anything out.
    Wednesday, March 25, 2015 10:48 PM