CCminer(SP-MOD) Modded GPU kernels.

[joblo]

would the windows version run on Linux via wine? 

No - it accesses the GPU, which requires the driver libs, which call into the driver running in the Windows kernel mode eventually. Not fucking happening.

It's fucking happened already.

I've done it and confirmed I get full hash rate.

The GPU doesn't care what the host OS is, it's just given a binary file to run in it's own run time
environment. All it needs is a common driver interface to talk to the host.

As an FYI you can also compile cuda in a VM, either windows or linux. You don't need the drivers,
just the cuda tools. I've done that too.

[1714774382]

1714774382

[1714774382]

1714774382

[1714774382]

1714774382

[1714774382]

1714774382

[1714774382]

1714774382

[joblo]

would the windows version run on Linux via wine? 

No - it accesses the GPU, which requires the driver libs, which call into the driver running in the Windows kernel mode eventually. Not fucking happening.

It's fucking happened already.

I've done it and confirmed I get full hash rate.

The GPU doesn't care what the host OS is, it's just given a binary file to run in it's own run time
environment. All it needs is a common driver interface to talk to the host.

As an FYI you can also compile cuda in a VM, either windows or linux. You don't need the drivers,
just the cuda tools. I've done that too.

Yeah, no shit - I know this. I also know at least in the case of AMD, you need to call into the driver to load the binary ONTO the GPU. How exactly does Wine handle this without explicitly catching the calls and making sure it calls into the Linux lib, which will properly handle it from there? Maybe Nvidia has a different system for this, I don't know.

Sounds like an inferiour design on AMD. Linux sits between wine and and the driver, it just provides an api
to direct windows system calls to the linux versions. The gpu talks to the windows ccminer via apis in wine
but all it has to do is obey the command to accept a cuda binary file and run it, then send the results back
to ccminer on the host. Nothing more than a simple command interface and data transfer are needed.

I don't know why it's so difficult for AMD. The GPU talks to the host driver so it can talk to any linux process,
that's it's access to the file system. Wine doesn't need to handle it. Wine only gets involed when giving
commands to the gpu or talking to windows processes like the file system when retrieving the results.
It's probably the shitty AMD drivers. Maybe the GPU thinks it's running on windows and thinks it's the
victim of spoofing or something.

[Grim]

Now how "bad" is the TLB trashing in wine?
As bad as in windows
or as bad as in linux?

anyone knows?



I know TLB trashing is a hardware limit yet linux "behaves" best with windows 7 slightly behind it and
windows 8.1/10 is total garbage in this regard.

[joblo]

would the windows version run on Linux via wine? 

No - it accesses the GPU, which requires the driver libs, which call into the driver running in the Windows kernel mode eventually. Not fucking happening.

It's fucking happened already.

I've done it and confirmed I get full hash rate.

The GPU doesn't care what the host OS is, it's just given a binary file to run in it's own run time
environment. All it needs is a common driver interface to talk to the host.

As an FYI you can also compile cuda in a VM, either windows or linux. You don't need the drivers,
just the cuda tools. I've done that too.

Yeah, no shit - I know this. I also know at least in the case of AMD, you need to call into the driver to load the binary ONTO the GPU. How exactly does Wine handle this without explicitly catching the calls and making sure it calls into the Linux lib, which will properly handle it from there? Maybe Nvidia has a different system for this, I don't know.

Sounds like an inferiour design on AMD. Linux sits between wine and and the driver, it just provides an api
to direct windows system calls to the linux versions. The gpu talks to the windows ccminer via apis in wine
but all it has to do is obey the command to accept a cuda binary file and run it, then send the results back
to ccminer on the host. Nothing more than a simple command interface and data transfer are needed.

I don't know why it's so difficult for AMD. The GPU talks to the host driver so it can talk to any linux process,
that's it's access to the file system. Wine doesn't need to handle it. Wine only gets involed when giving
commands to the gpu or talking to windows processes like the file system when retrieving the results.
It's probably the shitty AMD drivers. Maybe the GPU thinks it's running on windows and thinks it's the
victim of spoofing or something.

AMD drivers are fucking terrible, granted - but I would think it should work mostly the same way... maybe WINE doesn't yet have support for it with AMD?

