djm34 and gingeropolous hashout mining software

<gingeropolous> hows it going? I think I saw you post somewhere that you were unclear regarding the Monero gpu mining specifics for the funding / bounty. Anything I can help clarify?
<djm34> what do you expect at first milestone ?
<djm34> this is mostly what I don't understand
<gingeropolous> gotcha.
<gingeropolous> I wrote it out here: https://bitcointalk.org/index.php?topic=656841.msg12094899#msg12094899
<gingeropolous> but basically, if you're unable to get a lot of hashrate from your efforts
<gingeropolous> then some improvement over the current nvidia miner would be required for a payout.
<gingeropolous> so, point A is essentially - making the code well commented and clean. I've heard your a good programmer, so this shouldn't be a big problem
<gingeropolous> point B - the software should work on linux, windows, macs, etc
<djm34> I don't have macs
<gingeropolous> gotcha
<gingeropolous> does anyone even mine on macs?
<djm34> not really apple computer don't really use  much nvidia either
<gingeropolous> okay, well, we'll get rid of that.
<gingeropolous> point C: tunable parameters
<gingeropolous> basically, the software should be very modifiable with a config file.
<djm34> hmm... what do you want to modify ?
<gingeropolous> well, i imagine anything that you would otherwise hard code
<gingeropolous> but im not a programmer, so I dunno how feasible that is
<gingeropolous> I imagine if you were writing something, you would put 1024 in..
<gingeropolous> for some value dealing with memory
<gingeropolous> for instance
<gingeropolous> instead of putting the hard value at 1024, would it be possible to just call it ValueX, and then set valueX = 1024
<gingeropolous> and make it adjustable via a config file?
<gingeropolous> the hope is to extend the life of the software
<gingeropolous> so that in 3 years, when nvidia releases a 12 gig maxwell card for some reason (for example), your software might be tweakable
<djm34> the current one can already do that with thread and block value
<gingeropolous> right. My question is whether there are other values that could be swapped in
<djm34> that's basically how the required memory gets assigned
<gingeropolous> I don't know the code
<gingeropolous> ok
<gingeropolous> well, that point in general means exactly that - if you come up with something in your code that could be modifiable instead of a set value, it would be cool to make it modifiable
<djm34> also it isn't necessary to pass to many parameter to the config files because it makes the compiler clueless
<djm34> a good idea*
<gingeropolous> gotcha. well, in general, the point is just to think of what would happen to your code if a new GPU came out
<gingeropolous> with the same architecture, but more memory, faster memory, etc
<djm34> this is already handled by the current version
<gingeropolous> ok, cool. I didn't know that (i only have 750 tis, so I haven't really tried other cards)
<gingeropolous> point D: basically, it should be really easy to compile this from source
<djm34> well the -l"thread"x"block" tells to the program how much memory it should use
<gingeropolous> so, very limited dependencies. I know from watching monero development that it is possible to include dependencies in the actual source code
<djm34> yes it is possible latest version of ccminer does that and uses static libraries
<gingeropolous> nice
<gingeropolous> so you don't have to install the CUDA toolkit?
<gingeropolous> with the latest ccminer?
<djm34> this you still have, if you want to compile
<gingeropolous> ugh
<djm34> also cuda isn't opensource
<gingeropolous> ah, so there's technically no way to use static libraries
<gingeropolous> well, in that case, would it be possible to create a compile package?
<gingeropolous> the goal here again is user friendliness
<djm34> ? you use the static libraries when you compile, so your binaries doesn't require any dynamic libraries
<djm34> but assuming you are compiling it yourself, you still have to get cuda
<gingeropolous> gotcha
<djm34> (it is a compiler...)
<gingeropolous> would it be possible to include cuda in a downloadable gzip file or something?
<gingeropolous> ideally, someone wanting to mine would just download 1 zip file, and have everything they need to compile
<gingeropolous> as opposed to now, where you have to hunt down the cuda toolkit, driver, etc.
<gingeropolous> well, for linux compiling. I guess things are easier for windows
<djm34> cuda distribution is around 1GB
<djm34> windows or linux
<gingeropolous> well, then it becomes a problem for whoever is hosting the file :)
<gingeropolous> so, for reference
<gingeropolous> this is how I tell people to install tsivs miner: https://d3adbra1n.wordpress.com/2014/05/03/cuda-miner-installation-on-a-fresh-ubuntu-14-04-lts/
<gingeropolous> its 39 steps.
<gingeropolous> ( obviously, the git clone command is replaced for tsivs repo )
<djm34> I know, but I am afraid it isn't really easy to put in a full distribution (or may-be doing something like what ethereum did... )
<gingeropolous> i dunno what they did...
<djm34> you end downloading 5gb of useless crap
<gingeropolous> ah
<djm34> (not entirely useless... but qt just for mining...)
<gingeropolous> welp, for noobs, its better that the useless crap is downloaded and it actually works
<gingeropolous> as opposed to it requiring 40 steps.
<djm34> actually it still doesn't download cuda
<gingeropolous> ha!
<gingeropolous> or, the 40 steps could be scripted in some bash script
<gingeropolous> if thats possible.
<djm34> may-be
<gingeropolous> well, in any case, does that milestone point make sense now? thats item D
<gingeropolous> item E is just that it works on available nvidia hardware. Honestly, I can't test if it works on anything except maxwell, so who knows how useful this is
<gingeropolous> is the old architecture even worth it these days?
<djm34> the 780ti is still good
<gingeropolous> ah, so thats kepler
<djm34> yes
<gingeropolous> does tsivs work on kepler? but yeah, thats the point of item E - that it works on as many architectures as possible
<gingeropolous> realistically, I imagine this is like maxwell, kepler, and whatever came before kepler
<djm34> mostly, actually it is where I was able to optimize a bit
<gingeropolous> interesting. are you still planning on rebuilding from scratch, or just work with tsivs code?
<djm34> for the moment I prefer to use tsiv code... but it would probably better to use the current ccminer interface
<gingeropolous> well, whatever code is cleaner
<gingeropolous> and whatever code will be easier for others to come in and contribute to in the future
<gingeropolous> ok, the final point, F, is the ability to solo mine
<gingeropolous> so, someone could use their GPU to mine on their own node, no need to connect to a pool
<gingeropolous> or no need to run their own private pool
<gingeropolous> one of the things to think about while your working on this is that , hopefully, this code will one day be included in the Monero source code
<gingeropolous> in other words, we ultimately want Monero to remain decentralized, and to maintain that, we need as much independent mining nodes as possible.
<gingeropolous> Thus, each solo miner should be able to use all the hardware they can - their CPU, and GPUs, or any on-board GPUs (even if its only 40 h/s)
<djm34> will have to check the cpuminer code for that
<gingeropolous> so, thats milestone 1. Do you think thats worth 1500 xmr?
<gingeropolous> and then milestone #2 is the hashrate, with some exponential curve relating payout to hashrate increases, with a max of 3500 xmr.
<djm34> yeah but quite frankly I don't think it can be reached
<gingeropolous> which one, milestone 1?
<djm34> second 1
<gingeropolous> milestone 2?
<djm34> yes
<gingeropolous> because the POW function is that difficult?
<djm34> actually the pow fucntion isn't difficult (that's why there isn't much to optimize mostly xor and a multiplication)
<djm34> however I am still surprise that the amd are doing so well
<gingeropolous> smooth once said that to really get at optimization, we'd need to know the level of like circuitry diagrams etc
<gingeropolous> so maybe claymore has that kind of knowledge
<gingeropolous> perhaps there's a reason he keeps his stuff closed source, beside the profit model :)
<djm34> don't know... I have a couple of other idea I might try though...
<gingeropolous> well, if they curve is too shallow, let me know and I can try to come up with a better one
<gingeropolous> well, how does it all sound? Is milestone #1 clearer now, and do you still want to do it?
<djm34> I can try
<gingeropolous> ok. Is it cool if I post this entire conversation, to try and get the funding secured?
<djm34> sure
<gingeropolous> i'll remove my claymore comment :)
<djm34> lol
<gingeropolous> aight cool. What kind of timeline do you think you'll need for milestone #1?
<gingeropolous> 3 months? 1 month? 5 months? 2 weeks?
<djm34> rather 2 weeks
<gingeropolous> okay, and milestone #2?
<djm34> difficult to say...
<gingeropolous> also, for milestone #2, keep in mind that you can enlist others to help
<gingeropolous> in that case, you would manage the payout to your team
<gingeropolous> okay, well for milestone #2, we'll just give it 1 year.
<gingeropolous> and the payout can be incremental. So, if you get it to +100 h/s, you would get paid 280 xmr. Then, if you come back and find another optimization, and get it to +200, you'd get (784 - 280) ~ 500 xmr, etc. You'd get the difference along the curve
<djm34> for 100H/s this isn't really a lot
<djm34> those 100H/s don't really come easily
<gingeropolous> okay, so the curve needs to be steeper
<djm34> yes
<gingeropolous> what would be a good target for the first 100 h/s?
<djm34> I would say around 750xmr
<gingeropolous> ok
<gingeropolous> man im really bad at making curves
<gingeropolous> there we go. OK, nice and easy. +hr/0.133333 for first 100 h/s, then +hr/0.18.
<gingeropolous> so first +100 = 750 xmr, +200 = 2025, +300 = 3037
<gingeropolous> thus, + 346 = 3500 xmr
<djm34> sounds better already
<gingeropolous> but im sure when we get to that bridge, things will be different
<gingeropolous> so, if u get it to +100, you'd be payed out 750. If you then take a break, come back and get another +100, you'd get (2025 - 750), and if you came back later you'd get (3037 - 2025)
<gingeropolous> so its linear, but each +100 h/s is about 1000 xmr after the first one
<gingeropolous> and of course, this is all relative to the current hardware. If a new card comes out and can get +400 h/s, this payout schedule still relates to getting the nvidia 970 gtx == R290x
<djm34> yeah but a new card doesn't really count...
<gingeropolous> right right
<gingeropolous> so is everything clear and we're good to go?
<djm34> sound good yes
<gingeropolous> okey doke! I'll try to get this funded!