@Pre-FERMI nVidia GPU users: Important warning

Message boards : Number crunching : @Pre-FERMI nVidia GPU users: Important warning
Message board moderation

To post messages, you must log in.

Previous · 1 . . . 9 · 10 · 11 · 12 · 13 · Next

AuthorMessage
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1650709 - Posted: 8 Mar 2015, 17:02:24 UTC - in response to Message 1650703.  
Last modified: 8 Mar 2015, 17:06:56 UTC

We're currently referring to the demos (with source code) at https://developer.nvidia.com/opencl


Yeah, sadly the old oclSimpleGL that demonstrates the technique (but doesn't do much) isn't there. The Ocean one isn't there either, and not in the SDKs I have currently installed, though oCLsimpleGL shows up in at least 3.2 and 4.

The Ocean one was removed from OpenCL prior to 3.2 and moved to DirectCompute compute shader demos (Microsoft). There was a huge kerfuffle at the time, because MS's big thing was the synchronisation being discussed here (DirectX/DirectCompute, which Cuda uses for its synchronisation underneath still), And OpenGL/OpenCLs was (and probably still is) faster.

Still, wouldn't solve issues here without different engineering.

[*Edit*]: note that as far as I can see, the particles demo doesn't use any kindof blocking synchronisation, so will spin the CPU at 100% as observed.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1650709 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1650710 - Posted: 8 Mar 2015, 17:06:02 UTC - in response to Message 1650705.  

I've been running test WUs with the previous build - both normally, and with _use_sleep.

Normal one was usable, and passed validation - so far so good.

With -use_sleep, screen lag was intolerable - especially during ap_18se08aa_B6_P1_00046_1LC25 and sigind_v5. I couldn't even reliably complete a drag'n'drop operation while those were running. And at one point, I got it to sleep for about half an hour:



After killing it, the next one ran normally - note the extra TpCallbackIndependent threads:

ID: 1650710 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1650714 - Posted: 8 Mar 2015, 17:14:04 UTC - in response to Message 1650710.  

Curious. Who's using Windows Kernel Threadpools ? The OpenCL DLL/Driver ?
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1650714 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1650718 - Posted: 8 Mar 2015, 17:18:51 UTC - in response to Message 1650714.  

Curious. Who's using Windows Kernel Threadpools ? The OpenCL DLL/Driver ?

Pass. Above my pay-grade :P
ID: 1650718 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1650723 - Posted: 8 Mar 2015, 17:28:38 UTC - in response to Message 1650718.  
Last modified: 8 Mar 2015, 17:34:14 UTC

Curious. Who's using Windows Kernel Threadpools ? The OpenCL DLL/Driver ?

Pass. Above my pay-grade :P


Well, either way, it changes a lot if you can enter an alertable wait instead of sleeping or using Cuda blocking syncs.

[Edit:] ROFL, so much for "impossible to leak kernel resources as boinc apps don't use them...." (highly paraphrased)
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1650723 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1650724 - Posted: 8 Mar 2015, 17:39:36 UTC - in response to Message 1650710.  

I couldn't even reliably complete a drag'n'drop operation while those were running. And at one point, I got it to sleep for about half an hour:

It's counterintuitive cause call to Sleep(1) would provide switching point for scheduler earlier than quantum passed, so should increase GUI responsibility, not to decrease it.
Check stderr if something unusual reported there for that task.
Anyway, better to follow pattern I described earlier for getting clear results.
Single task, 2 binaries, 3 sets of switches.
ID: 1650724 · Report as offensive
Josef W. Segur
Volunteer developer
Volunteer tester

Send message
Joined: 30 Oct 99
Posts: 4504
Credit: 1,414,761
RAC: 0
United States
Message 1650753 - Posted: 8 Mar 2015, 19:01:06 UTC - in response to Message 1650631.  

Any confirmation that new build works OK with 341.44 driver on pre-FERMI cards?

I'd say not.

try updated build: https://www.dropbox.com/s/v8g8a4la4j6osk5/AP7_win_x86_SSE2_OpenCL_NV_r2745.7z?dl=0

Thanks. That one looks much happier:
...
I'll run through the rest of the standard test set (having already generated reference results using Joe's (I think) AP7_win_x64_AVX_CPU_r2692 to save time). Any other specific cases that need checking?

Reading the conditional logic for a bad driver version from changeset 2867, it appears to me the rejection of 344+ has been lost.