I don't know why they'd need to. Sending commands from the windows app to the gpu should be through a standard
interface and the gpu bypasses wine for file transfer.

[joblo]

Now how "bad" is the TLB trashing in wine?
As bad as in windows
or as bad as in linux?

anyone knows?

I know TLB trashing is a hardware limit yet linux "behaves" best with windows 7 slightly behind it and
windows 8.1/10 is total garbage in this regard.

I don't know but if it affects mining perfornance I'd guess there is no difference given the performance
is the same.

I'm specutating* too much. I should stick to what I know.

*That's the second interesting typo today. I think i'll copyright it. It even works in this context as a
mix of speculating and spectating.

[Grim]

Also with all the memory intensive algos around us it would be great if we could optimize memory latency timings for nvidia gpus. The best way to do (or rather try) is to find the memory timings of each strap (specific frequency range) and apply eg. the faster lower timings from a lower frequency strap to a higher frequency strap.

In memory intensive algos this could boost hashrates by quite a bit.



It works wonders for amd cards as seen in eth mining.
http://www.overclock.net/t/1561372/hawaii-bios-editing-290-290x-295x2-390-390x

Under the tab: Memory Timings modding
you find the juicy info



Any nvidia guru who knows this stuff?

(It seems tho samsung memory with factory settings is already quite optimized, so not sure its worth looking into)

[sp_]

would the windows version run on Linux via wine? 

No - it accesses the GPU, which requires the driver libs, which call into the driver running in the Windows kernel mode eventually. Not fucking happening.

It's fucking happened already.
I've done it and confirmed I get full hash rate.
The GPU doesn't care what the host OS is, it's just given a binary file to run in it's own run time
environment. All it needs is a common driver interface to talk to the host.
As an FYI you can also compile cuda in a VM, either windows or linux. You don't need the drivers,
just the cuda tools. I've done that too.

Problem solved.

Wolf0, why don't you opensource some of your work? Your famous x11 bins have now been beaten 100% by the kochur bins.

[ldw-com]

would the windows version run on Linux via wine? 

No - it accesses the GPU, which requires the driver libs, which call into the driver running in the Windows kernel mode eventually. Not fucking happening.

It's fucking happened already.
I've done it and confirmed I get full hash rate.
The GPU doesn't care what the host OS is, it's just given a binary file to run in it's own run time
environment. All it needs is a common driver interface to talk to the host.
As an FYI you can also compile cuda in a VM, either windows or linux. You don't need the drivers,
just the cuda tools. I've done that too.

Problem solved.

Wolf0, why don't you opensource some of your work? Your famous x11 bins have now been beaten 100% by the kochur bins.

Old news sp, that has already changed 

[djm34]

would the windows version run on Linux via wine? 

No - it accesses the GPU, which requires the driver libs, which call into the driver running in the Windows kernel mode eventually. Not fucking happening.

It's fucking happened already.
I've done it and confirmed I get full hash rate.
The GPU doesn't care what the host OS is, it's just given a binary file to run in it's own run time
environment. All it needs is a common driver interface to talk to the host.
As an FYI you can also compile cuda in a VM, either windows or linux. You don't need the drivers,
just the cuda tools. I've done that too.

Problem solved.

Wolf0, why don't you opensource some of your work? Your famous x11 bins have now been beaten 100% by the kochur bins.

that sounds like a bad suggestion actually, if anyone as a faster method, there wouldn't be any point in opensourcing at that level (you should know considering you are asking for 0.1btc donation since last week for your private miner )

[Genoil]

Same problem in the cryptonight algo. Doesn't work on widows 10

