Have you tried loading your card with a 3D game?

Big hydro is a problem nowadays. You will never have a chance at it unless you are a government.
Hydro can still get a lot smaller and distributed, see

http://www.theguardian.com/environment/2012/jul/19/hydroelectric-turbine-energy-london

I would say that 350k for that is very expensive, I've seen bigger plants manufactured at much lower price.

The last models require as little as two years to pay back for the energy required to build them. Most materials are largely available and highly recyclable. Historically, the main source of pollution has been the lead used as solder but this should have been phased out completely by now. Most panels built in the 90s will be still churning out juice. I've seen one built manually in the 70s, the owner claimed it was still functional albeit at very low power.

Dudes, right now
grsmyr at 271 MH
qubit at 71 MH

Both are ~ 7 280x... 

Pretty.
Some notes.
178 GW is an installed capacity. For PV they should be talking about GWp (peak capacity at normal test conditions).
1GW over 1 hour gives out 1 GWh so running 33 dispatch-able plants 360 days/year 24 hours will produce 285'120 GWh ~= 285 TWh/year.
PV capacity depends on installation as well as environmental factors. It is often sub-optimally installed. By my experience with plants around here, that PV capacity could output ~190 TWh/year (1100 hours of "nominal" production).
This implies a lot of the PV capacity is either sub-optimally installed or optimally installed in places where the yeld is much lower.
Albeit I know Germany has installed a lot... and even northern countries I still have difficulty with that gap. I'm very surprised!

Odd, I've seen much lower prices on 1MWp plants years ago... maybe I'm confusing that with panel price only... I wonder what plant sizes are being considered here.

/me is confused.

Right now I would be more than 2% of the Qubit network and more than 3% of grs-myr... that's going... somewhere. I will enjoy the feel of finding blocks myself I guess.

It's a possibility. I am positive the distribution of math operations VS mem access has a major incidence in GCN; the OpenCL AMD driver is super fast but also very stupid.

Pretty!
How are your speed with those? Are you using the .cl or the .bin-s?

Some kind of 'burn' thing? I think MYR and DBG should have really merged but as it stands now there's no real point in even trying.
BTW, one hour ago I was almost 2.5% of the (estimated) grs-myr network hashrate. Which means there could be just an handful of hi-end cards online.

I've looked at the resources. Considering the linked threads are 1) in German 2) hundreds of messages long I cannot be 100% sure I got it completely.

What I can tell you is that I've observed considerable lower than expected memory performance on GCN1.0 even with much smaller buffers. I think it is also worth noticing before 'compute on GPU' became a thing graphical resources always had an upper bound (!= from CL max alloc). It is my understanding no such limitation shall be in place at that point (and it should be bigger than 1GiB anyway)...
I'm still very surprised this hardware issue to manifest itself at such big bounds (unless the historical limitation still applies).

Leaving aside the max alloc, have you tried how varying the stride affect result (for K MiB buffer)?

While this is technically correct I can tell from experience some drivers will still keep the address range as reserved, apparently this has some benefits for driver mangling (I can see how assuming different range <--> different resource can help).
Beware, CUDA is way more than your GPU or CPU, sometimes it goes through some heavy magic.
How is the memory consumption being measured?

In the last few days I read more than one user having issues with Crimson... I'm inclined to not upgrade yet.
In the meanwhile if someone can give a go to my miner and tell me if it still works it would be nice to know.

New driver comes with a tweaked compiler which implies different instruction scheduling policies. Both differences seems to be in range for this kind of issues (Quark is a bit extreme I admit). In particular, the AMD compiler has historically been way too conservative on computation: this would often result in lower performance when latency-bound. Assuming Ethereum is this kind of problem it would benefit from a tweaked compiler. By contrast compute-bound kernels would get slower.

Interesting.
Please, can you share links to all discussions?

Considering OpenCL is possibly higher level than GL ever was, I'm quite surprised one pinpointed an hardware construct issue especially as GPUs are traditionally managed and there's a huge gap between different OS which in my experience should not be there for HW constructs... odd.

I have a 1GiB card so there's little I can do. I will try to take a look in the next few days if I can set apart some time. Initial analysis in CodeXL gave me inconsistent results.

Have you investigated different access patterns?

Side note: Ripple labs was present at cppcon 2015 with very interesting and generic presentations.

Uhm... quite a stretch (and I focus on Windows mostly). 

Please everyone flood the Linux message boards and ask them to work on the unified driver model for GPUs. We have been asking it for more than a decade now and apparently they still don't consider it a priority. If the GPU drivers are still messy that's also due to this issue. More IHV work --> less budget for streamlining.

I just checked and it turns out I'm almost 2% of the grsmyr network today so I'm afraid I'm not quite on the same line of thinking.
Truth to be told, I haven't hit a block yet. Perhaps the network hashrate estimation is just broken, let's hope so!

I guess you're just doing an example but I don't think DGB is malicious.
I approve usage of yescrypt but I'd rather not fork just for that.

Because those algos would predate the users from current GPU algos and some would get lost in the process of transitioning. Furthermore, as the hashrate from each algo becomes smaller and smaller their added value decreases as it becomes increasingly easier to hijack one algo in particular.

There would be considerable problems in informing users what X11 kernel to use. We can at least be moderately sure a public X11 kernel to be very decent compared to the closed ones (that's speculation).
I am moderately sure a better private kernel of GPU cryptonight to exist and I'm inclined to speculate it could be 3x faster or more so adding it would likely be counter-productive at least short term.

What is the difference in this case? In both cases it seems to me grs-myr would be out and yescrypt in.
Because unless there's a very good evidence a feature is bad, pulling out stuff will cause the corresponding user base to be alienated and start a transition. In general features don't get removed 'just because'. If grs-myr is currently on FPGA then let the guys have their place; it is fine.

A good objection would be fragmenting the hash power too much. To that degree I would say we should unify everything that is not ASIC but that's an extreme consideration.

Related:
In the last few days I mined some grs-myr on P2Pool and enjoyed the massive payouts - over 161 MYR! Unfortunately, it seems I have pissed off the constant ~1MHs user who typically got 490 MYRs out of each block and now it's gone. It is unlikely I will mine in the next few days and so far P2Pool has not found a block in days. Shall p2pool not find a block soon, I encourage someone to point some mining there.

They measure different things and give different results. Yes, Sandra most likely gives better results. For whatever that means to you.

grs-myr is chained too.
Considering the original idea of qubit was to be the CPU algo, swapping it for yescrypt might sound like a big deal... except qubit is currently the go-to algo for many GPU users.

What is the situation with skein BTW? A few months ago it still needed its own miner and wasn't integrated in sgminer yet. This makes the transition a bit problematic.

I don't think dropping algorithms is good btw.

Have you tried the original super-slow version by Vehre? That's the only one that ever worked for me.