Want legit 7970 testing/benchmarking and tuning for cgminer and Diablominer?

[DiabloD3]

It took basically three people to make GPU mining what it is now. You seriously underestimate the power of a single developer.

Wrd, if anything that 7970 should go to ArtForz first, as far as development is concerned.

Sure, but he seems to have quit development. That, and he has already left GPU mining and has funded his own ASIC production thanks to his gigantic GPU farm, so I'm pretty sure he could afford a few dozen 7970s if he so wanted them.

[1714039152]

1714039152

[1714039152]

1714039152

[1714039152]

1714039152

[1714039152]

1714039152

[1714039152]

1714039152

[1714039152]

1714039152

[simonk83]

I agree with the general consensus in this thread.

I'm definitely not going to contribute to buying you a free video card just so we can get some early stats when we can just wait for people to buy them themselves and upload their stats for free.

I think I'll put my contribution towards a video card of my own, thanks.

Who cares whether you coded DiabloMiner or not? You get donations for that separately. Why not put those towards buying the card?

So how are they going to upload stats? Using an untuned kernel on a miner that does not work on 79xx at this time? Who is going to fix the miners so they work? Without a 79xx, it surely is not going to be me.

Con will fix cgminer as its his baby.  He gets plenty of donations as plenty of people use his miner.

[rjk]

I support the idea of passing around the card to other developers for their own development, benchmarking, and testing. Perhaps they could all be asked nicely to always leave it at stock clocks.

Then, once the 79xx series is sold out due to demand, sell the card used and distribute the profits 

[film2240]

i think I may just wait for reliable results to be published.I then hope to republish them onto my blog so a hardware review can be done without too much trouble (due credit from the original review will of course be given) if he/she oks me republishing it.

I wonder how review sites can get a free GPU for testing purposes as that would help with the hardware review on my blog?

[Fiyasko]

I support the idea of passing around the card to other developers for their own development, benchmarking, and testing. Perhaps they could all be asked nicely to always leave it at stock clocks.

Then, once the 79xx series is sold out due to demand, sell the card used and distribute the profits 

shiiipiiinnnggg cooossssttttssss

[norulezapply]

I agree with the general consensus in this thread.

I'm definitely not going to contribute to buying you a free video card just so we can get some early stats when we can just wait for people to buy them themselves and upload their stats for free.

I think I'll put my contribution towards a video card of my own, thanks.

Who cares whether you coded DiabloMiner or not? You get donations for that separately. Why not put those towards buying the card?

So how are they going to upload stats? Using an untuned kernel on a miner that does not work on 79xx at this time? Who is going to fix the miners so they work? Without a 79xx, it surely is not going to be me.

Also, how many donations do you actually think I've gotten? Its about $30 USD total over the past year.

Get a job?

+1. Once again, why should we pay for you to get a new video card? Kernels will be released which are optimized for the 7xxx series whether you code them or not. I'm sure you could buy one with your own money if you really wanted to support the community.

[gat3way]

I think it's a good idea not to deliver kernels optimized for GCN at all. Since there appear to be no more than 7-8 people here that can code that, it won't be that hard

[rjk]

Kernels will be released which are optimized for the 7xxx series whether you code them or not.

What makes you so fanatically sure of this? I'm sure the coders capable of this realize the potential benefits of an architecture-optimized kernel, and it isn't unfathomable that they would keep it to themselves.

[norulezapply]

Kernels will be released which are optimized for the 7xxx series whether you code them or not.

What makes you so fanatically sure of this? I'm sure the coders capable of this realize the potential benefits of an architecture-optimized kernel, and it isn't unfathomable that they would keep it to themselves.

For one thing, the benefits more than likely won't be great enough to warrant keeping it to themselves.

[shakaru]

because we are all beging for a 7970 now. I would also like one on someone elses dime. All donations to buy me a 7970 should sent to Theymos with the message "This is a donation for the forum" attached so I know what to reply with.

[gat3way]

First thing is that _NO_ miner would work on GCN without modifications. The reason is simple: the BFI_INT replacement routine. GCN is a completely different architecture and so is the opcode. So no miner would produce correct results (if they produce any results anyway).

This needs to be changed.

