Any way to identify the gpu a task ran on?

Yes, it would be nice if more information was available in the stderr output.  Some systems have different cards and I cant tell which card caused the problem.  

Some errors is easy such as "netbios time limit exceeded" which I suspect the card is too slow or whatever.

Other errors such as "printer is out of paper"  is really off the wall and no help at all.

Stderr output

<core_client_version>7.6.22</core_client_version>
<![CDATA[
<message>
The printer is out of paper.
 (0x1c) - exit code 28 (0x1c)
</message>
<stderr_txt>
f photon pairs

Other projects (yes, grass is always greener it seems) shows temperatures of each GPU which was useful and I had to add water cooling to one of my gpus to solve that problem.

Note that I am not asking for changes in code to do this.  Heaven forbid that I be sent the source and authorized to add these features.

The following comments are based on a (possibly faulty) recollection of what was explained (probably by Bernd) some years ago.  If you wanted to search through his posts, you could probably find what he actually said.  I think I've basically got the gist of it though.

GPU tasks, while crunching, do produce a fairly large stderr output that accumulates locally.  At the start of this output, it does indeed tell you exactly which GPU was being used. In the processing of current tasks, there are something like 1255 binary points to be analysed and the following output is recorded for each one of these binary points.  This example is the second last binary point (1254/1255) for one of my tasks.

% Binary point 1254/1255
% Starting semicoherent search over f0 and f1.
% nf1dots: 31 df1dot: 3.344368011e-15 f1dot_start: -1e-13 f1dot_band: 1e-13
% Filling array of photon pairs

Notice that there are 31 'nf1dots' to be processed for each binary point.  As each one is done, a '.' is output to the log.  So multiply all this output by 1255 and you can see the log file will be quite large.  I believe all of this does accumulate locally.

There is a limit to what BOINC will upload so not all of what accumulates is uploaded.  My recollection is the limit is ~64KB.  These files exceed that by quite a margin.  It used to be that the first 64KB was uploaded and the balance was lost.  Apparently the interesting bits are at the end so this was changed to allow the last 64KB to be uploaded with the initial information being lost.  If you look at what makes it to the website by clicking on the task ID link, you should see what I'm talking about.  So, unfortunately, the startup messages which identify the GPU are not going to be returned for tasks that 'go the distance' and accumulate the full stderr output.

So, while a task is processing and the header part is available locally, it would be possible to grab the GPU details.  There would be no reason why a user script couldn't be triggered say 30 secs after task start to extract the header information accumulating in the slot directory and so link a task name to a GPU device number.  I'm not suggesting you do this if you have a more convenient way (like using BoincTasks history for example) to get that information.  I'm just noting that it's possible to get the data automatically through a script if you really wanted to.