Can this be fixed? Looking at the memory controller, on W8 it's maxed out... W10 it's at about 50% (which is definitely comparable to the performance I'm getting).

I prefer having a installation on w10 so I can see and report on changes/bugs comparable between algos and fix them

Curiously is anyone having problems with Ethminer and Windows 10? It seems like my w10 970 rig produces 8Mh/s and my W8.1 rigs all produce 17Mh/s... Not sure what's going on here.

Yesterday I upgraded ssd to one gaming rig which had gtx 970 and windows 10. Tested quickly ETH mining and yes, it was only hashing about 7-8MH. Thought I messed something during upgrade but after more testing realized that W10 kills hashrate.

My guess is MS has changed an API in W10 that requires all devs to modify their apps to comply.
They've done it before.

I'm only familiar with this issue on Ethminer, but I understand Cryptonight is a memory-heavy algo as well. The reason for this behavior is known as TLB trashing. The TLB is a unit found on CPU's and GPU's that translates virtual memory addresses into physical addresses. The TLB maintains a table of mappings from virtual memory pages to physical memory pages. When a kernel uses a lot of different addresses in a wide memory space, this table runs full, causing addresses that used to previous cached on the TLB to be removed (trashed) and to have to be retranslated (global memory replay). This causes a huge delay. Apparently there is a difference between Windows 7,8 and 10 with regards to this, most likely in page size. Using smaller page sizes, memory address lookups can be performed faster, but the TLB runs full quicker.

The reason that this didn't happen with Ethminer before, is because of the increasing DAG size. I wrote a test program a while back to identify the allocation size after which this behavior would start happening on any given combination of GPU and OS (it's in OpenCL, but there is no difference with CUDA). If I remember well, there actually isn't that much of a difference between Windows 8 and 10, but that may be different for GPU's that I don't own. For Nvidia hardware with Maxwell 2, the best solution is to use Windows 7 or Linux.

[antantti]

Genoil, some ETH coming your way. Been using your miner since last summer but never donated.

0xf01f74a1eb99be1aee7f58b6f1e83d89524d374babbcda2cd6f576c0d61c466d

[Vita1ico]

By thinking ..
ETH
970 100ME(elpida) - 22 Mh/s
960 100ME(samsung) -10 Mh/s
ethminer-cuda-0.9.41
Windows 8.1 x64

My 970 works 22Mh/s. 970 no 100ME- 17Mh/s.Assume the memory effect Elpida.

Windows 8.1x64 (970+960)-32Mhs
Windows 10x64 (970+960)-12Mhs
Windows 7x64 (970+960)-31.5Mhs

chart (1).jpeg

[sp_]

that sounds like a bad suggestion actually, if anyone as a faster method, there wouldn't be any point in opensourcing at that level (you should know considering you are asking for 0.1btc donation since last week for your private miner )

Actually, most of of my work the last 12 months has been opensource. I still submit some improvements to my github, but I keep some private. For the miners that have alot of money invested in maxwell gpu's,
0.1 BTC is nothing when the revenue is guaranteed to increase with a few percent. That's why I work on all algos..

[bensam1231]

Private kernal for sale. 0.1BTC

Release 2 sp-mod private (750ti) (faster than release 78)

x11: +2.4%
x13: +5.4%
x15: +4.5%
lyra2v2: +6.45%
quark: +3.2%
qubit: +2.3%

I wish I could code cuda.

I have added 2-300khash in the quark algo on gtx 970. Now peaking at 19.45mhash with +155 on the core.(g1 gaming). Will be included in sp-mod private 3

Ppl want a linux version. I don't want to release the sourcecode. So no linux. Switch to windows, or loose hashrate:)

wow ...

so you are willing to 'lose' the support of linux miners to try and push them towards windows? ...

not likely sp ... and something i will NEVER do with the total costs and instability and the sheer work involved in such a stupid thing as that - especially with a farm ...

if farm owners WANT to do that - then fine ... but those who will stick to linux - like me - will research ( or commission ) another way ...

no tanx - ill just add a few more powerful cards - and find a better way ...

#crysx

Kinda shitty to try to hide it behind the "I dun wanna release source" lie (the lie being the insinuation that linux support requires source.)

there has to be a better way of doing 'all this' wolf ...

im actually getting disheartened by the whole crypto scene the way it is - and its driving me to think about whether its a good idea to stay in the open like this - or fall into the background and just 'watch' the workings of development and crypto - while utilizing the offers that come our way on occasion ...

is it any wonder why the HUGE farms only get bigger? ...

not releasing YOUR source is one thing - not releasing OUR source is another ... which is exactly what oss is all about - its OURS ( as in the community ) ...

im linux all the way - and i wont change ... stubbornly refuse to give in to the closed system ... paid miners and paid software and paid systems are one thing ...

