 Show Posts
|
|
Pages: [1]
|
After running it for a while on my 6970s, I find even this change is of no benefit either  It's ever so slightly slower it appears. Not sure what to do now about all this. I'll just be quiet and go back in my hole for a bit. :/ |
|
|
|
I was mistakenly under the impression your changes incorporated everything from the latest kernels. Perhaps I may have to roll them all back and start porting it all myself. Darn. I had attempted to, however, I was trying to incorportate both phatk2.2 and diapolo's versions, since in my attempts, i was not able to integrate either of them alone to get cgminer to work as well as either of those versions were, running standalone. I also realised late lastnight that I might have missed a few things that could have changed things, but my VirtualBox windows .vdi crapped out on me, so I'm unable to utilize the Kernel Analyzer right now. One thing I definitely want from Diapolo's most recent work is the new output method. Not only is it faster, but it seems to subjectively give a *much* higher Efficiency/Utility. (Not tested over a long enough timespan to say objectively) |
|
|
|
Current 110810 kernel on git has 1368 ALU OPs for 58XX and 1696 for 69XX, that's neither phatk 2.2 nor my latest result (which is 1364 / 1688), but a bit faster than the last official CGMINER kernel. I mailed my latest version to Con for review  . The added __attribute__((vec_type_hint(u))) is unknown to the compiler and throws a warning, but IS mentioned in the OpenCL 1.1 manual ... strange. Dia Correct, it's not 2.2, nor your most recent. It was an honest attempt at integrating *both* of them, but I think now that I missed a few things. I had noticed the Kernel Analyzer threw an error about vec_type_hint, but it compiles without issue on linux. I don't have native windows (only virtualized) to test anything there. In testing, I was unsure as to whether vec_type_hint made an improvement, but I was certain that it wasn't the opposite. |
|
|
|
Don't be scared. You're doing good work. I'll play with your changes and see if they break anything  Welcome back! It's not so much about being scared; More that I didn't do a bunch of little commits and comment the specific changes. I would have liked to have done that...at least so they could be submitted as separate changesets/patches for you to look at. I *have* done that for the next couple commits |
|
|
|
Since Con is away... I thought I'd take a try at integrating some of the recent changes in both phatk kernel threads. ( here and here) I've also changed the method used to specify various #defines for the kernels by simply specifying the defines as build options for clBuildProgram() instead of editing the .cl text on the fly. (so much simpler!) Compared to the current kernel in cgminer 1.5.3, this does benefit from reduced ALU OPs, although not as much as either of the other phatk kernels: 1.5.3: VLIW4: 1699 ALU OPs VLIW5: 1376 ALU OPs Mine: VLIW4: 1694 ALU OPs VLIW5: 1368 ALU OPs My changes are here at github, but it's all in one big ugly commit, and not broken out by the individual changes, so i don't feel comfortable in the slightest offering a pull request to CK for it. |
|
|
|
I'm aware of this, thanks. It was a half arsed attempt to fix the crash that old libcurls have when the display is refreshed twice in a row. I've pushed a change which should fix that just now.
Yup, that fixed it, thanks (I figured you probably knew about it, but it could have just as easily been local to me, too...) |
|
|
|
|
Current git, I'm having issues with the curses display. Normal running is okay, but attempting to access any of the interactive options fails to have them drawn properly on the screen. It had worked with 1.4.1, but not in 1.5.0.
I can still press the appropriate key to access the appropriate function, but I never see the options. Example: I select [P]ool, the whole screen is redrawn, and the scroll portion goes blank. If I type "i" for info, it then prompts me what pool I want info for. However, then the screen redraws completely, and I'm given no info.
|
|
|
|
I then ran ldoconfig. I still had to use CFLAGS=-I/usr/local/cuda/include LDFLAGS=-L/usr/lib64/nvidia in order to have gpu mining support enabled even though /etc/ld.so.conf.d/local.conf still had these lines:
/usr/local/cuda/lib64/
/usr/local/cuda/lib/
ld.so.conf (et. al.) only affects runtime linking, not compile time linking. Likewise the LD_LIBRARY_PATH environment variable only has any effect on runtime linking. To the best of my knowledge, there exists no compile-time counterpart to ld.so.conf. However, there is an environment variable similar to LD_LIBRARY_PATH. It is LIBRARY_PATH. Anything set in this variable will be searched by gcc during the link stage. However, it would appear you still need to specify your CFLAGS, since you're asking it to include a non-standard path. |
|
|
|
You need to run aclocal before autogen.sh or ./configure. If you dont have it, install automake or autotool.
Thanks, I installed automake and got a bit further but now I get the error configure.ac:125: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation. Do you have the needed build dependancies installed? You might get this error if autotools cannot find a definition for LIBCURL_CHECK_CONFIG (the only macro in configure.ac that actually calls AC_MSG_ERROR) Try: sudo apt-get install libcurl4-openssl-dev |
|
|
|
What is considered a "Prolonged outage"? Look at the timestamps on this: [2011-07-16 12:40:33] Share a89dc2bb accepted from GPU 1 thread 1
[2011-07-16 12:40:43] New block detected on network before longpoll, waiting on fresh work
[2011-07-16 12:40:54] LONGPOLL received after new block already detected
[2011-07-16 12:40:54] Share 14572bd0 rejected from GPU 1 thread 4
[2011-07-16 12:41:05] Server not providing work fast enough, generating work locally
[2011-07-16 12:41:05] Prolonged outage. Going idle till network recovers.
[2011-07-16 12:41:05] Resuming with work from server
[2011-07-16 12:41:13] Share 933d1b38 accepted from GPU 1 thread 1
(running build from git version 1.2.7) |
|
|
|
|
I think it actually makes good sense for the client to use a header: it is often a common practice to advertise capabilities in HTTP headers (or even e-mail headers...)
However, it might make sense for the server to respond with the noncemask in the JSON content, as the client has already advertised its capability to handle such content.
|
|
|
|
Most miners generate nonces entirely at random, if I am not mistaken. That's inherently flawed, there are much better ways to generate a "low" hash value.
Actually, they iterate consecutively through the noncespace. (I think) But hey, finding a needle in a haystack is in your favour searching consecutively if the needle is near the front of the haystack. Searching randomly, it doesn't matter where the needle is, it's random chance. |
|
|
|
*sigh* I've been reading the forums for a while, just never got around to creating an account until now, as I was about to respond with a bug report to Con Kolivas' cgminer thread. I can't see anywhere else to submit bug reports. Somehow I missed the whole newbie forum requirements until I went to post... I've been mining for about 3 months, as you can see here. Edit: Well, at least in the meanwhile, this post lets me PM CK with the bug information... |
|
|
|
|
