I use different GPUs (AMD and Nvidia) in my computers, but I've problems only with the detection of my AMD Radeon R9 290 (Sapphire Tri-X 290).

The BOINC client doesn't identify the card correct (it's a multi-gpu machine but the result is identical if only the AMD is installed):

10/06/2014 18:06:14 | | CUDA: NVIDIA GPU 0: GeForce GTX 780 (driver version 332.21, CUDA version 6.0, compute capability 3.5, 3072MB, 2938MB available, 4336 GFLOPS peak)
10/06/2014 18:06:14 | | OpenCL: NVIDIA GPU 0: GeForce GTX 780 (driver version 332.21, device version OpenCL 1.1 CUDA, 3072MB, 2938MB available, 4336 GFLOPS peak)
10/06/2014 18:06:14 | | OpenCL: AMD/ATI GPU 0: Hawaii (driver version 1445.5 (VM), device version OpenCL 1.2 AMD-APP (1445.5), 3072MB, 3072MB available, 3200 GFLOPS peak)
10/06/2014 18:06:14 | | OpenCL CPU: Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz (OpenCL driver vendor: Advanced Micro Devices, Inc., driver version 1445.5 (sse2,avx), device version OpenCL 1.2 AMD-APP (1445.5))

RAM size detection is wrong
Detected driver version is wrong

As a result projects show incorrect information for this host.

Example 1 (MilkyWay):
NVIDIA GeForce GTX 780 (3072MB) driver: 332.21 OpenCL: 1.01, AMD Hawaii (3072MB) OpenCL: 1.02

Example 2 (PrimeGrid):
NVIDIA GeForce GTX 780 (3072MB) driver: 33221, CAL Hawaii (3072MB)

Example 3 (Poem):
NVIDIA GeForce GTX 780 (3072MB) driver: 332.21 OpenCL: 1.01, AMD Hawaii (3072MB) OpenCL: 1.02

All these projects are unable to display a driver version. I do not get AMD GPU tasks from any of these projects.

The R290 is not so new that it's impossible to detect it correctly. Folding@home (just as an example) correctly detects and uses the R290.

Is the incorrect detection only a BOINC client issue? Or does it also require a server-side update for a correct detection?
Are there plans that BOINC will detect and use this GPU anytime in the future?

Regards

Is the incorrect detection only a BOINC client issue? Or does it also require a server-side update for a correct detection?
Are there plans that BOINC will detect and use this GPU anytime in the future?

The problem here is that your GPU no longer supports CAL, the old ATI method of doing calculations on the GPU. AMD has deprecated support for this on the newer videocards, so you don't show the line that shows the CAL detection (needed for for instance Primegrid).

BOINC uses the CAL detection method for detecting what kind of GPU it is, since this information is not in the OpenCL drivers. So you can understand that it has trouble properly detecting the GPU when all you have is the OpenCL driver. And thus, the driver version that you see is only OpenCL. It isn't CAL, so that makes it the correct driver version. BOINC does read that value directly from the OpenCL driver, so if you still think that's wrong, complain at AMD.

And lastly, the size of the memory. Well that may be a bug that I can forward to development, but for that I need the BOINC version you're using.

---

Thank you, Ageless.

The RAM size is incorrect on all client versions i tried in the past (the last were: 7.2.42 and 7.3.19).

The problem here is that your GPU no longer supports CAL, the old ATI method of doing calculations on the GPU. AMD has deprecated support for this on the newer videocards, so you don't show the line that shows the CAL detection (needed for for instance Primegrid).

BOINC uses the CAL detection method for detecting what kind of GPU it is, since this information is not in the OpenCL drivers.

That means BOINC is using an old-style detection that is useless with all new AMD processors (GPU & APU) that are OpenCL only?
OpenCL is more "standard" than the (propritary) CAL or CUDA. Shouldn't the develeopement go into this direction? I mean, beside CUDA or CAL OpenCL is supported on a increasing number of processors.

Does it mean, that projects that can use a R9 290 (eg. Collatz) must do the GPU detection in their own code because BOINC is unable to do it? This is a work-around but the complete wrong way in my opinion.

I checked past emails I had with the developers on this subject.
The new names like Hawaii, Caicos, Bonaire, Tahiti, etc. is what OpenCL is reporting that they are called. When the GPU does not support CAL it will not use the CAL naming schedule, as it is encoded into the client. Meaning that for CAL, there is code in the client, per case of AMD GPU that states what the name of that GPU is. Since we cannot use that same scheme for OpenCL, we use the names as OpenCL reports them.

Here's what's in the source code comments about this:
// AMD OpenCL does not recognize all AMD GPUs returned by
// CAL but we assume that OpenCL and CAL return devices in
// the same order.

// ATI/AMD OpenCL does not always recognize all GPUs returned by CAL.
// This is complicated for several reasons:
// * CAL returns only an enum (CALtargetEnum) for the GPU's family,
// not specific model information.
// * OpenCL returns only the GPU family name
// * Which GPUs support OpenCL varies with different versions of the
// AMD Catalyst drivers.
//
// To deal with this, we make some (probably imperfect) assumptions:
// * AMD drivers eliminate OpenCL support for older GPU families first.
// * Lower values of CALtargetEnum represent older GPU families.
// * All ATI/AMD GPUs reported by OpenCL are also reported by CAL (on
// systems where CAL is available) though the converse may not be true.

---