but to do this that sp is saying he wants to do - that has now got my nose out of joint also ... i wont bend to such things - and agree that it is not right to state such things with the purpose of holding the source code for private use only ... im a supporter of both oss AND the devs ... you know this - sp knows this - the community who know what im about know this ...

but thats statement is ludicrous ...

i just need to find and settle in my new place - and rebuild the new farm ... only a few months away ...

then we can talk business ...

#crysx

Most big miners run nix, this means farms. Most small miners are running Windows as it's easy to use and doesn't require a degree to fix.

I've not seen any stability issues in Windows in all the time I've spent mining. It will hash slower, but now days that seems negligible except for some weird niche cases (and sometimes it goes the opposite direction too).

Big miners get bigger because they have private kernel developers working for them and/or they have public private miners working for them (like Wolf0). With high entry fees to get a kernel, if they will sell it to you at all and you know they're selling it, most small miners are losing ground. This is why I pushed so much for a nice public miner with a fee. That's accessible to anyone, at any level, big or small.

This aside, its seems as though most developers that will work with the public community don't even want to make what the miners need, such as kernels for high demand algos. Right now for instance it's Eth, Spread, and X11 (if that can be brought up to speed). Eth especially right now is getting pushed hard. Miners don't get to choose what's profitable, that's up to the dice of the exchanges. No one can predict that.

Same problem in the cryptonight algo. Doesn't work on widows 10

Can this be fixed? Looking at the memory controller, on W8 it's maxed out... W10 it's at about 50% (which is definitely comparable to the performance I'm getting).

I prefer having a installation on w10 so I can see and report on changes/bugs comparable between algos and fix them

Curiously is anyone having problems with Ethminer and Windows 10? It seems like my w10 970 rig produces 8Mh/s and my W8.1 rigs all produce 17Mh/s... Not sure what's going on here.

Yesterday I upgraded ssd to one gaming rig which had gtx 970 and windows 10. Tested quickly ETH mining and yes, it was only hashing about 7-8MH. Thought I messed something during upgrade but after more testing realized that W10 kills hashrate.

My guess is MS has changed an API in W10 that requires all devs to modify their apps to comply.
They've done it before.

I'm only familiar with this issue on Ethminer, but I understand Cryptonight is a memory-heavy algo as well. The reason for this behavior is known as TLB trashing. The TLB is a unit found on CPU's and GPU's that translates virtual memory addresses into physical addresses. The TLB maintains a table of mappings from virtual memory pages to physical memory pages. When a kernel uses a lot of different addresses in a wide memory space, this table runs full, causing addresses that used to previous cached on the TLB to be removed (trashed) and to have to be retranslated (global memory replay). This causes a huge delay. Apparently there is a difference between Windows 7,8 and 10 with regards to this, most likely in page size. Using smaller page sizes, memory address lookups can be performed faster, but the TLB runs full quicker.

The reason that this didn't happen with Ethminer before, is because of the increasing DAG size. I wrote a test program a while back to identify the allocation size after which this behavior would start happening on any given combination of GPU and OS (it's in OpenCL, but there is no difference with CUDA). If I remember well, there actually isn't that much of a difference between Windows 8 and 10, but that may be different for GPU's that I don't own. For Nvidia hardware with Maxwell 2, the best solution is to use Windows 7 or Linux.

Hmmm... I can go back to W8, I'd just rather not do it in case a issue pops up in the future. There is no way of fixing this? I don't know enough about TLB usage to offer productive input on that.

Speaking of memory hard algos. I just tried Monero on my 970 on both w8 and w10, they produced very similar hashrates. Based on what you're talking about, this bug should be present in Monero as well? This could also be because Cryptonote was never optimized on Nvidia GPUs, but I assume it would manifest itself in some way.

[djm34]

Private kernal for sale. 0.1BTC

Release 2 sp-mod private (750ti) (faster than release 78)

x11: +2.4%
x13: +5.4%
x15: +4.5%
lyra2v2: +6.45%
quark: +3.2%
qubit: +2.3%

I wish I could code cuda.

I have added 2-300khash in the quark algo on gtx 970. Now peaking at 19.45mhash with +155 on the core.(g1 gaming). Will be included in sp-mod private 3

Ppl want a linux version. I don't want to release the sourcecode. So no linux. Switch to windows, or loose hashrate:)

