NVIDIA Kepler speculation thread

So, I am not sure if AMD discloses this: Your activity counters, they use actual activity measures or do they use an extrapolation from analyzing the code that's supposed to get executed in a future cycle?
At least for the VLIW architectures, the shader compiler spits out some throttle numbers, iirc. But I have never seen anything in there (it always returned zero throttling), so maybe that is not used anymore (or only for the old architectures lacking a solution in hardware) or it is still some additional input to the algorithm and I didn't look at the right code sequences.
The alternative of analyzing the code on the GPU before it runs doesn't appear to be very useful to me compared to the necessary effort. Such a feed-forward only makes sense if your feedback is too slow or the hardware isn't qualified to run at the current frequency for all code sequences (the power circuitry should easily buffer power spikes in the µs regime and thermal behaviour is way slower).
 
Last edited by a moderator:
since they actually miss one very important criterium for qualifying as a power virus
Definitions... In this case a very informal one, I'm not a marketting guy, yet, everytime I hear or talked abou power virus the only requirement is making the chip draw a really lot of power, maybe the name is silly, but if everyone understand all is fine.
 
Definitions... In this case a very informal one, I'm not a marketting guy, yet, everytime I hear or talked abou power virus the only requirement is making the chip draw a really lot of power, maybe the name is silly, but if everyone understand all is fine.

To me, a power virus is a piece of software whose main purpose is to make the targeted chip draw as much power as possible, irrespective of the work done—if any work is indeed done.

I don't find it particularly silly.
 
To me, an important part of the definition of a (software) virus is that it does something behind your back, something you usually would not want it to do. Interestingly enough, Furmark was a benchmark before it became programma non grata with AMD and Nvidia and they decided to start calling it a power virus as opposed to a stress test - probably in order to keep people away from using it (who'd want to execute a "virus" on their system?).

Anyway, there are more benchmarks that behave like this, but I've learned the lesson. In future, I'll only refer to those as "stress tests" - and let the IHVs dig through all the stuff out there themselves.
 
For starters, it is highly programmable, so we can program it to be deterministic or non-deteriministic on a per device ID basis if need be; additionally updates to the entire thing are just delivered via Catalyst. Seconly, we have per-MHz control over the clock and a fast sampling frequency. A fast sampling frequency, over time, is going to be less prone to error than external power sampling because of the lag of the feedback loop - NVIDIA have already talked about the guardband they've had to put on.
Whether or not this is better depends entirely upon the nature of the errors. Yes, if you can guarantee that your systematic errors are small compared to your statistical errors, faster sampling is likely to lead to better results. But if you can't make that guarantee, if you have an overall bias in your fast sampling, then the picture is no longer clear.

Since I see no conceivable way to test all possible usage situations, I really really doubt that the situation is as clear-cut as you state here.
 
So, I am not sure if AMD discloses this: Your activity counters, they use actual activity measures or do they use an extrapolation from analyzing the code that's supposed to get executed in a future cycle?
These are activity counters on the chip, this isn't software that is trying to analyse code to figure out what is going on. IIRC there are some pretty interesting tools in the developer software that actually outputs a lot of activity chip activity traces.
 
These are activity counters on the chip, this isn't software that is trying to analyse code to figure out what is going on. IIRC there are some pretty interesting tools in the developer software that actually outputs a lot of activity chip activity traces.
For what it's worth, if what you're interested in is thermal dissipation to control clock speed, the counters are useful in approximating that, but aren't as good as actually measuring the current draw.

Of course, the overall current draw doesn't help if you have hotspots that you need to worry about...
 
These are activity counters on the chip, this isn't software that is trying to analyse code to figure out what is going on. IIRC there are some pretty interesting tools in the developer software that actually outputs a lot of activity chip activity traces.

Yeah, I think I got it this far that they are not software. But what I wasn't sure about is, whether they counted activity of the execution units or some kind of throughput in the schedulers. So, when counting activity in the execution units themselves, Powertune also reacts to perceived load that is already happening, albeit of course in a much much faster way than measuring power rails every 100 ms. :)

I wonder: Does Powertune react immediately after detecting an, let's say non desireable workload or does it leave the execution units running deliberately for a few tenth's of a second in order to really take advantage in thermal inertia or lag, as the cooling solution would not be saturated after a chip doing 1/10th of a second an unthrottled load like furmark.
 
GK110

Apologies if this has been linked already:

http://www.hpcwire.com/hpcwire/2012..._hpc_version_waiting_in_the_wings.html?page=2

According to Gupta, the second Kepler implementation will include a lot of capability not present in these first gaming-oriented products. In particular, it will have a lot more double-precision capability (which is not required for most graphics applications) and include new compute-specific features. And of course the raw power of these chips will be quite a bit higher than the mid-range graphics version introduced this week.

We now return you to your regularly scheduled Turbo discussion :)
 
Apologies if this has been linked already:

http://www.hpcwire.com/hpcwire/2012..._hpc_version_waiting_in_the_wings.html?page=2



We now return you to your regularly scheduled Turbo discussion :)


And of course the raw power of these chips will be quite a bit higher than the mid-range graphics version introduced this week.

Correction. The 500$ mid range graphics version! :devilish:

Also they mention Q4 for a production start of BigK? Oookkkeeeyyyy so any news on the GTX 670? :p
 
Correction. The 500$ mid range graphics version! :devilish:

Yeah, anytime they want to bring a $200 price drop.... :)

Also they mention Q4 for a production start of BigK?

One hopes for a non-calendar definition of Q4. There is also some concern that NV will be targeting two different markets with two different chips. That's not good for compute, insofar as there is a compatibility problem between $1500 and my pocketbook.... For that reason, GCN is more attractive, except that the ATI card I currently have is driving me nuts :(

I don't actually need the DP throughput, but I do want a dynamic-gop, two-pass encode solution that plays nice with my editor/titler.... 4x realtime (or whatever) means nothing when I can't use the results.
 
Correction. The 500$ mid range graphics version! :devilish:

Also they mention Q4 for a production start of BigK? Oookkkeeeyyyy so any news on the GTX 670? :p

They speak about Tesla.

But i dont know if it is a good or bad news for a next big Kepler. ( gaming cards ).

Look like they will definitively separate HPC, computing, gaming, and i dont like the term: < Second implementation > they have used. This really seems to point to a refresh, not a bigger version unreleased.
 
nVidias next fiscal Q4 is later than this years calendar Q4, you sure about hoping for non-calendar definition of Q4? :devilish:

Clearly I'm hoping for a non-nvidia, non-calendar definition of Q4. Perhaps I'm hoping for a definition of '4' that's a little closer to '2' :LOL: Well, at least we'll have some idea of what's what in Q2. :sigh:
 
To me, an important part of the definition of a (software) virus is that it does something behind your back, something you usually would not want it to do.
If I intentionally execute a computer virus it doesn't becomes another type of software, if it does something I want or not is not a definition for virus.

The only definition for computer virus I have ever seen is of a software being able to self replicate, the "power virus" is a exception to this definition, the only I remember.

There is another name for software doing bad things to your computer: malware.

To me, a power virus is a piece of software whose main purpose is to make the targeted chip draw as much power as possible, irrespective of the work done—if any work is indeed done.

I don't find it particularly silly.

I think it is silly because it does not have the same definition of a computer virus, wich is the ability to self replicate.
 
Back
Top