This "issue" however is also present at other projects, so it seems to me more a BOINC problem than on project level.
____________
Greetings from TJ

Matt's GPUGrid app reads the GPU's, knows which GPU a WU is using and now reports this correctly in the stderr output file

Errors, omissions and bugs excepted, BOINC already reports considerable details of each GPU in a system - have a look at the internals of a sched_request.xml file sometime (the most recent one for each attached project is kept in the root of the BOINC Data directory until overwritten).

If the 6GB of the Titan is still not being detected properly, that might be a 32-bit glitch in the CUDA runtime support in the consumer-grade drivers. We had problems in some cases with Keplers too: BOINC can't afford to purchase samples of every high-end card, and Rom Walton solved that one by remoting in to my GTX 670 (a problem with the high word of a 64-bit variable passed 'by reference' not being initialised in the way Rom expected, IIRC). If you have test Titans in the lab that could be made available to Rom via remote access, that might help fix that bug.

The issue of multiple GPUs in a single host being shown as multiple instances of the best GPU is cosmetic: although full details are passed back, the BOINC database hasn't been adapted to store, and more importantly display, such fine-grained detail.

But I do think there's a fundamental design problem which is going to cause problems here. When a task is allocated to a volunteer's computer, the capability checking is done on the server: questions like "does the host have a >1 GB CUDA card", "does the host have a double-precision ATI card" can be addressed. But - under the present design - those task requirements are not passed back to the host and re-tested locally when the task is scheduled.

Thus, if a particular host has both a 1 GB card and a 768 MB card, there's no way of telling it (after allocation) not to run a 1 GB task on the 768 MB card. That whole problem of heterogeneous resources within a single host is going to require a major re-write, I think.

When a task is allocated to a volunteer's computer, the capability checking is done on the server: questions like "does the host have a >1 GB CUDA card", "does the host have a double-precision ATI card" can be addressed. But - under the present design - those task requirements are not passed back to the host and re-tested locally when the task is scheduled.

Thus, if a particular host has both a 1 GB card and a 768 MB card, there's no way of telling it (after allocation) not to run a 1 GB task on the 768 MB card.

When a task is allocated to a volunteer's computer, the capability checking is done on the server: questions like "does the host have a >1 GB CUDA card", "does the host have a double-precision ATI card" can be addressed. But - under the present design - those task requirements are not passed back to the host and re-tested locally when the task is scheduled.

Thus, if a particular host has both a 1 GB card and a 768 MB card, there's no way of telling it (after allocation) not to run a 1 GB task on the 768 MB card.

However for hosts with one NVidia GPU or multiple GPUs with similar amounts of memory it is currently possible to allocate appropriate sized tasks. Is that correct?