Hi, > I've assumed until now that the device's vendor_id would match a given > vendor, i.e. one for AMD, one for NVidia, one for Intel, etc.
similar assumption here, but apparently not the case, cf. here for the same CPU on the Intel SDK vs. the AMD SDK: http://www.khronos.org/message_boards/showthread.php/7625-Detecting-same-device-on-different-platforms > Yesterday, I've realized that Toby and I didn't have the same vendor id > for our Intel integrated GPU. > I'm not sure of what the vendor id is supposed to represent, then. Looks like a unique identifier within each SDK. Not portable across SDKs... > For now, vendors are only used in the builtin database, but I'm > realizing that this is not useful, and that having vendor-specific > defaults is certainly a bad idea, sinc egenerations can greatly differ. Yep. > I'd rather go for mere generation-specific defaults. Should we just > throw away the vendor identification of the device, and focus on parsing > the name to identify the architecture and the device type? This boils down to the question of how reliable the device name is. I wouldn't bet my money on equal device names across different SDKs. On the other hand, the problem only persists on CPUs, as the only efficient (or at least sort-of...) OpenCL SDKs for the GPUs and accelerators are from the respective vendor. > Then, (CL_DEVICE_TYPE_GPU, haswell) would refer to the iGPU of haswell, > while (CL_DEVICE_TYPE_CPU, haswell) would refer to the CPU. That's not much different from how things are handled now, is it? The device type should be a stronger indicator than the device name... > Having > (CL_DEVICE_TYPE_GPU, haswell) on beignet or window's sdk wouldn't make > any difference from our point of view, and having (CL_DEVICE_TYPE_CPU, > haswell) on Intel's SDK or AMD's wouldn't make any difference either. Why should we treat them equally? I can well imagine that different compiler backends work differently, so I'd actually *expect* that the best performance on these SDKs is obtained with different configurations. For example, a LLVM-backend vs. a non-LLVM-backend is unlikely to behave similarly with such an SDK. > This would also prevent some headache when populating the database! Which headaches? I think if we treat all OpenCL SDKs equally, we will later have to refactor this because we will find differences among the SDKs... Best regards, Karli ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
