Some cruncher made the observation that the general Win32 version (0.20_x87) has some severe performance issue on an AthlonXP (possibly also on other CPUs), even as it is faster than the 0.19_SSE variant on more recent ones (like Core2 or Phenom).

I've therefore added a 0.20_SSE version (compiled with Microsoft compiler, not the intel one as all the other), not showing this behavior. This may be useful for users of AthlonXPs (and maybe P3, if it is still in use).

The updated package is available here. Besides the new Win32_SSE version everything else is identical, no need to change anything for users the SSE2/3 or Win64 versions.

The updated package is available here. Besides the new Win32_SSE version everything else is identical, no need to change anything for users the SSE2/3 or Win64 versions.

The new Win32_SSE is also available on brilliantsite

---

The updated package is available here. Besides the new Win32_SSE version everything else is identical, no need to change anything for users the SSE2/3 or Win64 versions.

The new Win32_SSE is also available on brilliantsite

The full link for brilliantsite is www.brilliantsite.com/milkyway

---

I need help!

Vista 64bit, client 0.20, catalist 8.12 working fine.

Today try to upgrade catalist to version 9.9.

Install driver, rename aticalrt.dll, aticalcl.dll, aticaldd.dll to amdcalrt.dll, amdcalcl.dll, amdcaldd.dll (found them in system32 folder, aticalrt64.dll and other not found )

try to run boinc and got client error.

<core_client_version>6.10.3</core_client_version>
<![CDATA[
<message>
- exit code -1073741701 (0xc000007b)
</message>
]]>


What i am doing wrong?


On other host Windows 7 32bit
0.20 client, catalist 9.9 and renamed dll working fine.

Only difference is 32-64 bit OS.

Sound like you were in the SysWOW64 folder and not the System32 folder. You do not need to rename anything in the SysWOW64 folder. You should find aticalrt64.dll, aticalcl64.dll, aticaldd64.dll in the the System32 folder and they are the only files you need to copy and rename. Just rename the copies you still need the orginal files in there. I learned the hard way I rename the files in sysWOW64 folder with a previous version, but after reading the Readme txt several times I realized I was in the wrong folder. I'm using Windows 7 64 bit, but all 64 bit versions of windows should have those 2 folders. Good Luck

---

system32 and SysWOW64 is the same directory. And there is no 64bit version of dll.

system32 and SysWOW64 is the same directory. And there is no 64bit version of dll.

Just don't use a 32 bit filemanager!

Win64 mirrors the content of the SysWOW64 directory into system32 for all 32 bit programs. Be sure to use the explorer or use just the command line.

That so simple! thanks!

But after renaming new problem. One videocard is not install driver properly.
Second card working good.

CAL Runtime: 1.4.403
Found 2 CAL devices

Device 0: ATI Radeon HD 4800 (RV770) 512 MB local RAM (remote 1855 MB cached + 1855 MB uncached)
GPU core clock: 0 MHz, memory clock: 0 MHz
800 shader units organized in 10 SIMDs with 16 VLIW units (5-issue), wavefront size 64 threads
supporting double precision

Device 1: ATI Radeon HD 4800 (RV770) 512 MB local RAM (remote 1855 MB cached + 1855 MB uncached)
GPU core clock: 625 MHz, memory clock: 750 MHz
800 shader units organized in 10 SIMDs with 16 VLIW units (5-issue), wavefront size 64 threads
supporting double precision



And client is using cpu very much, and sluggish desktop.

Roll back to 8.12.

My site is updated as well with the new 0.20 builds for Windows.

Now we just have to wait for speedmic for new builds for Linux.

http://www.arkayn.us/milkyway/index.html

And we'll continue to wait it seems.

Hoping to see parity again soon! :-)

system32 and SysWOW64 is the same directory. And there is no 64bit version of dll.

Just don't use a 32 bit filemanager!

Win64 mirrors the content of the SysWOW64 directory into system32 for all 32 bit programs. Be sure to use the explorer or use just the command line.

I'm sorry CP, but the reality is a bit different: in short 64-bit DLL's are in the system32 directory, and 32-bit DLL's are in the SysWow64 directory. This is because redirector works on SysWOW64, while system natively works on system32 (it's a problem from the past, for compatibility reasons)

http://msdn.microsoft.com/en-us/library/aa384187(VS.85).aspx

system32 and SysWOW64 is the same directory. And there is no 64bit version of dll.

Just don't use a 32 bit filemanager!

Win64 mirrors the content of the SysWOW64 directory into system32 for all 32 bit programs. Be sure to use the explorer or use just the command line.

I'm sorry CP, but the reality is a bit different: in short 64-bit DLL's are in the system32 directory, and 32-bit DLL's are in the SysWow64 directory. This is because redirector works on SysWOW64, while system natively works on system32 (it's a problem from the past, for compatibility reasons)

You are sorry for what? That you misunderstood what I've written? ;)

