It seems my very first decision on this project was the wrong one. I forked from ccminer-multi-1.2pre
instead of 1.1. I also failed to confirm 1.2pre would compile in windows.

Now I'm in a bind and it will delay windows support.

Hopefully the conflicts are only in files I haven't touched, if so I should be able to release with windows
support without too much delay. Otherwise I will go ahead and release with only linux support.

I believe you can set persistent mode which preserve the setting over a reboot. There have been some recent advances
so make sure you have the latest drivers.

You can also OC using nvidia-settings after setting up coolbits in Xorg.conf, Sorry, not time time to dig up the details, too busy.

Did you ever configure coolbits to give you fan control (and OC too)? You can keep your cards hotter and colder at the same time.

I've never heard of the 750ti wtf.

If you're talking analog computers that's really old, if analog data transmission it puts you in my generation.

Bigger cache line and a memory intensive algo. Makes sense.

Pallas suggested moving this to your thread but discussions about kepler aren't really on topic for SP_MOD..
Well it's my thread, I don't think there is much more to discuss but if it takes off we can start it's own thread.

I'm satisfied with this explanation so the only solution^h^h^h^h^h workaround is a form of hybrid.
I have built such a hybrid but it is bloated because of a 2 dimensional growth in neoscrypt code.
Because I make the kernel selection at run time both versions of neoscrypt get buillt into all three
versions of cuda. Only the 3.5 cuda will select DJM34 neo and the maxwell code will only select the Pallas neo.
I'd like to move the check to compile time but haven't been motivated enough to implement it without
a ccminer fork willing to host it.

If there is interest I can take another look once things settle down a bit with cpuminer.

Thanks Pallas. The first release won't support CPUs without AES_NI and will just exit. However, for testing
For the test build it wil still try to run. My only goal is to look for false positives and false negatives that
indicate the AES_NI check isn't 100% accurate. I'm also curious to see what will happen if an older CPU
tries to run AES_NI code.

I've got all that covered for the test cycle but I'll keep your offer in mind for the second release which will
support non-AES_NI CPUs.

Also thanks for all your work, I'm sure there's much more than I'm aware of.

I'm still somewhat puzzled about
the different performance profile for your neoscrypt ccminer kernel vs DJM34's. Yours works better on Maxwell
but DJM34's hashes 12% faster than your on my 780ti. Considering the nature of neoscrypt it's likely the HW
configuration is the reason for the difference, but I can't help to think think that understanding why this performance
reversal happened. I did some analysis when your kernel was released, and tried mixing up parts of each kernel
to try to affect performance but had no success. As someone who is intimately familiar with both versions I
was hoping to jog your mind and maybe spark an idea for further optimization.

I know the payout coin is chosen by the user argument but how do I choose the coin to
mine with only a single port for each algo. An how to I mine a scrypt coin with an x11 miner
or vice versa?

An update on the beta test.

Windows is definitely out for the beta test and so is CPU ID display. Arcitecture checking is working but will be
in permissive mode for the test build. I'm pretty beat tonight but will start packaging everything tomorrow.
I will be contacting the select beta testers by PM to make arangements for getting the beta build to
them. I expect it to be available friday. I expect the beta test to be quite short as the software has been
very reliable. I hope the first public release is out next week.

While waiting until I downgrade to VS 2013 let me indulge myself as I ramble on about who I am.

I'm a 58 year old computer geek who was laid off with a good severence package 8 years ago less than
a year before the company went bankrupt.

My education is somewhat limited, just a 3 year computer science diploma. In my final year in college
I and 2 other team members wrote an assembler for a microprosessor board that didn't have one.
It had no keyboard or display interface just an rs-232 serial port. So we had to write the assembler
twice on two different processor architectures. My teammate had an Apple 2e and it could connect
to the serial port and talk to the monitor program. It also had some rudimantary file transfer capability
so off we went. We got it done on tie with only one real all-nighter which was more by choice than
necessity. We were among the few that attended class or stayed awake in class the last week before
the formal project demonstration week. We actually had a live demo where we uploaded source code
to the board comlied it and executed it. And it worked. For a bit of humour we even deliberately
left a coding error so we could show the eror handling capability. They we all three graduated and
ended up at the same company, although at different times and in different departments. The same
company that went bankrupt after giving me a golden parachute. Ifeel sorry for the people layed off
after me because the company started cutting back on the packages. Then they declared bankruptcy
and all severance packages were taken off the table. They even reduced pension benefits to past
employees A real shame.

The proprietary system I worked on used Motorola 68k, 88k and powerpc cpus. I was most familiar with
the unpopular 88k. My claim to fame was discovering a bug in the branch prediction which ironically
improved performance once it was disabled. Apparently the BP conflicted with a compiler optimization
even if it had been working properly. The 88k, Moto's first venture into RISC, however, was short lived.

The software system was an integrated development system consisting of a run time real time operating system,
it's applications, a Linux based (originally IBM mainframe) multi-site program and documentation library,
and compiler all written in and for a proprietary high level language with similarities (ie strict type checking) with Pascal.
I really learned to love the language and it has some great features, with OO added later. One of my favorite quirks
in the language was the guzinta: "->". This is unlike similar c++ operator. It is the assigment operator
and works like this:  "value -> variable;".  Some of your may recognize it.