wow ...

so you are willing to 'lose' the support of linux miners to try and push them towards windows? ...

not likely sp ... and something i will NEVER do with the total costs and instability and the sheer work involved in such a stupid thing as that - especially with a farm ...

if farm owners WANT to do that - then fine ... but those who will stick to linux - like me - will research ( or commission ) another way ...

no tanx - ill just add a few more powerful cards - and find a better way ...

#crysx

Kinda shitty to try to hide it behind the "I dun wanna release source" lie (the lie being the insinuation that linux support requires source.)

there has to be a better way of doing 'all this' wolf ...

im actually getting disheartened by the whole crypto scene the way it is - and its driving me to think about whether its a good idea to stay in the open like this - or fall into the background and just 'watch' the workings of development and crypto - while utilizing the offers that come our way on occasion ...

is it any wonder why the HUGE farms only get bigger? ...

not releasing YOUR source is one thing - not releasing OUR source is another ... which is exactly what oss is all about - its OURS ( as in the community ) ...

im linux all the way - and i wont change ... stubbornly refuse to give in to the closed system ... paid miners and paid software and paid systems are one thing ...

but to do this that sp is saying he wants to do - that has now got my nose out of joint also ... i wont bend to such things - and agree that it is not right to state such things with the purpose of holding the source code for private use only ... im a supporter of both oss AND the devs ... you know this - sp knows this - the community who know what im about know this ...

but thats statement is ludicrous ...

i just need to find and settle in my new place - and rebuild the new farm ... only a few months away ...

then we can talk business ...

#crysx

Most big miners run nix, this means farms. Most small miners are running Windows as it's easy to use and doesn't require a degree to fix.

I've not seen any stability issues in Windows in all the time I've spent mining. It will hash slower, but now days that seems negligible except for some weird niche cases (and sometimes it goes the opposite direction too).

Big miners get bigger because they have private kernel developers working for them and/or they have public private miners working for them (like Wolf0). With high entry fees to get a kernel, if they will sell it to you at all and you know they're selling it, most small miners are losing ground. This is why I pushed so much for a nice public miner with a fee. That's accessible to anyone, at any level, big or small.

This aside, its seems as though most developers that will work with the public community don't even want to make what the miners need, such as kernels for high demand algos. Right now for instance it's Eth, Spread, and X11 (if that can be brought up to speed). Eth especially right now is getting pushed hard. Miners don't get to choose what's profitable, that's up to the dice of the exchanges. No one can predict that.

Same problem in the cryptonight algo. Doesn't work on widows 10

Can this be fixed? Looking at the memory controller, on W8 it's maxed out... W10 it's at about 50% (which is definitely comparable to the performance I'm getting).

I prefer having a installation on w10 so I can see and report on changes/bugs comparable between algos and fix them

Curiously is anyone having problems with Ethminer and Windows 10? It seems like my w10 970 rig produces 8Mh/s and my W8.1 rigs all produce 17Mh/s... Not sure what's going on here.

Yesterday I upgraded ssd to one gaming rig which had gtx 970 and windows 10. Tested quickly ETH mining and yes, it was only hashing about 7-8MH. Thought I messed something during upgrade but after more testing realized that W10 kills hashrate.

My guess is MS has changed an API in W10 that requires all devs to modify their apps to comply.
They've done it before.

I'm only familiar with this issue on Ethminer, but I understand Cryptonight is a memory-heavy algo as well. The reason for this behavior is known as TLB trashing. The TLB is a unit found on CPU's and GPU's that translates virtual memory addresses into physical addresses. The TLB maintains a table of mappings from virtual memory pages to physical memory pages. When a kernel uses a lot of different addresses in a wide memory space, this table runs full, causing addresses that used to previous cached on the TLB to be removed (trashed) and to have to be retranslated (global memory replay). This causes a huge delay. Apparently there is a difference between Windows 7,8 and 10 with regards to this, most likely in page size. Using smaller page sizes, memory address lookups can be performed faster, but the TLB runs full quicker.

The reason that this didn't happen with Ethminer before, is because of the increasing DAG size. I wrote a test program a while back to identify the allocation size after which this behavior would start happening on any given combination of GPU and OS (it's in OpenCL, but there is no difference with CUDA). If I remember well, there actually isn't that much of a difference between Windows 8 and 10, but that may be different for GPU's that I don't own. For Nvidia hardware with Maxwell 2, the best solution is to use Windows 7 or Linux.

