Folding Forum

So far the only related information released is that PG is aware of issues with lower end AMD-ATI cards as mentioned here - https://folding.stanford.edu/home/core1 ... d-of-life/. So far they have not announced anything further.

macdjord wrote:Is there any plans to change or fix this, then?
Also, if I'm not the only one having problems running Core_17 WUs on this model of GPU, maybe someone should change the master GPUs.txt file.

Are there any plans to fix the OpenCL driver from AMD? You would have to ask that on the AMD forum. This is a driver issue, not a fahcore issue. We don't typically recommend beta drivers, but please try the Cat 14 beta drivers. They seem to work better for some people according to initial reports, though no reports from 5xxxx series owners yet.

Yes, they could change the master GPU list. Unfortunately, the only two options are On or Off. I would hate to disable all 5x40 models if only some of them have trouble folding.

You're not the only one who has had trouble with Core_17 assignments on a HD 5xxx GPU. (I have not tried the new drivers yet.)

P5-133XL wrote:You can guaranty no Core_17 (p8900) by using v6 of the client.

Uhm, wasn't Core_16 retired last year, meaning wouldn't removing the GPU-slot from v7-client give the same result as downgrading to v6?

No, Core_15/16 projects still exist. It is Core_11 that is rare to non-existent. There are lots of Core_15 (Nvidia), far fewer Core_16 (AMD), and Core_11 is outright rare to non-existent. Eventually everything will undoubtedly move to Core_17 but I can't really say when that will be.

7im wrote:Are there any plans to fix the OpenCL driver from AMD? You would have to ask that on the AMD forum. This is a driver issue, not a fahcore issue. We don't typically recommend beta drivers, but please try the Cat 14 beta drivers. They seem to work better for some people according to initial reports, though no reports from 5xxxx series owners yet.

Everything else seems to be working fine; I'm not willing to deal with a beta driver just to get FAH going.

7im wrote:Yes, they could change the master GPU list. Unfortunately, the only two options are On or Off. I would hate to disable all 5x40 models if only some of them have trouble folding.

Er, I'm not sure we're on the same page here. I was under the impression that the GPU list identified which GPUs support which cores. Thus it should be possible to edit it to say that 5x40s support V6 but not V7. Since there are still plenty of V6 projects still active, everyone would still be able to contribute.

You're not the only one having trouble with the current drivers. They're the responsibility of ATI, not Stanford.

Yes, Stanford could permanently disable certain GPUs, but then they'd have to undo that process if (when?) ATI fixes the drivers. That's a bad idea, though, because nobody would be able to test a new set of drivers. You can disable the GPU slot.

macdjord wrote:...

7im wrote:Yes, they could change the master GPU list. Unfortunately, the only two options are On or Off. I would hate to disable all 5x40 models if only some of them have trouble folding.

Er, I'm not sure we're on the same page here. I was under the impression that the GPU list identified which GPUs support which cores. Thus it should be possible to edit it to say that 5x40s support V6 but not V7. Since there are still plenty of V6 projects still active, everyone would still be able to contribute.