it had some important features like not defining the null pointer as 0. nul always pointed off to invalid address high
up in the address space. Address 0 was also invalid and would throw an exception if accessed. The languange
also had array index protection built into the compiler. An index out of range also would throw an exception.
There was also a built in data structure (nice to own your own compiler) called a descriptor that was essentially
a pointer to an array. It also had index protection. c++ probably has a class similar to the descriptor but without
index protection. That feature alone made the system so much more resilient to memory corruption and easier
to debug, but most importantly the concept of a buffer overflow did not exist. The compiler would not allow it.
Imagine how many fewer exploits there would have been had c/c++ had such protection (at a slight performance
cost).

I've never done any Linux or c++ development although I had some exposure to c++ at work. Many of the concepts
are so different that what I am familiar with and that slows me down a lot. I've used HP-UX, solaris and linux as
desktop workstations at work and used linux at home since Redhat 5.2.

Although I'm comfortable with assembly code I haven't touched Intel since the 8000 series. That will make the assembly
language files tough to work with. I have a couple of optimization thechniques I've used in the past but they require
intimate knowledge of the Intel architecture such as memory interface, cache organization, execution environment,
instruction issue and retirement throughput, and things I'm probably not aware exist. I have a lot to learn, but that's why
I'm here.

I know nothing about cryptographic algorithms so don't expect me to code new algos. I'll leave that up to others.

I had heard of Bitcoin but didn't get involved until very late (too late) in the darkcoin frenzy in April 2014. I started
with just one CPU but unknown to me at the time ASICS had taken over bitcoin and scrypt was next. And GPUs were taking
over the altcoin algos. I bought a gt730, a nice little card that performed on par with my i7-4790K. I bought a 750ti shortly
after that and a few other cards since then.

Well that's how I got here. I'm bored with lots of time on my hands so I've been poking around at miner code here and there.
I'm even less familiar so I took a shot with a cpuminer and was surprised. It is a credit to Pooler's design that I was able to
pull together code from 3 different miners and make it work smoothly and efficiently in a short time.

VS is still installing but I think it's time for a break.

I must be getting tired I just tried to post this to the wrong thread. I giess i don't have the stamina I did 25 years ago.

Thanks for reading and taking an interest in my project.

There was a lot wrong with that file, some of it was me and some of it was editpad++.
I'm starting fresh.

Edit: It's loaded now.  I made minimal edits and avoided moving things around. I should have known
better than to get too adventurous with MS. Thanks again for your keen eye.

Edit2: 479 errors on first compile. An this is code that compiles flawlessly on Linux. Obviously Windows
support is out for the beta. Maybe I'll get it working in time for the release.

Hi Wolf0, thanks for contributing.

I've got the capabilities check working has_aes-ni() already existed and I wrote has_sse2. I'm now trying to get cpuid working to see
if I can display the actual cpu model.

I'm looking for opinions on how to handle incompatible CPUs, during the test phase and then the first release

There are two parts to this issue. First is whether the CPU has AES_NI and the second is whether
cpuminer is compiled for that architecture. it's a biggger issue on Windows where the builds are
portable. I hope MS builds to support multiple architectures and select the best one at run time.
When multiple architectures are supported in cpuminer it is my intention to do exactly that.

But for the time being it only support ASES_NI so...

For the first part I'm considering 4 options.

1. If the CPU doesn't support AES_NI exit.
      probably most likely for the release

2. Damn the torpedos full speed ahead
      My preferred choice during testing

3. Add a comand line prompt to choose 1 or 2
        will become obsolete when more architectures are supported
        would probably delay the test release

4. Add a user prompt at startup
       This would require the work in 3 as well additional work to add a yes/no prompt and
       expand the new command line option for 3 choices if an incompatibility is found: Exit, Continue,
       or Prompt(default). This has all the cons of 3 but more so.

I'm not interested in poll, I prefer the reasons for the choice. And of course the beta testers can get what
they want.

It's not the first time I've been blind, many thanks.

Update: No joy. I still get the same error. I was suspicious about th etypo becase I did double check everything,
my editor has been acting up so I may have messed up the line without realizing. I confirmed with the VS editor
that it was using the right file, the line looks just like every other (asfter deleting "x6" and I confirmed the file is present.

Windows support may have to wait.

I'm having some difficulty compiling on Windows with VS community 2015.

If there is anyone who can help it will speed up Windows support.

I editted  cpuminer.vcxprog with a text editor, not VS's built in editor.
I modelled the changes based on the sources list in Makefile.am,
but I really have no idea what I'm doing.

I added a bunch of entries to this list:


I get the following error.: The attribute "Include" in element  </ClCompile> is unrecognized. I've shuffled
the order of the list and it errors on a different file everytime but the same line number.

Any ideas welcome.
    

I'm comfortable with the testers I have now but thanks for the offer. You shouldn't have to
wait very long for the public release.

You might want to talk to epsylon3 (tpruvot) about new algos, but I think he is more focussed on
his ccminer fork and yiimp pool (busy guy) at the moment.

I'm starting to work on compiling on Windows, if it goes well it should b be ready for private beta in a couple of days.

Uhhh, how? It's listed under sha256.

Thanks SP. Now if only I could code in cuda.

I don't know what you have but in general terms AES-NI is included in all Intel i series CPUs. Some of
the lower end pentiums may not have it. sse2 came in around core2 but I may be mistaken. I have
no idea about AMD CPUs.

Come join me in my new thread.

https://bitcointalk.org/index.php?topic=1326803.msg13542103#msg13542103

Thanks kama. The project is just getting off the ground officially, nothing is yet available publicly
or privately.

Source code will be available. I compile Windows with VS and am not inclined to change. But as
I editted in my first post Windows is not guaranteed in the first release. It Depend on how things go.