Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 596. (Read 5806103 times)

No idea  Only time someone reported something along these lines they discovered the display GPU wasn't actually the one they thought it was in cgminer. The GPU numbers don't always make sense and are just whatever OpenCL tells cgminer.

Alright. Do you maybe know why it's doing that? I know I used to use 2 threads back when I was on Windows and it ran just fine. Also it seems to be just the display GPU that suffers, but being on dynamic intensity, it's supposed to set itself to 1 thread anyway, right?

Hey guys! i add a 5870 and a 5830 running perfectly on cgminer, but when i added a 5750 via a x1 extender cable cgminer crashes everytime i try to open it. I tryed doing no overclocking to the cards etc etc and nothing works. Some help please!



after that error msg cgminer crashes.

What went wrong here?

It usually adds only a small amount to the hashrate in the order of 1-3% depending on device.

Are there any downsides to running 1 thread per GPU on a normal pool? Every time I try enabling that second thread, my hashrate drops severely and my system becomes really slow.

No

No, Win7 doesn't suspend tasks of inactive user.
It does make something weird with drivers when switching between users but again it isn't full termination or suspend.
Anyway 2.3.1 have enough luck to work well behind the scene and behave alive when I switch to the user where It runs.

I wonder if something was changed between 2.3.1-2 and 2.3.2 and caused such behavior?

Kinda hard to test GPU mining when I didn't have any working GPUs; I think I did the best reasonably expected given those circumstances. That's solved now (I have 1 working GPU, and another on the way).

I added work-restart support to the Icarus driver, and you started demanding I had to refactor the (admittedly broken-by-design) internal structure that it used. Just because I'm touching a piece of code doesn't mean I want to refactor the existing code it's using (and when/if I do, it certainly doesn't belong in the same commit). As I told you, I wanted to talk to Con before changing it, since I wasn't very familiar with it. As it turns out, this particular code goes back to Jeff Garzik and cpuminer, and Con seems fine with the refactor you suggested.

Sorry, I had no reason to expect that fixing the hashrate measurement in the Icarus driver would somehow break the actual share-finding. It was a subtle bug, one you admit would only be noticable after hours of mining with it.

I finished writing that JSON API refactoring I proposed to you, and was kindof hoping you could look it over and see why I think it's a good idea. Feel free to take your time; it'll just be sitting there waiting for your input when you get back, not merged until you give it a thumbs up.

OK, I take that back.
After spending some time arguing with luke-jr about bugs in his pull requests that he wouldn't listen to
I'll say there are issues with accepting his code.

In the past he hasn't tested (or even compiled) some of the changes he requested, I know he doesn't test run the code on windows by his own admission, and having to argue with him about why a code bug is a bug is a complete PITA.
(and then have him say that it's my bug because I have a similar code change (written better) that I know has the bug that I haven't sent the code to be added - because I know it's a bug and haven't worked out the fix yet in my unsent code - is even more annoying )

He likes to label a piece of text displayed by cgminer as a bug if it isn't what he wants (that one will probably be in the next release)
But a real code bug that he put in as a pull request - he thinks that's not possible.
(until later he sees exactly what I've told him is already on his own screen - he just didn't test it properly)

I like working on the API (and Icarus.c) coz noone else is messing with it or making stupid changes to it (and also the donations for the API are high compared to other donations so far - in real terms they are not a lot - but compared to other stuff around here, they are good) but there are a lot of changes that I see luke-jr now trying to push on those two and I don't trust his code ethic (or his code)

I'm sure this will not affect anyone, but I'll take a break from the code for a day?, week?, month? and see how this latest set of changes mess things up ... or wait for them to disappear.

I don't have any control at all over the cgminer code, that's all ckolivas' decisions, so it shouldn't matter to anyone anyway.

More specifically the DISPLAY DRIVERS are user mode drivers (in WinXP they were kernel mode drivers).  When user switches they are shutdown.  When new user logs in they are started up under the new user.  No drivers = no access to GPUs.  There is no work around that can be done by the developer or end user.  For stability reasons display drivers are now user mode (as of Windows Vista) and that will never change going forward.  There are advantages like having a driver crash and you just get "AMD Catalyst stopped respond, driver restarted" message instead of a BSOD.  Also crashing applications like games are more likely to crash back to the desktop then halt the entire system.

This is a Windows 7 issue, it has nothing to do with cgminer.  W7 doesn't operate the same as XP did, anything that the user has running is suspended when that user is logged out or another user is switched to.  In XP you could continue to have programs running with a logged out user, not in Win 7.

Thanks extremely Got it
(and yep it's in ckolivas' git now too)

I don't know about others but for me the display of cgminer is great.

Sounds to me like nit picking

The code is much more important than the display.

If you want pretty colors and some other crap in the display then feel free to code it yourself ...

Well you'll have to look elsewhere to see what permissions you extracted the zip file with or something like that, because cgminer has no clue about users or permissions like that.

did you set the intensity too high? I set mine to 4 on my faster cards and 2 on my slower cards
I never use d

I'm sorry but this is virtually impossible to do reliably (the GPU part). OpenCL doesn't tell us what the devices are. cgminer tries to guess with ADL and it's not entirely reliable.

I don't know O_o.
But when I return back to the user running cgminer I see that no more shares were submitted since I switched out.
It just staying still.

Using this example/option from another thread....



Is there currently a supported API call in 2.3.3 that will return GPU MODEL or GPU FAMILY ?

Thank you. 5BTC sent.