This is not good at all. "For some usages, e.g. mad(a, b, -a*b), the definition of mad() is loose enough that almost any result is allowed from mad() for some values of a and b". One wonders for which values of a and b is a*b + (-a*b) not equal to zero. Cheers, Mike
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
@Richard: I built a BRP4 Intel-GPU App Version 1.70 (beta). The OpenCL code is identical to the one used in BRP4, the CPU code is actually from current BRP7, but should be backwards-compatible (tested). The only difference compared to the previous 1.34 version should be the missing "-cl-mad-enable" option in the FFT code compilation. Please give it a try, my possibilities of testing a Windows app are currently pretty limited, in particular with an Intel GPU.
I see it. I'll try it on host 12496320, my HD 530 - that's the one where the first divergence in validation became significant, here and at SETI, and the one I used for my testing weekend with Raistmer. I'll let it run over the weekend, and we should have some idea of the validation outcomes by Monday. Give me 10 minutes to prep a preference set, and we're away.
But note: Raistmer found that the OCL FFT library was OK with -cl-mad-enable: it was his own SETI kernels that couldn't handle MAD. We may not be out of the woods yet
And we're off. But I seem to have got exclusively v1.22 FGRPB1G for the first fetch: I'll have to turn that off and try again (and my NVidia will have to lump it).
> Raistmer found that the OCL FFT library was OK with -cl-mad-enable: it was his own SETI kernels that couldn't handle MAD. We may not be out of the woods yet
The OpenCL FFT library that we are using is not "the clFFT" (originally from AMD, now on github). This is the only place where we actually use -cl-mad-enable in our App.
Regarding the driver limit: there probably was a reason for this. I'll have to make a new plan class for this app version. May take a bit.
Richard Haselgrove
)
Note: compare these links:
https://registry.khronos.org/OpenCL/sdk/1.2/docs/man/xhtml/mad.html
https://registry.khronos.org/OpenCL/sdk/1.0/docs/man/xhtml/clBuildProgram.html
8/11/2022 3:36:17 AM |
)
8/11/2022 3:36:17 AM | Einstein@Home | Scheduler request failed: HTTP internal server error
On all of mine the last few hours
Server must be busy
Reported in the 'Problems and
)
Reported in the 'Problems and Bug Reports' area. See reply from Gary.
Richard Haselgrove
)
Thanks, I see he posted that at the same time I was here
This is not good at
)
This is not good at all. "For some usages, e.g. mad(a, b, -a*b), the definition of mad() is loose enough that almost any result is allowed from mad() for some values of a and b". One wonders for which values of a and b is a*b + (-a*b) not equal to zero. Cheers, Mike
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
@Richard: I built a BRP4
)
@Richard: I built a BRP4 Intel-GPU App Version 1.70 (beta). The OpenCL code is identical to the one used in BRP4, the CPU code is actually from current BRP7, but should be backwards-compatible (tested). The only difference compared to the previous 1.34 version should be the missing "-cl-mad-enable" option in the FFT code compilation. Please give it a try, my possibilities of testing a Windows app are currently pretty limited, in particular with an Intel GPU.
BM
I see it. I'll try it on host
)
I see it. I'll try it on host 12496320, my HD 530 - that's the one where the first divergence in validation became significant, here and at SETI, and the one I used for my testing weekend with Raistmer. I'll let it run over the weekend, and we should have some idea of the validation outcomes by Monday. Give me 10 minutes to prep a preference set, and we're away.
But note: Raistmer found that the OCL FFT library was OK with -cl-mad-enable: it was his own SETI kernels that couldn't handle MAD. We may not be out of the woods yet
And we're off. But I seem to
)
And we're off. But I seem to have got exclusively v1.22 FGRPB1G for the first fetch: I'll have to turn that off and try again (and my NVidia will have to lump it).
Not quite working yet. Last
)
Not quite working yet. Last attempt got
We may have to adjust that driver limit, or do you want me to downgrade?
> Raistmer found that the OCL
)
> Raistmer found that the OCL FFT library was OK with -cl-mad-enable: it was his own SETI kernels that couldn't handle MAD. We may not be out of the woods yet
The OpenCL FFT library that we are using is not "the clFFT" (originally from AMD, now on github). This is the only place where we actually use -cl-mad-enable in our App.
Regarding the driver limit: there probably was a reason for this. I'll have to make a new plan class for this app version. May take a bit.
BM