Issue with clEnqueueAcquireD3D10ObjectsKHR

Issue with clEnqueueAcquireD3D10ObjectsKHR

Ritratto di Ian J.
Ian J.
Dom, 10/03/2013 - 14:36

I have written an application that shares textures between OpenCL and D3D10. I use OpenCL to write to a D3D texture and D3D to display it. The application executes well with one exception. I find that if I switch from windowed to full screen graphics using the latest HD4000 Win8 driver then the execution time for clEnqueueAcquireD3D10ObjectsKHR goes to over 2 seconds. When it finally completes it returns CL_SUCCESS. The application still executes correctly, but at a very slow speed (i.e. drops from >100 frames per second to approx. 0.5 frames per second). Performance does not recover if I switch back from full screen graphics.

The switch between windows and fullscreen works correctly without slowdown on PCs using either ATI or NVidia graphics hardware.

Is this a known issue? Unfortunately I'm not able to provide a small example for this issue.

O/S Windows 8 64bit, HD4000 driver version 15.28.12.64.2932, Intel SDK for OpenCL* Applications 2013 Beta

Thanks,

Ian

RSS In cima
7 post / 0 new
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di Chuck De Sylva (Intel)
Chuck De Sylva (Intel)
Lun, 11/03/2013 - 10:24

If you have an example of your code we could look at, that would better help us understand what is going on. Can you share it with us? So, to be clear, the slowdown occurs when you change to fullscreen, not when you start in fullscreen, correct?

In cima
Ritratto di Ian J.
Ian J.
Lun, 11/03/2013 - 12:03

Chuck

The basic model I follow is:

1. find OpenCL device that supports extension "cl_khr_d3d10_sharing"
2. Get device using clGetDeviceIDsFromD3D10KHR
3. Use clCreateContext to create context with CL_CONTEXT_D3D10_DEVICE_KHR
4. create texture using clCreateFromD3D10Texture2DKHR

In display loop

clEnqueueAcquireD3D10ObjectsKHR
clEnqueueNDRangeKernel
clEnqueueReleaseD3D10ObjectsKHR

DXGI automatically processes ALT-ENTER. In the corresponding WM_SIZE message I follow instructions as described by Microsoft at:

http://msdn.microsoft.com/en-us/library/windows/desktop/ee417025%28v=vs....

Note that the same code is invoked for a change in size of window (which works) as for when the display goes full screen (which does not). The code executes correctly on NVidia and AMD. Also I wrote a version which uses OpenCL and D3D, but does not use texture sharing. That switches to and from full screen correctly with the Intel driver.

The code I have is too large to share, however this evening I compiled the SimpleDX10 example from the AMD OpenCL SDK v2.8. I removed the call to clGetDeviceInfo with CL_DEVICE_DOUBLE_FP_CONFIG in line 690 of SDKCommon.cpp, rebuilt, and then ran with command line arguments so that it selected the Intel OpenCL platform (on my pc this was SimpleDX10.exe -p 0)
On my HD4000 system the frame rate was initially good (~350fps), after ALT-ENTER to move to full screen it exhibited the same issues as my code (update every 2 secs). The low frame rate remained after I switched back to windowed mode. No slowdown occured on a PC with an AMD graphics card when I switched to full screen. This indicates to me that it is either an issue in my HD4000 PC configuration, or an issue in the HD4000 driver. Hopefully you can use the SimpleDX10 code to see the results on your test systems.

Thanks,

Ian

In cima
Ritratto di Raghu Muthyalampalli (Intel)
Raghu Muthyalampalli (Intel)
Mer, 13/03/2013 - 16:09

Hi Ian,

We just tried the AMD sample on a driver and SDK verions later than what you have and got about 220 fps in windowed mode and ~170fps in full screen mode. Also when switching back to windowed mode, we got 220 fps.

On the other hand, Chuck tried it on his machine that had the AMD card removed but not the driver and he had trouble running the sample. Can you try uninstalling the ADM driver, remove the external gfx card and try the sample again? You may have to change the include and lib paths in visual studio and change the cl_context_properties to build the sample. Please report back your results.

Thanks,
Raghu

In cima
Ritratto di Ian J.
Ian J.
Gio, 14/03/2013 - 01:03

Raghu,

Many thanks for looking into this. Actually I am developing on two systems, the system that has HD4000 graphics does not have an AMD card installed, so I cannot remove it. However, you did prompt me to think about trying different HD4000 driver versions - and I have found a big difference.

I installed downloaded and installed the previous version 9.17.10.2875 from the Intel website (released 23rd October). With this driver the switch to full screen worked correctly, with no slow down. I then switched back to the latest released driver (9.17.10.2932, released 18th December) and the problem re-appeared. It therefore seems reasonable to assume that it is caused by a glitch in the 2932 drivers. Perhaps to confirm you could roll back the driver on your system to 2932 and retest? From your post it appears that the glitch may be fixed in the next driver release?

Thanks,

Ian

In cima
Ritratto di Chuck De Sylva (Intel)
Chuck De Sylva (Intel)
Gio, 14/03/2013 - 10:40

Ian,

We are using newer drivers, but I still saw the issue when the AMD driver was installed and the card wasn't even in the system. When I uninstalled the driver the issue went away. The first check for available devices appears to look at the registry or something, so it still shows AMD even though the card isn't even in the system. The last device check in the code worked as it should and only showed the Intel device.

- Chuck

In cima
Ritratto di Ian J.
Ian J.
Gio, 14/03/2013 - 13:12

Chuck,

That is good info for others that may see this issue in a system with both chipsets. However, there was no AMD driver or AMD card installed on the system I tested on; only Intel drivers and a HD4000. In this case my tests seem to indicate that it is specific to driver 2932, and is not present in 2875.

Cheers,

Ian

In cima

Accedere per lasciare un commento.