I know how it works and I've correctly described what happens when someone is using a 32bit program to access the system32 directory. The WOW64 layer redirects all accesses by 32bit programs to system32 into the SysWOW64 directory. Effectively he sees SysWOW64 as system32 directory. That is the reason he didn't see the 64bit dlls as long as he used a 32bit file manager. He used another one and that problem was solved. Quite simple.

system32 and SysWOW64 is the same directory. And there is no 64bit version of dll.

Just don't use a 32 bit filemanager!

Win64 mirrors the content of the SysWOW64 directory into system32 for all 32 bit programs. Be sure to use the explorer or use just the command line.

I'm sorry CP, but the reality is a bit different: in short 64-bit DLL's are in the system32 directory, and 32-bit DLL's are in the SysWow64 directory. This is because redirector works on SysWOW64, while system natively works on system32 (it's a problem from the past, for compatibility reasons)

You are sorry for what? That you misunderstood what I've written? ;)

I know how it works and I've correctly described what happens when someone is using a 32bit program to access the system32 directory. The WOW64 layer redirects all accesses by 32bit programs to system32 into the SysWOW64 directory. Effectively he sees SysWOW64 as system32 directory. That is the reason he didn't see the 64bit dlls as long as he used a 32bit file manager. He used another one and that problem was solved. Quite simple.

yeah, I'm sorry that I misunderstood what you've written ... ooops!

see you guys go off line for the weekend and i figure ill update

to the latest drivers and such and look what yuns dun to me :P :P

having MAJOR issues with the .20 app and VPU recover with ATI....

i mean this is frakked,, cant do squat :( :(

amyone hav any idea's.... had Cat 9.9 installed figured id try 9.8

still no joy.... boinc 6.10.4 and its worked well with all others.

no oveclock on the cards being all ya have to do is pull the ATI CCC

up and BANG CRASH!!!!!!!!!!!!!!!

lol im good spirits and all just cant seem to get this figured out...

what da hell am i gona have to do to get this to work guys and gals????

i will look for the answer tomarro.... this machine can take a break for tonight.....

hassnt taken a day off in 2 years :P :P oh running a

ATI 4850 strapped to a AMD 9750 Quad core wit a 650w PS


any help you guys can provide can and will help me on the other machine

thats doing the EXACT SAME THING.....

---

I am running 6.10.3 with CAT 9.2 on both of my machines, no CCC installed on either one.

---

I'm having a problem getting one of my systems to run the latest (0.20) gpu version. It's running Vista (64bit), with an ATI 4890. I've done everything specified in the readme file, and checked twice!

All workunits terminate immediately with a computation error.

I've reset the project, and re-installed. Rebooted. Same result.

I've detached from the project, and re-installed. Rebooted. Same result.

I'm running BOINC 6.10.6 (although my first attempts to get this running were under 6.10.4) and ATI Catalyst drivers version 9.2

If I revert back to 0.19g then it works without problem.

I have another 64-bit system without an ATI card - this is running 0.20 without a problem. I also have a 32-bit system with an ATI card which is also running 0.20 without a problem. Both of these are also running under 6.10.6.

Anyone any ideas on how to get past this problem, please?

I'm having a problem getting one of my systems to run the latest (0.20) gpu version. It's running Vista (64bit), with an ATI 4890. I've done everything specified in the readme file, and checked twice!

All workunits terminate immediately with a computation error.

It's a bug in the CAL compiler (part of the driver) that was fixed in the latest Catalyst (and is not occuring with earlier Catalysts either). Update to 9.9 and you will be fine.


@all:
Everyone seeing errors with this output in the task details

CAL Runtime: 1.4.283
[..]
0, integration, Kernel Execution : Failed to create Program

can solve it by updating to Catalyst 9.9.

Not seeing any errors like that on my machines and they both run 9.2.

I cannot go past that due to some Alpha work I am doing.

---

I'm running BOINC 6.10.6 (although my first attempts to get this running were under 6.10.4) and ATI Catalyst drivers version 9.2

If the error is something about input/output files then it is 6.10.6 ... there is 6.10.7 out and I am running it now and it *MAY* have fixed that but I have not run it long enough to tell. For the moment it is looking good ... but it is too early to say for sure ...

Safer bet is still 6.10.3 ...

but 6.10.6 has a bug that CAN cause tasks to be trashed ...

also if you keep getting the VPU recover message i know its in the 9.8 and 9.9 drivers.

i had to revert back to the 8.12 so that the CCC wouldnt keep crashing Boinc.

now that im back on the 8.12 drivers everything is smooth as silk :) :)

---

By the way, there is some kind of a silent update of the 0.20 ATI app. Actually not the slightest change to the app itself was done (thats's why there's no version change), but the dependence on the MSVC runtime may have been removed.

Nothing needs to be done for the people already running the app. It only helps new users to experience one issue less. So one should use the new package for the 0.20 version from now on. It just contains other versions of the brook dlls. They are slightly larger, but shouldn't require the MSVC runtime to be installed to run.