Closed GoogleCodeExporter closed 8 years ago
I'm not to sure what the problem is. Though lukas doesn't recommend the 10.2
drivers.
http://pyrit.wordpress.com/2010/02/21/ati-catalyst-10-2/ Perhaps you should try
with
the 10.1 drivers?
Original comment by adam.k...@gmail.com
on 28 Feb 2010 at 1:23
1. Please try downgrading to 10.1
2. Can you successfully run the SDK-examples? Not just HelloCL but also the more
complex ones like Mandelbrot
3. Please execute the following command in a shell and post the result
python -c "from cpyrit import _cpyrit_opencl; print [(i,
_cpyrit_opencl.OpenCLDevice(0,i).solve('bla',('blablabla',)*3)) for i in
xrange(_cpyrit_opencl.OpenCLPlatform(0).numDevices)]"
Original comment by lukas.l...@gmail.com
on 28 Feb 2010 at 3:04
1 When i use ATI 10.2 I can suuccessfully run all SDK-examples
2 The output of comand under ATI 10.2 is
[(0,
('\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x9
2\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c')),
(1,
('\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x9
2\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c')),
(2,
('\xc1\xed\xb1dJ\x93\xcb5sg0b\xfd\xc2\x8eO5\xef\xea*\x9c\xff\xc7I\xfc\x16\x14\x0
e\xe3\x8f\xa3\xa8',
'\x89XU"\xfa\xfb\xc7\x96\xda\x8c\xc5\xdd\xf4\xe5\xefG\xa4\xb5(B\xc2\x7f\xf6\xbc\
xb7\xe0\xfdg\r\x99v<',
'(h|L\xce\xceq\xd46#\xa2{\xcaq\xf7\xd7\xd7\xa0IT\xd1\r\xe4\x00\x1b(DCT\x18\xc1Q'
))]
3 Now I'll try to downgrade to ATI 10.1
Original comment by odl...@gmail.com
on 28 Feb 2010 at 3:35
I have downgrade to ATI 10.1 but
root@bt:~# pyrit
Segmentation fault
and all SDK-examples return in Segmentation fault
root@bt:/usr/local/opencl/samples/opencl/bin/x86# ./AESEncryptDecrypt
Encrypting Image ....
Input Image : input512.bmp
Key : 15 201 51 89 92 34 96 66 11 225 161 96 81 211 108 124
Segmentation fault
Original comment by odl...@gmail.com
on 28 Feb 2010 at 3:44
Device 0 is your CPU, Device 1 and Device 2 are the two GPUs. Like I expected:
The
second GPU is producing wrong results. There may be several reasons for that:
* A bug in Pyrit's OpenCL-code (unlikely, there is a *ton* of error checking)
* A bug in ATIs OpenCL-implementation (very likely, given ATIs history of
driver-quality)
* Your GPU is not working correctly (unlikely, but possible)
Please open /usr/lib/python2.5/site-packages/cpyrit/cpyrit.py, find line 375 and
change it as followed:
for dev_idx in range(p.numDevices):
should read
for dev_idx in range(p.numDevices)[:1]:
This will cause only the first GPU to be used. Please see if 'selftest' is
working
after that change. If it is, change the line to
for dev_idx in range(p.numDevices)[1:]:
This will cause only the second GPU to be used. Again, see if 'selftest' is
working.
If it is a bug in ATI's driver, we face a average of two months before ATI
recognizes
the problem...
Original comment by lukas.l...@gmail.com
on 28 Feb 2010 at 3:50
I'm not sure, that about this:
I have downgrade to ATI 10.1 but
root@bt:~# pyrit
Segmentation fault
I had the same on Ubuntu 9.10 - this is known ATI SDK bug with kernels newer
than
2.6.19 or so
by adding NOPAT to kernel boot string - eliminated segmentation fault in my case
try to google on that issue
Original comment by Vladimir...@gmail.com
on 28 Feb 2010 at 4:35
Now I'm trying with ATI 10.1
With nopat kernel boot option there's not Segmentation fault
I have edited /usr/lib/python2.5/site-packages/cpyrit/cpyrit.py, line 375 for
the
first GPU
for dev_idx in range(p.numDevices)[:1]:
this is the output of "pyrit selftest"
root@bt:/usr/local/opencl/samples/opencl/bin/x86# pyrit selftest
Pyrit 0.3.1-dev (svn r228) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Cores incorporated in the test:
#1: 'CPU-Core (SSE2)'
#2: 'CPU-Core (SSE2)'
#3: 'CPU-Core (SSE2)'
#4: 'CPU-Core (SSE2)'
#5: 'CPU-Core (SSE2)'
#6: 'CPU-Core (SSE2)'
#7: 'CPU-Core (SSE2)'
#8: 'CPU-Core (SSE2)'
Running selftest...
All results verified. Your installation seems OK.
The GPU's are no longer recognized.
But if I edit /usr/lib/python2.5/site-packages/cpyrit/cpyrit.py, line 375 for
the
second GPU
for dev_idx in range(p.numDevices)[1:]:
this is the output
root@bt:/usr/local/opencl/samples/opencl/bin/x86# pyrit selftest
Pyrit 0.3.1-dev (svn r228) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Cores incorporated in the test:
#1: 'OpenCL-Device 'Cypress''
#2: 'OpenCL-Device 'Cypress''
#3: 'CPU-Core (SSE2)'
#4: 'CPU-Core (SSE2)'
#5: 'CPU-Core (SSE2)'
#6: 'CPU-Core (SSE2)'
#7: 'CPU-Core (SSE2)'
#8: 'CPU-Core (SSE2)'
Running selftest...
Exception in thread Thread-2:
Traceback (most recent call last):
File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner
self.run()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 111, in run
self._testComputeFunction(101)
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 101, in
_testComputeFunction
raise ValueError("Test-vector does not result in correct PMK.")
ValueError: Test-vector does not result in correct PMK.
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner
self.run()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 108, in run
essid, pwlist = self.queue._gather(self.buffersize, timeout=0.5)
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 552, in _gather
self._check_cores()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 410, in _check_cores
raise SystemError("The core '%s' has died unexpectedly" % core)
SystemError: The core 'OpenCL-Device 'Cypress'' has died unexpectedly
Traceback (most recent call last):
File "/usr/bin/pyrit", line 6, in <module>
pyrit_cli.Pyrit_CLI().initFromArgv()
File "/usr/lib/python2.5/site-packages/pyrit_cli.py", line 106, in initFromArgv
func(self, **options)
File "/usr/lib/python2.5/site-packages/pyrit_cli.py", line 854, in selftest
cp.enqueue(essid, pws)
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 484, in enqueue
self._check_cores()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 410, in _check_cores
raise SystemError("The core '%s' has died unexpectedly" % core)
SystemError: The core 'OpenCL-Device 'Cypress'' has died unexpectedly
Now I'll try to revert to ATI 10.2,but I suspect that the result will be the
same
Original comment by odl...@gmail.com
on 28 Feb 2010 at 5:23
bawww, I didnt take account for the CPU-Device. It should read:
for dev_idx in range(p.numDevices)[:2]
and
for dev_idx in range(p.numDevices)[2:]
Original comment by lukas.l...@gmail.com
on 28 Feb 2010 at 5:28
ok
Now with for dev_idx in range(p.numDevices)[:2]
root@bt:~# pyrit selftest
Pyrit 0.3.1-dev (svn r228) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Cores incorporated in the test:
#1: 'OpenCL-Device 'Cypress''
#2: 'CPU-Core (SSE2)'
#3: 'CPU-Core (SSE2)'
#4: 'CPU-Core (SSE2)'
#5: 'CPU-Core (SSE2)'
#6: 'CPU-Core (SSE2)'
#7: 'CPU-Core (SSE2)'
#8: 'CPU-Core (SSE2)'
Running selftest...
All results verified. Your installation seems OK.
and with for dev_idx in range(p.numDevices)[2:]
oot@bt:~# pyrit selftest
Pyrit 0.3.1-dev (svn r228) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Cores incorporated in the test:
#1: 'OpenCL-Device 'Cypress''
#2: 'CPU-Core (SSE2)'
#3: 'CPU-Core (SSE2)'
#4: 'CPU-Core (SSE2)'
#5: 'CPU-Core (SSE2)'
#6: 'CPU-Core (SSE2)'
#7: 'CPU-Core (SSE2)'
#8: 'CPU-Core (SSE2)'
Running selftest...
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner
self.run()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 111, in run
self._testComputeFunction(101)
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 101, in
_testComputeFunction
raise ValueError("Test-vector does not result in correct PMK.")
ValueError: Test-vector does not result in correct PMK.
Exception in thread Thread-8:
Traceback (most recent call last):
File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner
self.run()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 108, in run
essid, pwlist = self.queue._gather(self.buffersize, timeout=0.5)
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 552, in _gather
self._check_cores()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 410, in _check_cores
raise SystemError("The core '%s' has died unexpectedly" % core)
SystemError: The core 'OpenCL-Device 'Cypress'' has died unexpectedly
Traceback (most recent call last):
File "/usr/bin/pyrit", line 6, in <module>
pyrit_cli.Pyrit_CLI().initFromArgv()
File "/usr/lib/python2.5/site-packages/pyrit_cli.py", line 106, in initFromArgv
func(self, **options)
File "/usr/lib/python2.5/site-packages/pyrit_cli.py", line 854, in selftest
cp.enqueue(essid, pws)
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 484, in enqueue
self._check_cores()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 410, in _check_cores
raise SystemError("The core '%s' has died unexpectedly" % core)
SystemError: The core 'OpenCL-Device 'Cypress'' has died unexpectedly
Original comment by odl...@gmail.com
on 28 Feb 2010 at 5:41
My card, Ati hd5970, is not crossfire but double GPU on single pcb...How can I
test
if the second GPU is fully functional?
Original comment by odl...@gmail.com
on 28 Feb 2010 at 5:48
Thanks for the information; this shows that the problem is the solely the
second GPU
and not interaction/multithreading. Is the result you posted above stable? Can
you
re-run the selftest with first or second GPU and get the same result?
For the moment, I suggest you stick with "for dev_idx in
range(p.numDevices)[:2]" so
only the first GPU is used. This is a workaround that gives you a working
version of
Pyrit. I'll see what ATI has to say about this.
The result of 'pyrit benchmark' on single-gpu would be of interest for me.
Original comment by lukas.l...@gmail.com
on 28 Feb 2010 at 5:51
I can confirm that the test results are stable
This is 'pyrit benchmark'
root@bt:~# pyrit benchmark
Pyrit 0.3.1-dev (svn r228) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Running benchmark (34770.9 PMKs/s)... -
Computed 34877.81 PMKs/s total.
#1: 'OpenCL-Device 'Cypress'': 30632.9 PMKs/s (RTT 1.9)
#2: 'CPU-Core (SSE2)': 463.6 PMKs/s (RTT 2.9)
#3: 'CPU-Core (SSE2)': 444.5 PMKs/s (RTT 2.9)
#4: 'CPU-Core (SSE2)': 470.1 PMKs/s (RTT 2.9)
#5: 'CPU-Core (SSE2)': 464.6 PMKs/s (RTT 2.8)
#6: 'CPU-Core (SSE2)': 437.5 PMKs/s (RTT 2.9)
#7: 'CPU-Core (SSE2)': 468.4 PMKs/s (RTT 3.1)
#8: 'CPU-Core (SSE2)': 435.0 PMKs/s (RTT 3.1)
Thanks for help
Original comment by odl...@gmail.com
on 28 Feb 2010 at 6:01
[deleted comment]
More information about this:
* I've dumped the .il and the .isa file that get generated for both GPUs on the
HD5970. They are identical.
* It takes a very long time on the second GPU for clFinish() to return (seval
seconds). It finally returns CL_SUCCESS (the call to clFinish() takes roughly a
few
milliseconds on the first GPU).
* CL_EVENT_COMMAND_EXECUTION_STATUS for clEnqueueNDRangeKernel() is always
CL_COMPLETE
* The kernel-output on the second GPU is always wrong, but always the same
every time
the kernel is called. It behaves regardless of the input (!).
Original comment by lukas.l...@gmail.com
on 28 Feb 2010 at 9:53
Maybe I need to disable internal CROSSFIRE ??
root@bt:/home/Sorgenti/pyrit/pyrit_svn/pyrit/test# aticonfig --lscc
Master adapter: 0. 06:00.0 ATI Radeon HD 5900 Series
Candidates: 1. 07:00.0 ATI Radeon HD 5900 Series
root@bt:/home/Sorgenti/pyrit/pyrit_svn/pyrit/test# aticonfig --lscs
Candidate Combination:
Master: 6:0:0
Slave: 7:0:0
CrossFire is enabled on current device
CrossFire Diagnostics:
There is CrossFire Side port connection between GPUs
CrossFire can work with P2P write through peer aperture
Dongle Capabilities: support PASSTHROUGH |INTERLINK_SW_AFR | INTERLINK_AUTO_AFR |
INTERLINK_BLACKING | INTERLINK_SUPERAA
root@bt:/home/Sorgenti/pyrit/pyrit_svn/pyrit/test# aticonfig --lsch
CrossFire chain for adapter 0, status: enabled
0. 06:00.0 ATI Radeon HD 5900 Series
1. 07:00.0 ATI Radeon HD 5900 Series
Original comment by odl...@gmail.com
on 1 Mar 2010 at 9:43
You can try this.
In any case, the second GPU should never return incorrect results without
indicating
an error-condition through the API.
Original comment by lukas.l...@gmail.com
on 1 Mar 2010 at 9:53
No success
Same error, same benchmark
Original comment by odl...@gmail.com
on 1 Mar 2010 at 10:30
- only to share my feeling -
Im following this issue with pain ("pain" is referred to me not to the issue).
Late in 2009, I choosed to wait Fermi, but now I hate the delay of NVIDIA with
Fermi
and his neverending sequence of fake announcements... ok, I say to me, I go with
ATI... but then I see this so-low-level-driver-quality in 9.12, 10.1, 10.2 ....
Bad
time, bad time we - the customers - are living...
Original comment by pyrit.lo...@gmail.com
on 2 Mar 2010 at 4:30
[deleted comment]
@odian3
(note: I talk related to *our* needs, I mean pyrit user viewpoint, not gamer
user
viewpoint.)
I dont know you are talking about HARDware or SOFTware developers, anyway:
about NVIDIA.
They said: "Fermi ready at end of 2009", then "Beginning of 2010", then "second
quarter of 2010". During this period they show fake Fermi card, and take the
attention up with "hype news" every week but it is just bla bla bla, smoke and
hype.
Result is: 6 months of delay in shipment Fermi card. NVIDIA official news
"advise"
future costomers to have a case ready to manage "a card that will be little
hotter
than usual": it means Fermi will be hot like hell. And last: they are working on
Fermi 2: it means: actual Fermi is a "beta" chipset, the right one will be
Fermi 2.
More, they "price politic" is VOLTURE: prices are SO high without have HIGH
performances. Have a looke ATI/NVIDIA similar card performances: there is a 100
Euro
average difference (ATI=XEURO, NVIDIA=(X+100)Euro).
My opinion: shame on you, NVIDIA.
about ATI.
ATI has chiper, colder and powerfull graphic cards then NVIDIA, but their
drivers are
*VERY* unusable: have a look the the post of lukas related 9.12, 10.1 and 10.2
ATI
drivers. The best card in the word has value=0 if drivers make her not usable.
My opinion: shame on you, ATI.
Anyway, my money are not fake, my money are not alpha version. So, as my money
are
good, I have right to ask for good hardware/software.
For the moment, I decided I will NOT buy ATI (till STABLE and USABLE drivers
will be
avaiable), I will NOT buy NVIDIA (till Fermi 2)
Original comment by pyrit.lo...@gmail.com
on 2 Mar 2010 at 8:03
please take discussions elsewhere
Original comment by lukas.l...@gmail.com
on 2 Mar 2010 at 8:08
ATI confirmed a problem on their side.
Original comment by lukas.l...@gmail.com
on 5 Mar 2010 at 7:01
Is it mean, that odlan3's 5970 card is OK and ATI again has a bug?
Original comment by Vladimir...@gmail.com
on 5 Mar 2010 at 11:15
Cpyrit Doesn't work with my HD 4870X2 too.
I tried also with two HD4870 and if i disable Crossfire the second card
disappears
and it will be unusable.
It is a problem of ATI or Cpyrit?
Original comment by mastertq...@gmail.com
on 18 Mar 2010 at 2:42
ATI. The driver is simply not working.
Original comment by lukas.l...@gmail.com
on 18 Mar 2010 at 6:25
anyone tried the 10.3 "preview" driver?
Original comment by lukas.l...@gmail.com
on 18 Mar 2010 at 5:11
I' m waiting for Linux version.
I will check as soon as the new drivers and you'll know
Original comment by odl...@gmail.com
on 18 Mar 2010 at 5:55
10.3 is out. Any news on the problem?
Original comment by lukas.l...@gmail.com
on 25 Mar 2010 at 3:22
I have started download now. Some minute and I'll tell you
Original comment by odl...@gmail.com
on 25 Mar 2010 at 5:27
I have to recompile pyrit ? If not I have the same error with Catalyst 10.3
pyrit selftest
yrit 0.3.1-dev (svn r237) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Cores incorporated in the test:
#1: 'OpenCL-Device 'Cypress''
#2: 'OpenCL-Device 'Cypress''
#3: 'CPU-Core (SSE2)'
#4: 'CPU-Core (SSE2)'
#5: 'CPU-Core (SSE2)'
#6: 'CPU-Core (SSE2)'
#7: 'CPU-Core (SSE2)'
#8: 'CPU-Core (SSE2)'
Running selftest...
Exception in thread Thread-2:
Traceback (most recent call last):
File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner
self.run()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 111, in run
self._testComputeFunction(101)
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 101, in
_testComputeFunction
raise ValueError("Test-vector does not result in correct PMK.")
ValueError: Test-vector does not result in correct PMK.
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner
self.run()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 108, in run
essid, pwlist = self.queue._gather(self.buffersize, timeout=0.5)
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 552, in _gather
self._check_cores()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 410, in _check_cores
raise SystemError("The core '%s' has died unexpectedly" % core)
SystemError: The core 'OpenCL-Device 'Cypress'' has died unexpectedly
Traceback (most recent call last):
File "/usr/bin/pyrit", line 6, in <module>
pyrit_cli.Pyrit_CLI().initFromArgv()
File "/usr/lib/python2.5/site-packages/pyrit_cli.py", line 110, in initFromArgv
func(self, **options)
File "/usr/lib/python2.5/site-packages/pyrit_cli.py", line 941, in selftest
cp.enqueue(essid, pws)
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 484, in enqueue
self._check_cores()
File "/usr/lib/python2.5/site-packages/cpyrit/cpyrit.py", line 410, in _check_cores
raise SystemError("The core '%s' has died unexpectedly" % core)
SystemError: The core 'OpenCL-Device 'Cypress'' has died unexpectedly
Original comment by odl...@gmail.com
on 25 Mar 2010 at 5:52
No, you don't. The OpenCL-code is compiled at run-time.
Please post the the result of the following command:
python -c "from cpyrit import _cpyrit_opencl; print [(i,
_cpyrit_opencl.OpenCLDevice(0,i).solve('bla',('blablabla',)*3)) for i in
xrange(_cpyrit_opencl.OpenCLPlatform(0).numDevices)]"
Original comment by lukas.l...@gmail.com
on 25 Mar 2010 at 5:56
This is the output
[(0,
('\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x9
2\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c')),
(1,
('\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x9
2\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c')),
(2,
('\x98x\x80\xeaZ\x8d\xb2\x91\x17\xdc5\x1d0\xf6\xe6^\xdf\x10&\x94\xcf\x08s\xad\xb
3\xbf\x85\xe2\xa6\\\x9c\xdc',
'\xefB\xd6\xa7aPp\x87r85x\x0e\x8d\xa4\xc6\x0c&\xa7A_]/\xad\xee\xce\xa8\xa6\xbcJ\
xf3:',
'\x80\xe5\xa4\x96J\x92\xd9\x8c\x0f\xed\xbe\x9fC+=?qLu\xb3\x87J\x0e\x01\xdb\xba\x
c3\xc9dG\xed\x05'))]
Original comment by odl...@gmail.com
on 25 Mar 2010 at 5:58
so the second gpu is still producing random, incorrect results. If ATI does not
provide a hotfix or a workaround in the meantime, you'll have to wait for 10.4
(in
april) and try again .....
Original comment by lukas.l...@gmail.com
on 25 Mar 2010 at 6:01
Thanks for support
Original comment by odl...@gmail.com
on 25 Mar 2010 at 6:31
odlan3,
Check out what worked for me over on the issue 137 thread (using 2 4850 cards,
which
wouldn't work in pyrit while crossfire'd). If you disable internal crossfire
and try
my setup, you may be able to use both cores before the next driver release (I'm
using
Cat 10.3).
BTW, I'm using the calpp version right now. I haven't tested it on OpenCL
(which also
didn't work crossfire'd) but the fix should work the same, as I stole it from a
thread about OpenCL. After reading what the 5000 series cards are benchmarking
at
under calpp (included in latest svn), you may want to switch to that. I'd try
my fix
with OpenCL first, since you're already set up for that. Good Luck!
Original comment by robert.b...@gmail.com
on 15 Apr 2010 at 3:51
Thanks....It works!!!!
pyrit benchmark
Pyrit 0.3.1-dev (svn r245) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Running benchmark (64930.3 PMKs/s)... /
Computed 68346.30 PMKs/s total.
#1: 'OpenCL-Device 'Cypress'': 32414.2 PMKs/s (RTT 1.9)
#2: 'OpenCL-Device 'Cypress'': 31876.3 PMKs/s (RTT 1.9)
#3: 'CPU-Core (SSE2)': 550.7 PMKs/s (RTT 2.9)
#4: 'CPU-Core (SSE2)': 565.4 PMKs/s (RTT 2.9)
#5: 'CPU-Core (SSE2)': 530.4 PMKs/s (RTT 3.1)
#6: 'CPU-Core (SSE2)': 536.3 PMKs/s (RTT 2.8)
#7: 'CPU-Core (SSE2)': 582.3 PMKs/s (RTT 2.8)
#8: 'CPU-Core (SSE2)': 533.4 PMKs/s (RTT 3.0)
Original comment by odl...@gmail.com
on 15 Apr 2010 at 7:25
The CAL-Core should give you even higher performance...
Original comment by lukas.l...@gmail.com
on 15 Apr 2010 at 7:32
I have same problem to compiling CAL-CORE
Original comment by odl...@gmail.com
on 15 Apr 2010 at 7:48
Attachments:
odlan3 please open a new issue for that
Original comment by lukas.l...@gmail.com
on 15 Apr 2010 at 7:57
I have impression that comment #51 in issue #148 solve issue #123 :)
Original comment by pyrit.lo...@gmail.com
on 18 Apr 2010 at 7:56
I keep this issue open until there is an official fix by ATI. The drivers still
produce random results without ANY error indication....
Original comment by lukas.l...@gmail.com
on 19 Apr 2010 at 6:45
I am guessing problem can be in xorg, BackTrack4 use xorg 7.4
I had segfault with BT4, so I wipe it out and go with debian.
I run:
- debian 5.0.4 stable on amd64
- xorg 7.3 from .deb package
- ATI driver 10.2 from ATI site
- ATI SDK 2.01 from ATI site
- python 2.6.4 from source tar.gz from python site, compiled and installed
- boost 1.42.0 from source tar.gz from boost site, compiled and installed
- pyrit with calpp-v2b-1 so as showed in issue #149.
hardware:
1 HD5770 on 1st PCI-X bus at x16
1 HD8770 on 3st PCI-X bus at x16
The system is up and running since saturday in neverending passthrough work, it
is
stable, no crach or dump or what else.
Hope this info can help.
Original comment by pyrit.lo...@gmail.com
on 19 Apr 2010 at 10:18
Hey,now is fixed using cpyrit_opencl
python -c "from cpyrit import _cpyrit_opencl; print [(i,
> _cpyrit_opencl.OpenCLDevice(0,i).solve('bla',('blablabla',)*3)) for i in
> xrange(_cpyrit_opencl.OpenCLPlatform(0).numDevices)]"
[(0,
('\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x9
2\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c')),
(1,
('\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x9
2\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c')),
(2,
('\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x9
2\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c',
'\xb8\xb7\xf5E^\xfe\xb1\x8b\xf5\x98\xce\x95z$%\xd4\x05\xdb4\xb6E\xeb\xf4\xfd\x92
\xf0\xa18\x18\xae\xaa\x1c'))]
This is what I have done
aticonfig --adapter=0 --cfd (remove any crossfire chains)
aticonfig --adapter=1 --cfd (remove any crossfire chains)
aticonfig --adapter=all --initial -f (create new xorg.conf)
export DISPLAY=:0
This whit ncpus-=2
pyrit benchmark
Pyrit 0.3.1-dev (svn r250) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Running benchmark (68003.6 PMKs/s)... |
Computed 68829.74 PMKs/s total.
#1: 'OpenCL-Device 'Cypress'': 33249.7 PMKs/s (RTT 1.8)
#2: 'OpenCL-Device 'Cypress'': 32210.5 PMKs/s (RTT 1.8)
#3: 'CPU-Core (SSE2)': 578.4 PMKs/s (RTT 2.8)
#4: 'CPU-Core (SSE2)': 573.1 PMKs/s (RTT 2.9)
#5: 'CPU-Core (SSE2)': 592.5 PMKs/s (RTT 3.2)
#6: 'CPU-Core (SSE2)': 614.2 PMKs/s (RTT 2.8)
#7: 'CPU-Core (SSE2)': 603.3 PMKs/s (RTT 2.9)
#8: 'CPU-Core (SSE2)': 628.9 PMKs/s (RTT 3.1)
This whit ncpus-=4
pyrit benchmark
Pyrit 0.3.1-dev (svn r250) (C) 2008-2010 Lukas Lueg http://pyrit.googlecode.com
This code is distributed under the GNU General Public License v3+
Running benchmark (73917.1 PMKs/s)... |
Computed 76168.07 PMKs/s total.
#1: 'OpenCL-Device 'Cypress'': 37503.7 PMKs/s (RTT 1.6)
#2: 'OpenCL-Device 'Cypress'': 35855.9 PMKs/s (RTT 1.7)
Anyway version of CAL++ seems to be more performant
Original comment by odl...@gmail.com
on 19 Apr 2010 at 11:01
Attachments:
I think this issue can be closed as well. I think the "garbage" output from the
second GPU was due to it being the secondary GPU in a crossfire setup. Once
odlan
de-crossfired his GPUs, his output was as it should be. The problem he had when
producing garbage output for GPU #2 was due to internal crossfire being enabled.
Also, when he disabled crossfire, the second GPU wasn't seen by pyrit. That got
fixed
in issue 137, so now everything works as it should. I don't see this as either a
driver or pyrit issue. AMD admits that Stream doesn't work under crossfire. And
the
only reason pyrit couldn't see the 2d GPU was because we had to change the
default
DISPLAY variable from :0.0 to :0, so all GPUs would be used on one screen.
Unless of course, you saw another issue in your testing that I'm just not
getting.
(Always a possibility).
Original comment by robert.b...@gmail.com
on 21 Apr 2010 at 12:56
@robert.bleach
I think you are right but last word is for the developpers
Thanks to lukas, hazeman11 and thank you robert for help
Original comment by odl...@gmail.com
on 21 Apr 2010 at 7:44
odlan,
Absolutely. Lukas gets the final word. It's his baby. I just don't want him
thinking
that there's a bug where there isn't. I'm sure he has enough on his plate as
is. It
appeared that the test results he got from your second GPU bothered him, and I
wasn't
sure if he realized that those bad results were from when you were crossfire'd.
Now
that you're de-crossfired, your results are coming up correct for both GPUs,
right?
And you're more than welcome for any help I've given. I wish I had lukas' or
hazeman's programming knowledge so I could contribute more. As it is, I just got
lucky finding the whole DISPLAY=:0 thing while scouring the ATI Stream SDK
forums. At
least I have tenacity working for me to make up for lack of programming skills.
;)
Bob
Original comment by robert.b...@gmail.com
on 22 Apr 2010 at 12:50
closed, bug in ati drivers. workarounds seem to exist.
Original comment by lukas.l...@gmail.com
on 17 Oct 2010 at 12:30
Original issue reported on code.google.com by
odl...@gmail.com
on 27 Feb 2010 at 11:33