- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm calling mkl_custom.dll (ia32, cdecl, sequential, predefined lapack exports) from within a C# class library via PInvoke. Everything works fine so far.
As soon as my application also loads the managed DirectX dependencies (loaded from within Direct3D libraries) and creates some plots with them, calling MKL functions afterwards give strange results.
I tested and confirmed this reproducable for 'dsyevr' with jobz = 'V'. On return, the info parameter gives -6, which means "lda - parameter was wrong" - but it's not.
Running on WinXP, VS2005,
MKL 10.0.3.021, Manifest embedded into mkl_custom, reference to msvcr80.dll .
Microsoft.DirectX.dll - 5.4.0
Microsoft.DirectX.Direct3D.dll - 9.5.132
Microsoft.DirectX.Direct3DX.dll - 5.4.0
Any ideas? May be the runtime loaded by DX somehow conflicts with the one used by MKL?
BTW: the problem does not occour, if I FIRST load DirectX and MKL afterwards (first time only). But as soon as I load DX after having loaded MKL already, the MKL function gives wrong results again.
As soon as my application also loads the managed DirectX dependencies (loaded from within Direct3D libraries) and creates some plots with them, calling MKL functions afterwards give strange results.
I tested and confirmed this reproducable for 'dsyevr' with jobz = 'V'. On return, the info parameter gives -6, which means "lda - parameter was wrong" - but it's not.
Running on WinXP, VS2005,
MKL 10.0.3.021, Manifest embedded into mkl_custom, reference to msvcr80.dll .
Microsoft.DirectX.dll - 5.4.0
Microsoft.DirectX.Direct3D.dll - 9.5.132
Microsoft.DirectX.Direct3DX.dll - 5.4.0
Any ideas? May be the runtime loaded by DX somehow conflicts with the one used by MKL?
BTW: the problem does not occour, if I FIRST load DirectX and MKL afterwards (first time only). But as soon as I load DX after having loaded MKL already, the MKL function gives wrong results again.
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We found the solution: managed DirectX by default sets the FPU precision to float! This was causing the driver routine to fail. Dont know if this is a bug in Lapack or not. SYEVR is described to be a "relatively robust" method. IMO the driver should at least report a meaningfull errror - but it just gives the error from the failed internal routine for creation of eigenvectors, which reflects a wrong argument number (-6).
Anyway, after preventing DX to alter the precision, everything works as expected again.
Anyway, after preventing DX to alter the precision, everything works as expected again.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page