if(driver_major_version_num>=340 && driver_major_version_num<341
   || (driver_minor_version_num<44 && driver_major_version_num==341)


The first line of that logically reduces to

if(driver_major_version_num==340

                                                                  Joe
ID: 1650753 · Report as offensive
Jacob Klein
Volunteer tester

Send message
Joined: 15 Apr 11
Posts: 149
Credit: 9,783,406
RAC: 9
United States
Message 1650767 - Posted: 8 Mar 2015, 19:28:12 UTC - in response to Message 1650753.  

Any confirmation that new build works OK with 341.44 driver on pre-FERMI cards?

I'd say not.

try updated build: https://www.dropbox.com/s/v8g8a4la4j6osk5/AP7_win_x86_SSE2_OpenCL_NV_r2745.7z?dl=0

Thanks. That one looks much happier:
...
I'll run through the rest of the standard test set (having already generated reference results using Joe's (I think) AP7_win_x64_AVX_CPU_r2692 to save time). Any other specific cases that need checking?

Reading the conditional logic for a bad driver version from changeset 2867, it appears to me the rejection of 344+ has been lost.

if(driver_major_version_num>=340 && driver_major_version_num<341
   || (driver_minor_version_num<44 && driver_major_version_num==341)


The first line of that logically reduces to

if(driver_major_version_num==340

                                                                  Joe


Sooo... Doesn't it say "340.xx or (341.xx less than 341.44)". Looks sorta correct to me.
ID: 1650767 · Report as offensive
Josef W. Segur
Volunteer developer
Volunteer tester

Send message
Joined: 30 Oct 99
Posts: 4504
Credit: 1,414,761
RAC: 0
United States
Message 1650784 - Posted: 8 Mar 2015, 20:07:22 UTC - in response to Message 1650767.  

Any confirmation that new build works OK with 341.44 driver on pre-FERMI cards?

I'd say not.

try updated build: https://www.dropbox.com/s/v8g8a4la4j6osk5/AP7_win_x86_SSE2_OpenCL_NV_r2745.7z?dl=0

Thanks. That one looks much happier:
...
I'll run through the rest of the standard test set (having already generated reference results using Joe's (I think) AP7_win_x64_AVX_CPU_r2692 to save time). Any other specific cases that need checking?

Reading the conditional logic for a bad driver version from changeset 2867, it appears to me the rejection of 344+ has been lost.

if(driver_major_version_num>=340 && driver_major_version_num<341
   || (driver_minor_version_num<44 && driver_major_version_num==341)


The first line of that logically reduces to

if(driver_major_version_num==340

                                                                  Joe


Sooo... Doesn't it say "340.xx or (341.xx less than 341.44)". Looks sorta correct to me.

I don't know if checking for 344+ drivers is needed, probably they wouldn't even install on a system which had only a pre-Fermi GPU. If nVidia has considered all possibilities, adding a pre-Fermi card as a secondary GPU may also be handled gracefully. I just wanted to point out that the original >= 340 did define everything higher as bad for pre-Fermi while the present logic says nothing at all about anything above 341.
                                                                  Joe
ID: 1650784 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1650791 - Posted: 8 Mar 2015, 20:13:02 UTC - in response to Message 1650784.  

Any confirmation that new build works OK with 341.44 driver on pre-FERMI cards?

I'd say not.

try updated build: https://www.dropbox.com/s/v8g8a4la4j6osk5/AP7_win_x86_SSE2_OpenCL_NV_r2745.7z?dl=0

Thanks. That one looks much happier:
...
I'll run through the rest of the standard test set (having already generated reference results using Joe's (I think) AP7_win_x64_AVX_CPU_r2692 to save time). Any other specific cases that need checking?

Reading the conditional logic for a bad driver version from changeset 2867, it appears to me the rejection of 344+ has been lost.

if(driver_major_version_num>=340 && driver_major_version_num<341
   || (driver_minor_version_num<44 && driver_major_version_num==341)


The first line of that logically reduces to

if(driver_major_version_num==340

                                                                  Joe


Sooo... Doesn't it say "340.xx or (341.xx less than 341.44)". Looks sorta correct to me.

I don't know if checking for 344+ drivers is needed, probably they wouldn't even install on a system which had only a pre-Fermi GPU. If nVidia has considered all possibilities, adding a pre-Fermi card as a secondary GPU may also be handled gracefully. I just wanted to point out that the original >= 340 did define everything higher as bad for pre-Fermi while the present logic says nothing at all about anything above 341.
                                                                  Joe

That's correct - 344(+) drivers won't install on legacy hardware. But that doesn't mean that we won't push them up incrementally to 342 and above before we've finished finding their bugs for them.

Has anybody got a copy of Clean20 they can point me to? I know I downloaded it from "the other thread" the year before last, but the machine I'm testing on has a sacrificial OS for testing BOINC installers - and I've wiped it since then.
ID: 1650791 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1650805 - Posted: 8 Mar 2015, 20:39:40 UTC - in response to Message 1650791.  

Has anybody got a copy of Clean20 they can point me to? I know I downloaded it from "the other thread" the year before last, but the machine I'm testing on has a sacrificial OS for testing BOINC installers - and I've wiped it since then.


GPU AP tuning: new set of test tasks for GPU AP

Claggy
ID: 1650805 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1650835 - Posted: 8 Mar 2015, 21:57:36 UTC

I suppose that if bug fixed in 341.44 it will not appear in higher versions.
At least probability is low enough to not ban version before it appears.
ID: 1650835 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1650852 - Posted: 8 Mar 2015, 23:08:19 UTC

I've also carried out a bench on my E8500/9800GTX+ host, it's first since these ones:

http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2195&postid=52381

AP7_win_x86_SSE2_OpenCL_NV_r2690.exe / single_pulses.wu :
AppName: AP7_win_x86_SSE2_OpenCL_NV_r2690.exe
AppArgs:
TaskName: single_pulses.wu
Started at : 02:47:33.960
Ended at : 02:48:18.975
44.955 secs Elapsed
40.888 secs CPU time
Speedup : 84.50%
Ratio : 6.45x

ref-astropulse_7.03_windows_intelx86__sse.exe-single_pulses.wu.res: <ap_signal>44,<pulses>34,<best_pulses>10
result-AP7_win_x86_SSE2_OpenCL_NV_r2690.exe-single_pulses.wu.res: <ap_signal>40,<pulses>30,<best_pulses>10
All Signals: Weakly similar or Different.
Pulses: pulse at signal 0 has no match (direction -->)
Weakly similar or Different.

Best Pulses: Weakly similar or Different.

-(.\testDatas\ref\ref-astropulse_7.03_windows_intelx86__sse.exe-single_pulses.wu.res)-
Reportable Single Pulses: 4 [Weak], 3 above threshold*THRESHOLD_FUDGE
Reportable Repeating Pulses: 30 [OK]
Single Pulses (Best): 10 [Weak], 3 above threshold*THRESHOLD_FUDGE

-(.\testDatas\result-AP7_win_x86_SSE2_OpenCL_NV_r2690.exe-single_pulses.wu.res)-
Reportable Single Pulses: 0 [Weak], 0 above threshold*THRESHOLD_FUDGE
Reportable Repeating Pulses: 30 [OK]
Single Pulses (Best): 0 [Weak], 0 above threshold*THRESHOLD_FUDGE



Thanks, that confirms what i found yesterday on my 9800GTX+ while running 340.52 drivers:


------------
AP7_win_x86_SSE2_OpenCL_NV_r2690.exe / single_pulses.wu :
AppName: AP7_win_x86_SSE2_OpenCL_NV_r2690.exe
AppArgs:
TaskName: single_pulses.wu
Started at : 21:11:50.241
Ended at : 21:12:58.708
68.413 secs Elapsed
69.623 secs CPU time
Speedup : 49.82%
Ratio : 1.99x

ref-astropulse_7.03_windows_intelx86__sse.exe-single_pulses.wu.res: <ap_signal>44,<pulses>34,<best_pulses>10
result-AP7_win_x86_SSE2_OpenCL_NV_r2690.exe-single_pulses.wu.res: <ap_signal>40,<pulses>30,<best_pulses>10
All Signals: Weakly similar or Different.
Pulses: pulse at signal 0 has no match (direction -->)
Weakly similar or Different.

Best Pulses: Weakly similar or Different.

-(.\testDatas\ref\ref-astropulse_7.03_windows_intelx86__sse.exe-single_pulses.wu.res)-
Reportable Single Pulses: 4 [Weak], 3 above threshold*THRESHOLD_FUDGE
Reportable Repeating Pulses: 30 [OK]
Single Pulses (Best): 10 [Weak], 3 above threshold*THRESHOLD_FUDGE

-(.\testDatas\result-AP7_win_x86_SSE2_OpenCL_NV_r2690.exe-single_pulses.wu.res)-
Reportable Single Pulses: 0 [Weak], 0 above threshold*THRESHOLD_FUDGE
Reportable Repeating Pulses: 30 [OK]
Single Pulses (Best): 0 [Weak], 0 above threshold*THRESHOLD_FUDGE



But is fine when running 337.50 Beta drivers:


------------
AP7_win_x86_SSE2_OpenCL_NV_r2690.exe / single_pulses.wu :
AppName: AP7_win_x86_SSE2_OpenCL_NV_r2690.exe
AppArgs:
TaskName: single_pulses.wu
Started at : 22:59:49.857
Ended at : 23:00:59.413
69.502 secs Elapsed
64.413 secs CPU time
Speedup : 53.58%
Ratio : 2.15x

ref-astropulse_7.03_windows_intelx86__sse.exe-single_pulses.wu.res: <ap_signal>44,<pulses>34,<best_pulses>10
result-AP7_win_x86_SSE2_OpenCL_NV_r2690.exe-single_pulses.wu.res: <ap_signal>44,<pulses>34,<best_pulses>10
All Signals: Weakly similar or Different.
Pulses: Checked 34, 34 , Strongly Similar
Best Pulses: Weakly similar or Different.

-(.\testDatas\ref\ref-astropulse_7.03_windows_intelx86__sse.exe-single_pulses.wu.res)-
Reportable Single Pulses: 4 [OK], 3 above threshold*THRESHOLD_FUDGE
Reportable Repeating Pulses: 30 [OK]
Single Pulses (Best): 10 [Weak], 3 above threshold*THRESHOLD_FUDGE

-(.\testDatas\result-AP7_win_x86_SSE2_OpenCL_NV_r2690.exe-single_pulses.wu.res)-
Reportable Single Pulses: 4 [OK], 3 above threshold*THRESHOLD_FUDGE
Reportable Repeating Pulses: 30 [OK]
Single Pulses (Best): 10 [Weak], 3 above threshold*THRESHOLD_FUDGE



The outcome of this is legacy GPUs (at a minimum) should avoid 340.52 drivers.


Now r2690 with 341.44 matches what was produced with 337.50 Beta drivers:

------------
AP7_win_x86_SSE2_OpenCL_NV_r2690.exe / single_pulses.wu :
AppName: AP7_win_x86_SSE2_OpenCL_NV_r2690.exe
AppArgs:
TaskName: single_pulses.wu
Started at : 19:00:32.112
Ended at : 19:01:08.133
35.962 secs Elapsed
31.855 secs CPU time
Speedup : 77.04%
Ratio : 4.36x

ref-astropulse_7.03_windows_intelx86__sse.exe-single_pulses.wu.res: <ap_signal>44,<pulses>34,<best_pulses>10
result-AP7_win_x86_SSE2_OpenCL_NV_r2690.exe-single_pulses.wu.res: <ap_signal>44,<pulses>34,<best_pulses>10
All Signals: Weakly similar or Different.
Pulses: Checked 34, 34 , Strongly Similar
Best Pulses: Weakly similar or Different.

-(.\testDatas\ref\ref-astropulse_7.03_windows_intelx86__sse.exe-single_pulses.wu.res)-
Reportable Single Pulses: 4 [OK], 3 above threshold*THRESHOLD_FUDGE
Reportable Repeating Pulses: 30 [OK]
Single Pulses (Best): 10 [Weak], 3 above threshold*THRESHOLD_FUDGE

-(.\testDatas\result-AP7_win_x86_SSE2_OpenCL_NV_r2690.exe-single_pulses.wu.res)-
Reportable Single Pulses: 4 [OK], 3 above threshold*THRESHOLD_FUDGE
Reportable Repeating Pulses: 30 [OK]
Single Pulses (Best): 10 [Weak], 3 above threshold*THRESHOLD_FUDGE


Claggy
ID: 1650852 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1650868 - Posted: 9 Mar 2015, 0:11:14 UTC

I repoted that fix works back to NV and closed bug report.
Awaiting info about sync/async bug status.
ID: 1650868 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1651027 - Posted: 9 Mar 2015, 14:24:36 UTC - in response to Message 1650705.  

Well, to re-test that sync/async issue this binary https://www.dropbox.com/s/nwtnomc5m6uhxen/AP7_win_x86_SSE2_OpenCL_NV_r2745_sleep_loop_shifted.exe.7z?dl=0 can be dropped along usual one into benchmark.
Then I propose to make 3 runs on let say Clean20 task:

1) both w/o switches - times should be comparable. If CPU usage inefficiency/bug presents both will take CPU ~ Elapsed time

2) both with -use_sleep option added. If bug under discussion is fixed times should be comparable again. And CPU should be lower than in 1). If bug still presents shifted sleep loop will be executed only when actual sync is complete hence will not save any CPU time. Hence, big difference in CPU times expected versus usual build.

3) -use_sleep -v 6 for both. In stderr will be clear info how many times sleeping loop executed for both variants.

Completed step (2)

WU : Clean_20LC.wu
AP7_win_x64_AVX_CPU_r2692.exe -verbose :
Elapsed 2504.127 secs
CPU 2488.232 secs
AP7_win_x86_SSE2_OpenCL_NV_r2745.exe -use_sleep -v 1 :
Elapsed 4333.024 secs, speedup: -73.04% ratio: 0.58x
CPU 85.333 secs, speedup: 96.57% ratio: 29.16x
AP7_win_x86_SSE2_OpenCL_NV_r2745_sleep_loop_shifted.exe -use_sleep -v 1 :
Elapsed 4337.615 secs, speedup: -73.22% ratio: 0.58x
CPU 3848.981 secs, speedup: -54.69% ratio: 0.65x

I don't think "sleep_loop_shifted" is viable - doesn't reduce lag, does consume CPU.

The step (1) numbers were

WU : Clean_20LC.wu
AP7_win_x64_AVX_CPU_r2692.exe -verbose :
Elapsed 2504.127 secs
CPU 2488.232 secs
AP7_win_x86_SSE2_OpenCL_NV_r2745.exe -v 1 :
Elapsed 4159.410 secs, speedup: -66.10% ratio: 0.60x
CPU 4127.693 secs, speedup: -65.89% ratio: 0.60x
AP7_win_x86_SSE2_OpenCL_NV_r2745_sleep_loop_shifted.exe -v 1 :
Elapsed 4152.606 secs, speedup: -65.83% ratio: 0.60x
CPU 4144.510 secs, speedup: -66.56% ratio: 0.60x

(as near identical as makes no difference)
ID: 1651027 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1651085 - Posted: 9 Mar 2015, 17:12:19 UTC - in response to Message 1651027.  

And for step (3)

WU : Clean_20LC.wu
AP7_win_x64_AVX_CPU_r2692.exe -verbose :
Elapsed 2504.127 secs
CPU 2488.232 secs
AP7_win_x86_SSE2_OpenCL_NV_r2745.exe -use_sleep -v 6 :
Elapsed 4386.918 secs, speedup: -75.19% ratio: 0.57x
CPU 75.489 secs, speedup: 96.97% ratio: 32.96x
AP7_win_x86_SSE2_OpenCL_NV_r2745_sleep_loop_shifted.exe -use_sleep -v 6 :
Elapsed 4338.256 secs, speedup: -73.24% ratio: 0.58x
CPU 3801.011 secs, speedup: -52.76% ratio: 0.65x

The basic r2745 mostly waited 2 iterations in SinglePulse find (before buffer read): 20 iterations in PC_inner_ffa (before buffer read). Sometimes more - the highest I've found is "Awaited 1219 iterations for completion" of an ffa. I may have been stress testing for screen lag at the time...

sleep_loop_shifted waited 1 iteration for both SinglePulse and ffa - never more, never less.
ID: 1651085 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1651110 - Posted: 9 Mar 2015, 18:49:40 UTC

So, bug still there.
ID: 1651110 · Report as offensive
Profile RottenMutt
Avatar

Send message
Joined: 15 Mar 01
Posts: 1011
Credit: 230,314,058
RAC: 0
United States
Message 1655558 - Posted: 21 Mar 2015, 21:58:02 UTC - in response to Message 1651110.  

So it isn't fixed?
don't upgrade to the latest drivers?
ID: 1655558 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1655560 - Posted: 21 Mar 2015, 22:01:05 UTC - in response to Message 1655558.  

So it isn't fixed?
don't upgrade to the latest drivers?

Bug about that this thread was started is fixed in 341.44.
Another bug wasn't but it exists in older drivers too.
ID: 1655560 · Report as offensive
Jacob Klein
Volunteer tester

Send message
Joined: 15 Apr 11
Posts: 149
Credit: 9,783,406
RAC: 9
United States
Message 1655634 - Posted: 22 Mar 2015, 2:13:23 UTC

So, maybe consider closing and locking the thread, since it is resolved, to prevent more confusion?
ID: 1655634 · Report as offensive
Previous · 1 . . . 9 · 10 · 11 · 12 · 13 · Next

Message boards : Number crunching : @Pre-FERMI nVidia GPU users: Important warning


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.