Hi
2014-07-20 11:45 GMT+02:00 Karl Rupp <r...@iue.tuwien.ac.at>:
> 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...
>
>
>
Unfortunately, this doesn't even seem to be the case! Toby and I both use
Beignet, but end up with a different Vendor ID...! I could also point to
this stackoverflow question:
http://stackoverflow.com/questions/8146056/how-to-programmatically-discover-specific-gpu-on-platform-with-multiple-gpus-op
According to what that person gets, we can't assume a one-to-one mapping
between vendor ids and platforms.
... Device ATI Radeon HD 5770[AMD]: vendorId[1021b00] ...
... Device ATI Radeon HD 5770[AMD]: vendorId[2021b00] ...
> 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.
>
>
Well, I would also expect that... but I would expect the worse performance
coming from mising optimizations (no automatic loop unrolling, no
auto-vectorization, etc...). My insight is that auto-tuning the same device
for two different SDKs is conceptually similar to auto-tuning the same
device for two versions of the same SDK. Now, do we also want to store the
platform version in the builtin database? We could, but it will certainly
involve a pretty complicated fallback mechanism, which will be practically
always used because of the fragmentation of the SDK versions.
>
> 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...
>
Well, populating the database will be much longer if we consider the
variations in the compiler (platform versions, sdks...). Just like we stick
to auto-tuning a routine for the latest SDK version of a vendor...
Well, the vendor_id key could still be replaced by a platform enum that
could be obtained by parsing the platform name + version...
This also means : do we want to run all our tuning procedures for Apple,
since it has its own SDK? If not, should we use a fallback for Apple. Which
one for the CPU? AMD? Intel? Which one for the iGPU? Beignet, Intel? Why?
Philippe
> 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