Then GCN architecture puts an end to the need to vectorize. Any current kernel would be inefficient on GCN without a rewrite.

In fact without a rewrite, you are not getting slower, unoptimized version of the miner for the GCN hardware. You are not getting a working miner at all.

[DeathAndTaxes]

First thing is that _NO_ miner would work on GCN without modifications. The reason is simple: the BFI_INT replacement routine. GCN is a completely different architecture and so is the opcode. So no miner would produce correct results (if they produce any results anyway).

This needs to be changed.

Then GCN architecture puts an end to the need to vectorize. Any current kernel would be inefficient on GCN without a rewrite.

In fact without a rewrite, you are not getting slower, unoptimized version of the miner for the GCN hardware. You are not getting a working miner at all.

Every miner I know has an option to disable BFI_INT patch otherwise they wouldn't work for Nvidia cards.

So while results may not be optimized the 7970 would work just fine "out of the box" with most (all?) current miners.

[gat3way]

Nice, that would explain why experimental results are just a bit better than 6970.

One more reason why optimized code for GCN should not be released in public

[DiabloD3]

First thing is that _NO_ miner would work on GCN without modifications. The reason is simple: the BFI_INT replacement routine. GCN is a completely different architecture and so is the opcode. So no miner would produce correct results (if they produce any results anyway).

This needs to be changed.

Then GCN architecture puts an end to the need to vectorize. Any current kernel would be inefficient on GCN without a rewrite.

In fact without a rewrite, you are not getting slower, unoptimized version of the miner for the GCN hardware. You are not getting a working miner at all.

Every miner I know has an option to disable BFI_INT patch otherwise they wouldn't work for Nvidia cards.

So while results may not be optimized the 7970 would work just fine "out of the box" with most (all?) current miners.

Detecting VLIW5/4 and only running bfi_int on those is simple. Plus, 2.6 is supposed to fix the bfi_int bug, although I have not tested it, but I've been told it should actually work correctly with bitselect().

GCN does not end the need for manual vectorization, it just makes the helical wound uint2 vectorization we use now less optimal. Most likely DiabloMiner already has an (more) optimal vectorization already available, but without a GCN card myself, theres no way to find out.

[LoupGaroux]

So if you truly believe you have a better moustrap- invest in yourself and buy a card, and sell the resulting improvements as a new commercialized version of your miner. The world will beat a path to your door and provide you with a revenue stream to keep up support and future improvement on your product.

Or, as suggested before, if you want an evaluation copy for legitimate evaluation and benchmarking purposes- provide suitable credentials and documentation to the manufacturers and they will ship you a card for testing and developmental work. In fact, you could probably get on the bleeding edge and receive red cards for testing of release candidates. You might even have something valuable to suggest to them in the testing process that would make their card better.

Acting petulant about getting the community to buy you one is probably not the best strategy. With the card in the wild it will be a matter of days before one of the enormously talented coders tweaking in the community fine-tunes the code anyway.

[gat3way]

It does not (tried personally) - bitselect is still not mapped to BFI_INT. Although it is now exposed at IL level at last.

[DiabloD3]

It does not (tried personally) - bitselect is still not mapped to BFI_INT. Although it is now exposed at IL level at last.

Heh, still, we won't need it on 79xx, the existing BFI_INT code can stay.

[gat3way]

What makes you think you won't need it?

[DiabloD3]

What makes you think you won't need it?

No bfi_int instruction on that arch, apparently. Unless there is a useful replacement, we use the normal code path.

[gat3way]

You are wrong about that. There is a BFI intruction in the GCN architecture - v_bfi_b32. Strange though, there is no "s_" equivalent on the scalar unit. But it is there. I have occasionally seen that in my Tahiti kernels and you can also grep it from libaticaldd.so.

Now bitselect() does not map to v_bfi_b32 for sure, yet some patterns of the kind (a&b)|(~a&c) where part of the variables are constants do produce bfi code.

I cannot patch the binary of course because the architecture is different and the opcodes are different as well. Trying to patch the binary the same way I do for VLIW kernels does nothing. I guess until the 79xx ISA reference comes out, using bfi on GCN hardware would not be possible. Unless they finally map bitselect to bfi of course.