The GPUs.txt tells if F@H supports the GPU or not (it doesn't know about v6 or V7). If the GPU is supported, the FAHClient sends the details of the GPU to the F@H Servers which decide what WU should be assigned to the GPU. I am not sure of how granular the controls are on the F@H Server but any changes to the Servers are kept to a minimum since an error could mean that a lot of donors might face unexpected issues.

As it has been stated elsewhere, FahCore_17 uses OpenCL 1.1 Industry Standard so it is up to the vendor to provide support to the customers. From what I have read, there are different "levels" of support for OpenCL and am not sure of what specific features FahCore_17 requires to fully function. If any of those features are missing, the results can be unexpected. For example, Apple has made some major updates to OpenCL and supports OpenCL 1.2. However, that level is still not sufficient for FahCore_17 to fully function (viewtopic.php?p=254970#p254970).

macdjord wrote:...

7im wrote:Yes, they could change the master GPU list. Unfortunately, the only two options are On or Off. I would hate to disable all 5x40 models if only some of them have trouble folding.

Er, I'm not sure we're on the same page here. I was under the impression that the GPU list identified which GPUs support which cores. Thus it should be possible to edit it to say that 5x40s support V6 but not V7. Since there are still plenty of V6 projects still active, everyone would still be able to contribute.

I help maintain the list. I can assure you, the options are Black or White (hence greylist). Off or On.

The only other 2 options are to define the GPU chip type. AMD or NV, and then the Chip family, like 5xxx or 7xxx series.

The GPUs.txt formatting info is posted here: https://fah-web.stanford.edu/projects/F ... tOfGPUsTxt

GPUs.txt consists of lines in the following format:

0xpci_vendor:0xpci_device:gpu_type:gpu_species:description

Where the fields have following meaning:

pci_vendor - The PCI vendor ID as four lowercase hexadecimal digits.
pci_device - The PCI device ID as four lowercase hexadecimal digits.

gpu_type
1 - ATI/AMD
2 - NVidia
0 or blank - Device not supported

gpu_species
ATI/AMD:
1 - R520 - No longer supported
2 - R600 - No longer supported
3 - R700 - No longer supported
4 - HD 5000-6000, FirePro V x800, V x900
5 - HD 7000-8000, FireStream 9000, Rx 2xx
NVidia:
1 - G80+ - Going End Of Life
2 - Fermi
3 - Kepler
4 - Maxwell (Not released, not supported yet)
0 or blank - Device not supported

A full example: 0x10de:0x0e22:2:2:GF104 [GeForce GTX 460]

codysluder wrote:You're not the only one having trouble with the current drivers. They're the responsibility of ATI, not Stanford.

Yes, and I'm not suggesting Stanford can or should be the one to fix the underlying problem. However, until the problem is fixed, I have a mostly-idle GPU which I wish to donate but cannot. If Stanford wishes to take advatage of that processing power - and the processing power of everybody else in a similar situation - they need to provide me with options to allow me to work around this problem. And if they don't think it's worth the effort, it's not me who loses out; I'm not doing this for points, I'm doing it because I want to help.
On that note, does anyone know of any other charitable distibuted computing efforts that can make use of a GPU? Preferably ones that are reasonably simple to install and play nice with FAH?

codysluder wrote:Yes, Stanford could permanently disable certain GPUs, but then they'd have to undo that process if (when?) ATI fixes the drivers.

I don't see why that would be a significant barrier. It's a single text configurations file; it's not like they'd need to do any coding or even publish a new version.

codysluder wrote:That's a bad idea, though, because nobody would be able to test a new set of drivers.

Then change it back when the new drivers comes out.

codysluder wrote:You can disable the GPU slot.

I have done so, until this problem is resolved.

7im wrote:I help maintain the list. I can assure you, the options are Black or White (hence greylist). Off or On.

The only other 2 options are to define the GPU chip type. AMD or NV, and then the Chip family, like 5xxx or 7xxx series.

The GPUs.txt formatting info is posted here: https://fah-web.stanford.edu/projects/F ... tOfGPUsTxt

Damn. Pity.

Hrm. There's already a mechanism to preferentially support research for a specific cause (cancer vs. Parkinson's vs. Huntinton's, etc.). How hard would it be to add a new 'cause' which contained only V6 projects?

One, the cause feature is not active yet, so you see even that is not easy to do. (Supported at client level, not yet supported at the server level)

Two, core 15 is not v6 only. Core types are not client specific. New features ARE client specific. Support for core 17 was a new feature in V7.

If you want core 15 only, the only option is to run a v6 GPU client. And then monitor it with HFM. It's very V7 like after that. v6 and V7 can run together without issue, until you get a GPU upgrade.

7im wrote:One, the cause feature is not active yet, so you see even that is not easy to do. (Supported at client level, not yet supported at the server level)

Two, core 15 is not v6 only. Core types are not client specific. New features ARE client specific. Support for core 17 was a new feature in V7.

If you want core 15 only, the only option is to run a v6 GPU client. And then monitor it with HFM. It's very V7 like after that. v6 and V7 can run together without issue, until you get a GPU upgrade.

Sorry, should have said 'a core 15 cause'. But if the feature isn't implemented, it doesn't matter. (Why is that option even there if it doesn't work yet?)

Which is your preference?

Disable that option in the client until the servers are updated. Then ask everyone to upgrade their client when the servers are ready.

Let everyone upgrade their client as convenient, even though the feature isn't active yet, and then when the servers are ready, it starts working without any user intervention.

Point taken. Still seems a bit disingenuous to add the option, to all appearances fully-functional, when it actually does nothing, but I suppose that's the best choice.
I suppose I'm just to used to the modern software lifecycle, where versions releases are frequent and incremental and updating is automatic.