Hmmm... I can go back to W8, I'd just rather not do it in case a issue pops up in the future. There is no way of fixing this? I don't know enough about TLB usage to offer productive input on that.

again with these too long message to edit...  

just to react a bit: there is no high demand algo, it is just a question of timing and you can't switch project in the middle of the project because of some p&d scheme going on at an instant t on some unknown coin.

Second, some of you (especially you in fact ) need to realize that hashrate can't be increased indefinitely. We know where it is possible (roughly) to get some improvement but for some algos it would be too much work (hence not profitable for us) to develop. For ethereum,  development is stuck by the size of the dag file and nothing can really be done about it, because it is way too large for most of the cards... the alternative would be to recalculate part of the dag element (actually I tried it...) but it is then too slow, because there are very large loop...)
So no matter how much you want a better eth miner, there are constraints which limit any kind of development at that level.

[ldw-com]

Most big miners run nix, this means farms. Most small miners are running Windows as it's easy to use and doesn't require a degree to fix.

I've not seen any stability issues in Windows in all the time I've spent mining. It will hash slower, but now days that seems negligible except for some weird niche cases (and sometimes it goes the opposite direction too).

Big miners get bigger because they have private kernel developers working for them and/or they have public private miners working for them (like Wolf0). With high entry fees to get a kernel, if they will sell it to you at all and you know they're selling it, most small miners are losing ground. This is why I pushed so much for a nice public miner with a fee. That's accessible to anyone, at any level, big or small.

This aside, its seems as though most developers that will work with the public community don't even want to make what the miners need, such as kernels for high demand algos. Right now for instance it's Eth, Spread, and X11 (if that can be brought up to speed). Eth especially right now is getting pushed hard. Miners don't get to choose what's profitable, that's up to the dice of the exchanges. No one can predict that.

I agree on the part where devs modify whatever they feel like. In a way, it's their right to do so. If they want to make more money. yeah, they should mod whatever is most profitable. And there are out there that do so. But mostly not in public ;-)

And as stated above, in some cases, it just isn't worth the time/effort.

[Genoil]

Genoil, some ETH coming your way. Been using your miner since last summer and never donated.

0xf01f74a1eb99be1aee7f58b6f1e83d89524d374babbcda2cd6f576c0d61c466d

Thanks a lot!

[sp_]

This aside, its seems as though most developers that will work with the public community don't even want to make what the miners need, such as kernels for high demand algos. Right now for instance it's Eth, Spread, and X11 (if that can be brought up to speed). Eth especially right now is getting pushed hard. Miners don't get to choose what's profitable, that's up to the dice of the exchanges. No one can predict that.

I am making miners for high demand algos.

I have 4 private miners for the people who donate.

1. 0.1BTC: Pentablake +100-120%
2. 0.1BTC: Cryptonight +10%
3. 0.1BTC: Spreadcoin +10-20%
4. 0.1BTC: All nicehash algos optimized. 0-7%  (x11 +2.4% (faster than release 74 ) on the 750ti)

[ZeroFossilFuel]

I'm having trouble getting ccminer.exe to run in WINE. I looked through the threads a bit after failing to get it to work. Seems there are mixed results out there.

Code:

wine ccminer.exe -q -a quark -o stratum+tcp://stratum............

get error

Code:

Driver does not support CUDA 5.5 API! Update your nVidia driver!

Card is GTX-750ti, OS Xubuntu 14.04, CUDA 7.5, nVidia driver 352.68. Pretty sure that's all up to date. What am I missing?

[djm34]

I'm having trouble getting ccminer.exe to run in WINE. I looked through the threads a bit after failing to get it to work. Seems there are mixed results out there.

Code:

wine ccminer.exe -q -a quark -o stratum+tcp://stratum............

get error

Code:

Driver does not support CUDA 5.5 API! Update your nVidia driver!

I'm running Xubuntu 14.04, CUDA 7.5, nVidia driver 352.68. Pretty sure that's all up to date. What am I missing?

why do you even want to run it under wine... you have to compile it for linux...