if you could, it'd be extremely helpful to add a flag to the program to simply ignore the memory size checking and create the pad on the GPU anyway (for some reason, cgminer is only reporting that my video cards have 512mb of memory when they have 3gb. I don't know why this is) It will set it to whatever you choose regardless if it can instead of what it detects as the maximum. The reported size is just the reported max size allocatable by opencl, it is NOT the gpu ramsize. I already said that it will try to set it to what you set it to. It fails, and we are back to my original response - I have no idea why it fails, but that is the response to the command asking for that much memory. Is that something you need to get and store with clGetDeviceInfo? Are you sure that that's not just the max default allocatable size for OpenCL? From http://www.khronos.org/registry/cl/specs/opencl-1.x-latest.pdf#page=52 : CL_INVALID_BUFFER_SIZE returned if size is 0 or is greater than
CL_DEVICE_MAX_MEM_ALLOC_SIZE value specified in table 4.3 for all devices in
context. CL_DEVICE_MAX_MEM_ALLOC_SIZE specifications CL_DEVICE_MAX_MEM_ALLOC_SIZE (cl_ulong) Max size of memory object allocation in bytes. The minimum value is max (1/4th of CL_DEVICE_GLOBAL_MEM_SIZE, 128*1024*1024) ulong is a huge integer, it should be able to be set higher than 512MB |
|
|
|
high HW values are normal? also utility is very low! i haven't found yet correct ltc settings for 79xx cards. changing to btc  yeah, i realized it after posting. still broken. |
|
|
|
|
edit: false alarm, i didn't look at the hw error rate. again, same problem as before, can not use appropriately sized buffers.
|
|
|
|
You should be able to easily replicate this just by setting --thread-concurrency 12288 (which works fine on reaper). I'm pretty sure the problem has to do with these lines, clState->padbufsize = bufsize;
clState->padbuffer8 = clCreateBuffer(clState->context, CL_MEM_READ_WRITE, bufsize, NULL, &status); For whatever reason your program is calculating 0 for the bufsize. You should be able to step through this with a debugger and figure it out pretty easily I would presume. I'm unable to reproduce this anywhere. Can you give me your whole command line minus any account details? --scrypt -I 20 -g 1 -v 1 -w 256 --shaders 1792 --thread-concurrency 12288 or 24000 Off the top of my head It's been a noted bug in the windows version since the tittiez beta builds Now that is just bizarre. I tried it even on a windows machine and it didn't give me zero... EDIT: Nm, can now reproduce. Okay I've done quite a bit of investigation around this "0" displayed issue. Ironically, that is a display bug in windows. The buffer size is actually being worked out to something like 1.5 billion, and if it's put on a separate line you can see that bufsize is not zero (I'll do it in the next version). However this does not fix your original complaint that you can't set very high thread concurrency counts like you could on raper [sic]. But you've reminded me of what happened when I investigated this originally. There are a number of problems with the way raper uses the padbuffer there. Firstly it is reused between threads which means that if you set multiple threads per device they fight over and can trash the data in the buffer. That's not a huge problem with raper because its threading is pretty primitive, unlike cgminer which is heavily multithreaded. However, the main problem is that there is NO error checking on setting values to run the opencl commands. If it returns invalid values, raper just does it again, and assumes the hashes have been done. So it intermittently works, and intermittently just counts up a number of hashes that never happened. So what happens is you get a displayed hash rate that is really high that does not translate into a proportional rise in number of shares generated. Summary: I implore you to compare the best share generation rate of raper to cgminer rather than the displayed hashrate. I only go by pool hashrate. Reaper pulls 550kh/s per card versus 460kh/s per card with cgminer. That's a 20% improvement. Reaper gets ~3% stales which is more or less the same as compared with cgminer. edit: tried these settings --scrypt --thread-concurrency 8000 --shaders 1792 -I 20 -g 1 -v 1 -w 64  Okay. The problem is the same as the one with reaper, in that when thread_concurrency is too low 7xxx cards will only yield hardware errors at intensity = 20. to fix this, you need to use more memory. if you could, it'd be extremely helpful to add a flag to the program to simply ignore the memory size checking and create the pad on the GPU anyway (for some reason, cgminer is only reporting that my video cards have 512mb of memory when they have 3gb. I don't know why this is)  basically, i'm pretty sure the problem is that cgminer is calculating the memory size available on the card incorrectly. |
|
|
|
Problem has been fixed, now cgminer should be able to use 7xxx cards effectively as of v. 2.7.7 :-) |
|
|
|
What a pain this is....
likely won't get outbid, my ass....
screw it. guess I won't be getting any kava. Glad I wasted a money on this, seeing as I likely won't use the remainder of credits I have.
If you want solid kava kava root powder I'll hook you up. I think I've got about 100-200g of hawaiian premium left. 30-50g does me in. |
|
|
|
You should be able to easily replicate this just by setting --thread-concurrency 12288 (which works fine on reaper). I'm pretty sure the problem has to do with these lines, clState->padbufsize = bufsize;
clState->padbuffer8 = clCreateBuffer(clState->context, CL_MEM_READ_WRITE, bufsize, NULL, &status); For whatever reason your program is calculating 0 for the bufsize. You should be able to step through this with a debugger and figure it out pretty easily I would presume. I'm unable to reproduce this anywhere. Can you give me your whole command line minus any account details? --scrypt -I 20 -g 1 -v 1 -w 256 --shaders 1792 --thread-concurrency 12288 or 24000 Off the top of my head It's been a noted bug in the windows version since the tittiez beta builds |
|
|
|
Scrypt mining is still broken in that it can not utilize high thread concurrencies (I need to use a thread concurrency of 24000 for my 7950s to mine effectively). The bug seems to be with the calculation for memory allocation. It can be easily duplicated by setting the thread concurrency above 8192, eg 12288. In reaper, any thread concurrency may be used as long as it is a multiple of 64 and produces a memory padding that fits within the card's memory space.
Using "set GPU_MAX_ALLOC_PERCENT=100" in Windows allows the program to run, but it doesn't hash at all and does not create a memory pad on the GPU.
I reported this several weeks ago and it still hasn't been addressed.
That's cause I have no idea what the problem is. Setting GPU_MAX_ALLOC_PERCENT does nothing on windows, only linux. [2012-10-05 16:01:03] Started cgminer 2.7.6
[2012-10-05 16:01:03] Started cgminer 2.7.6
[2012-10-05 16:01:04] Probing for an alive pool
[2012-10-05 16:01:04] Long-polling activated for http://ltc.kattare.com:9332/LP
[2012-10-05 16:01:06] LONGPOLL from pool 0 detected new block
[2012-10-05 16:01:15] Maximum buffer memory device 0 supports says 524288000, your scrypt settings come to 0
[2012-10-05 16:01:15] Error -61: clCreateBuffer (padbuffer8), decrease CT or increase LG
[2012-10-05 16:01:15] Failed to init GPU thread 0, disabling device 0
[2012-10-05 16:01:15] Restarting the GPU from the menu will not fix this.
[2012-10-05 16:01:15] Try restarting cgminer.
Press enter to continue: There's the error code for you. You should be able to easily replicate this just by setting --thread-concurrency 12288 (which works fine on reaper). I'm pretty sure the problem has to do with these lines, clState->padbufsize = bufsize;
clState->padbuffer8 = clCreateBuffer(clState->context, CL_MEM_READ_WRITE, bufsize, NULL, &status); For whatever reason your program is calculating 0 for the bufsize. You should be able to step through this with a debugger and figure it out pretty easily I would presume. |
|
|
|
|
pm'd the serial, enjoy. sorry it took so long, been super busy.
|
|
|
|
|
What are they using a light microscope and fan ducting for?
|
|
|
|
Litecoin could only be worth more than .25 BTC if it turn out to have a significant advantage over BTC.
I don't think faster transaction times qualify enough.
One possible scenario would be that it turns out to be more secure than BTC. The SHA-3 competition has declared a winner this week and it is in the realm of possibility that some cryptanalysis on SHA-2 is released after now which has been held back not to compromise security of systems.
I don't think keccak really has much to offer that SHA256 doesn't already have aside from faster speeds (which is why it was selected). The circuit sizes are still pretty small and thus still will probably be mined more quickly with ASICs. |
|
|
|
It's normal. Difficulty changes every 3.5 days, so LTC has enhanced volatility as compared to BTC. Price goes up and down based on supply and demand. What else is new?
Maybe look at the graphs, they're not linked at all to the (relatively small) difficulty changes, or anywhere near the same percentages. It's very abnormal. Have a look on ltc-charts.comAnyone who doesnt get the nature of LTC pump/dump spec probably shouldnt be investing in it. I've been mining ltc since 2 weeks after the genesis block. I've seen it all. Doesn't phase me. The order book says: Price is going up. The order book has been saying that since the price was 0.0035 and I called it then. It's going to keep going up. So is the hash rate. Tacotime what's your hashrate btw? Right now it's 2mhs |
|
|
|
It's normal. Difficulty changes every 3.5 days, so LTC has enhanced volatility as compared to BTC. Price goes up and down based on supply and demand. What else is new?
Maybe look at the graphs, they're not linked at all to the (relatively small) difficulty changes, or anywhere near the same percentages. It's very abnormal. Have a look on ltc-charts.comAnyone who doesnt get the nature of LTC pump/dump spec probably shouldnt be investing in it. I've been mining ltc since 2 weeks after the genesis block. I've seen it all. Doesn't phase me. The order book says: Price is going up. The order book has been saying that since the price was 0.0035 and I called it then. It's going to keep going up. So is the hash rate. |
|
|
|
|
It's normal. Difficulty changes every 3.5 days, so LTC has enhanced volatility as compared to BTC. Price goes up and down based on supply and demand. What else is new?
|
|
|
|
|
Scrypt mining is still broken in that it can not utilize high thread concurrencies (I need to use a thread concurrency of 24000 for my 7950s to mine effectively). The bug seems to be with the calculation for memory allocation. It can be easily duplicated by setting the thread concurrency above 8192, eg 12288. In reaper, any thread concurrency may be used as long as it is a multiple of 64 and produces a memory padding that fits within the card's memory space.
Using "set GPU_MAX_ALLOC_PERCENT=100" in Windows allows the program to run, but it doesn't hash at all and does not create a memory pad on the GPU.
I reported this several weeks ago and it still hasn't been addressed.
|
|
|
|
will you take 0.5 BTC for Dirt Showdown?
sure 13xS8M8Fh5uK7h8BgjjkgFigttCAtkNeRG |
|
|
|
|
Show Posts
