I'm working on a project which uses the D2XX drivers from FTDI chip.
We are delivering the ftd2xx.dll file as part of our application. As far as I understand, the other files (e.g. ftdibus.sys) are installed on the system (at least for Windows) where the application runs. Linux is also a target for us, but let's ignore that for simplicity now.
My question is regarding the relation between these files? If, for example, I upgrade the ftd2xx.dll file delivered with our application, will users have to install the newest drivers? What if they do not?
In addition to the specific FTDI drivers, any general source of information on this area is also very welcome.
I used to work on a project that made use of FTDI's D2XX library.
There is no tight coupling between the exact version of ftd2xx.dll and ftdibus.sys. I believe the interface between ftd2xx.dll and the kernel mode driver is version independent at the basic feature level (at least since version 2.04.06 or so). There is even functions in the DLL to query DLL and driver versions respectively.
Thus, it can happen that they are 'out of sync'. I.e. ftd2xx.dll could be one from a more recent release than ftdibys.sys or vice versa. That is not a problem as such.
You are of course in complete control of the ftd2xx.dll version, but how does the driver package get installed? Is it installed as part of your application, or do you rely on the user obtaining the driver from another source? If your application has an installer, it could be an option to include FTDI's driver package in the installation. Thereby you will know which driver version is available.
What can be really tricky (and what has caused me headaches) is if there are other devices on the PC that use FTDI's chip. If such a device is supplied with media containing an older version of the driver and the user chooses to install this driver, it will simply overwrite any existing version of the driver (e.g. the version that your installer provided). This is a potential cause of regression, because FTDI has resolved a lot of bugs in the driver over the years.
If I were you, I would check the driver version at runtime and compare it to a version that is known to work (the version that you tested your application with). If the driver is older, suggest the user to upgrade it. Otherwise I would assume it is compatible.
Related
I have NVIDIA driver v 378.92 installed, and according to the nvidia website since driver version 377.14, driver supports vulkan api 1.0.42.1. My vulkan SDK api version is 1.0.42.2. However when I check for my device support info, using vkjson_info.exe in the vulkan SDK, there's stated that only apiVersion 1.0.37 is supported.
I'm a bit confused how this works, can anyone enlighten this?
The reported version could be limited by the Vulkan Loader/Runtime it finds. First is this Windows or Linux?
If you have the Vulkan SDK 1.0.42.2 installed, can you run the VIA tool? It should generate an HTML output. If you look at the "Runtimes" section, you should see which ones are available and which one it's using. For best results, try running it from the same folder as vkjson_info.exe. But, it should give you a good idea if you just run it anywhere.
"1.0.42.1" is not a Vulkan version. Vulkan only has three levels (i.e. major.minor.patch). So the "1.0.37" is likely correct and the "1.0.42.1" is likely the version of some LunarG Vulkan SDK or possibly Vulkan Runtime that comes with it.
There are usually several types of versions flying around:
The Vulkan driver version. It is of the major.minor.patch format and it is in VkPhysicalDeviceProperties::apiVersion or can be obtained by a tool such as VHCV.
Optionally SDK/Layers version on the runtime machine. LunarG Vulkan SDK versioning of the form vulkan_major.vulkan_minor.vulkan_patch.optionally_SDK_patch.
Vulkan Runtime of the runtime machine — It is basically The Vulkan Loader dll (if the application uses that). Both SDK and drivers install this (and coexist) and they use their own versioning scheme. The SDK version also installs the Validation Layers to the system.
SDK/Header on the application developer machine. Versioning as described above. The vulkan.h header is always 1.0 and so has only single number version — VK_HEADER_VERSION (which matches the Vulkan patch version — but does not have to in the future)
SDK/Header on the driver developer machine. Versioning as described above. Should really be the same as Vulkan driver version. And most likely the Vulkan RT installed by the driver will be the same version. But I think I have seen this to differ.
It should not matter, because all patch versions are supposed to be both-ways compatible (in reality not really — there were some changes, but driver makers seem to keep up so far providing updated drivers, so it is not an issue). And in fact that is the only thing I could find in the driver documentation: "Vulkan 1.0" support.
I hope you are so enlightened now that you reached the ultimate state of boredom.
377 is a beta version driver from https://developer.nvidia.com/vulkan-driver . There is no guarantee that beta feature will be carried over to the subsequent release version. And according to http://vulkan.gpuinfo.org/listreports.php it didn't (378 indeed have 1.0.37 and 377 have 1.0.42 and more importantly has the extensions you want to try). Continue to use the beta for now if you want the features within it. As for Layers and other SDK features you should not need newer drivers — in fact you should always use the latest to benefit from Validation Layer bugfixes and improvements.
I want to build a sample included in Vulkan SDK.
I downloaded the SDK from http://vulkan.lunarg.com and install it.
Then I opened the Visual Studio (I have a 2013 version), I open the solution from this path: (C:\VulkanSDK\1.0.13.0\Demos). I choose DEMOS.sln file. Then when I click on LocalWindowsDebugger this message pops up:
vkCreateInstance Failure:
vkEnumerateInstanceExtensionProperties failed to find the VK_KHR_surface extention.
Do you have a compatible Vulkan installable client driver (ICD) insatalled? Please look at the Getting Started guide for additional information.
I have never worked with vulkan, but as it named "Demo", I think that everything inside of it should be set in order to work.
I searched the web, but as it is new, there are few resources talked about it.
What is ICD? and how to install it? (is it different from installer of VulkanSDK?) OR this error is about completely different property? like setting properties of VisualStudio?
ICD is basically your GPU driver...
Both the SDK and driver install vulkaninfo app. Use it to determine what extensions you have and whatnot.
BTW Some time ago AMD drivers forgot to export the extensions like VK_KHR_surface. Make sure you are using the latest driver (16.5.2.1 on AMD and 365.19 on NVIDIA as of time of writing).
Also you need supported GPU. Consult:
NVIDIA supported GPUs
AMD supported GPUs
Khronos maintained list
BTW: All the demos work for me.
Do you have a compatible Vulkan installable client driver (ICD) installed?
This message tells you that Vulkan's loader wasn't able to find a Vulkan driver on your device. ICD is the installable client driver that comes with the driver of your graphics card.
What GPU are you using and do you have a driver installed that actually supports Vulkan? Note that while your card may support OpenGL it may not support Vulkan.
Check NVIDIA(performance mode) is selected at "Nvidia X Server Settings" application if you are using ubuntu.
We have a device that requires we install drivers before it's plugged in, otherwise we need to remove the drivers that Windows 8 and 10 automatically download.
How do we make a USB driver installer that can install correctly whether it's plugged in first or not?
On Windows 10, my simple driver for usbser.sys with just an INF file and a CAT file will automatically take precedence over Microsoft's usbser.inf that they supply in Windows 10. But if that doesn't happen for your particular driver/device, you might look into using DevCon, an open source utility from Microsoft that can be used to list devices and update their drivers. I have never used DevCon in an installer, but I think I have noticed other installers that use it. There is an MSYS2 package for DevCon.
We use DPinst which is a Driver Package installer program that Microsoft supply. It is quite flexible & straightforward to use & can give you a pretty standard wizard UI.
Question 1
If I want to build an application with OpenCL support, do I have any guarantees that the OpenCL.lib implementation from my vendor is able to work with all devices from other Vendors? If yes what's the difference between the implementation?
Question 2
Is it possible to use different OpenCL versions in the same application? For example AMD has released a preview driver for OpenCL 2.0 support. On the other hand the lovely company called Nvidia is still trying to ignore everything past OpenCL 1.1. It would be nice if I could write platform specific code in different versions.
1: On Windows, OpenCL.lib is a static wrapper around OpenCL.dll, which is the ICD loader, and exposes all of the available platforms. It is provided by Khronos and redistributed by the OpenCL platform vendors. So go ahead and link to it; it will work with whatever is installed (although if nothing is installed your application won't run because it can't find OpenCL.dll; this is solved other ways).
2: Yes. As long as the ICD loader is the latest, you can get at the newer API on newer platforms / devices. Just don't use new API on old devices; that will crash or worse.
Hi!
I have an old plugin (as binary, dll), used by my application. It was build for WM2003. And now it crashes the app, if loaded on Windows Mobile 6.1 (WM5 works fine, WM6 too).
The source code is not available and it's no more supported by developer. So I can't rebuild it for WM6.1.
Is it possible to patch or convert the binary to allow it to work on WM6.1 ? If so, how can I do this ?
Thank you.
Edit: I've found, that the problem is in PE loader, which acts not the same on WM6.1 (comparing with WM6 and earlier).
Does this plug-in use MFC or ATL? Earlier versions of WinMo had a different ATL/MFC version baked in, so MFC or ATL apps written in Studio will not work unless you deploy the newer ATL/MFC libraries along with the app, just as the old apps will not work on new devices unless you deploy the old MFC/ATL libraries.
This problem is rare, but some information can be found.
The common solution is to rebuild a binary in VS2008 (TCPMP new VS2008 builds for WM6.1), but this will not help, if you don't have the source code.
I've found the problem explanation and another solution in cegcc mailing list (arm-wince-cegcc on Windows Mobile 6.1). In Windows Mobile 6.1 Memory Management scheme was changes.
This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0. However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space.
In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot. Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks. ...
And the workaround for this issue is to declare the DLL in registry (to tell the OS not to load it in high memory).
I don't like this workaround, so I try to find some binary patcher. And found it :)
It's not really a patcher, it's UPX - the Ultimate Packer for eXecutables. But it solves the problem perfectly. The DLL, packed with UPX don't crashes the application and runs fine.