Derek Smart on ATI Driver issues

... which is the major reason the design behind D3D sux. I can't see why they still in DX8 use this Lock/Unlock approach. It's more painful to code for and provides no advantage over the passive interface used in OpenGL.

 

I think that would be a good conservative estimate for increase in heat vs. clock speed, but the real number will be somewhat higher. In general CMOS has very low power consumption in the "static" i.e. low frequency or DC case, so that means most of the power is dissipated in the transition between states. Hence, if you up the clock frequency (i.e. increase the number of voltage transitions for a given time period) your power dissipated as heat should at least increase proportionally.

However, the interconnecting transmission lines have a series resistance / shunt capacitance ratio that act as a delay line. Conversely, this can be seen as a low pass filter with some corner frequency. A pure clock edge (such as a square wave) has an infinite number of frequency harmonics. If you filter out these harmonics in a low pass filter, the clock edge will look more rounded (for instance, if you filter out ALL the harmonics, you will have a sine wave instead of a square wave).

If the clock edge becomes progressively more rounded off as you increase the frequency, the transition time between states as a fraction of the total cycle time is also increasing, and it is during this transition time that most of your power is being dissipated. Thus the excess heat generated (and conversely the power that needs to be supplied) would be somewhat worse than linearly increasing with frequency.

Of course, when people are overclocking CPU's they also sometimes increase the supply voltage as well (to attempt to compensate for the greater attenuation along the interconnecting lines), which compounds the heat problem even further.

 

Are you sure that you're rounding the square wave? At least with normal fourier transforms, if you don't have enough elements in the series, you don't end up with a square wave, but, hrm, it's hard to describe...

Here:
As the wave goes up, almost vertically, it doesn't stop once it hits the point it's supposed to. It keeps going up, then does an about-face, comes back down, and again overshoots. It does this a number of times, progressively getting closer to the central value.

Of course, for this to be an accurate description, it would mean that the higher-frequency harmonics would be the ones that are taken away, which makes sense when you think about it: capacitance resists change in current. The higher the frequency, the more capacitance has an impact.

This description also makes more sense as a reason for greater power dissipation, as if the result just becomes "curved" then it should put out the same amount of power, but just do it over a longer period of time. By oscillating back and forth over the target value, it's creating much more state change than is necessary.

 

Chalnoth,

What you described is a typical underdamped response curve.

 

Good point Chalnoth. I had assumed that we are at such a frequency that the series resistive effects of the interconnect lines dominates the inductive reactance. I believe this is the case for GPU's, but perhaps not for CPU's (since they are at much higher frequencies).

In general whenever you see a voltage overshoot such as you were describing its a resonant effect which requires capacitive and inductive components. I'll bet the inductive effects (both self and mutual inductances) become very pronounced on CPU's when you get up to the GHZ range. It's no doubt much less of a problem at a few hundred MHz.

 

Yes, thats another way to state it. If the resistive component dominates the inductive component of the interconnect line, it has a low Q, and hence is severely damped. If Q were increased you might get an underdamped response (increasing Q denotes decreasing the resistive component).

The Q of a series RL circuit goes up linearly with frequency (excluding skin depth effects on current flow).

 

darkblu,

might I ask Waht game you were working on at the time you are refering to..?

Or what company, developer you are with now?

 

I'm actually quite proud of myself. I'm a mechanical guy, and know just enough about electrical engineering to kill myself... and my knowledge of computer engineering and digital architecture is even more pitiful. But, his description was a perfect fit for an underdamped system. I know that electrical, fluid, and mechanical systems can be translated from one to another, and that the electrical underdamped response had a mechanical equivalent. So, I worked back from my knowledge of mechanical systems to the equivalent electrical components, and had decided that increased resistance or lowered inductance would dampen the system, and the opposite would be true for low resistance high inductance circuits.

lol, that you have confirmed my conclusion makes me think there's some hope after all for my computer/electrical education.

 

kid_crisis,

When you say Q, do you mean impedance?

 

It avoids implicit memcpys.

-- Daniel

 

bigus -- heh, you're right on as far as I can see! would have guessed you were an EE if you hadn't said otherwise...

saem -- Q is quality factor, which in electronics denotes the "purity" of a reactance (i.e. capacitor or inductor) usually, though in general it can be applied to any kind of resonant circuit.

A completely lossless circuit would have an infinite Q, i.e. it's perfect and has no losses. In actuality everything in the real world has finite Q, even a superconductor has a measureable Q (though it can be in the 100,000's or millions). Well, maybe a Bose-Einstein-Condensate has infinite Q, but who really believes in those anyways? 8)

My guess is that the interconnect lines on a GPU at a few hundred MHz frequencies have Q << 1, i.e. the series resistive component in ohms is greater than the series inductive component (in +j-ohms).

 

The only thing is, I believe the effects that we're talking about aren't just dependent upon frequency, but also the circuit size. I was thinking more about the problems in the memory interface than inside the GPU, as the distance from the GPU to the memory chips is much larger than the distance currents must travel each clock within the GPU.

From what I've learned in E&M, if you double the circuit size, you pretty much halve the realistic max frequency of the circuit.

This says to me that the external traces to the memory in a graphics card running at several hundred MHz aren't much different from the internal CPU traces running at a couple GHz.

Primarily, my line of thinking was that if the signal from the GPU to the memory is represented as a fourier series, then the higher-frequency signals would get "lopped off" by the capacitance, resulting in the underdampted curve described above.

Within the GPU, given the extremely small circuit size, I'm pretty sure you're right that underdamped curves wouldn't be a problem...I just don't see why overdamped ones would be a problem in power consumption.

Quick side note: "circuit size" I used above is the distance a signal has to travel before the new signal arrives, as it were. This basically means that this "rule" doesn't apply to travelling signals, such as those seen in power lines, telephone wires, cable, and presumably serial transfer protocols in PCs like USB and firewire.

 

... on hardware that uses linear buffers, which doesn't exist anymore.
With todays hardware in DirectX when updating a surface we get:

1) App Lock() the surface, driver unswizzles and copies the surface to system memory, alternatively keeps a copy in the system memory.
2) App operates on the memory.
3) App Unlock() the surface, driver copies and swizzles back into hardware's format.

In OpenGL you get:
1) App operate on memory.
2) App passes pointer to driver which swizzles it to hardware's format.

The first approach either takes the same or one more step to perform, it also allows on the fly conversion of data to an internal format without the app needing to specifically write a lot of conversion code. It's actually very likely that an app might want to use another representation of it's data than the API's format. For instance in my framework I pack all mipmap levels of textures into the same memory block, it's much easier for many image operations as I can just to a do{ ... }while(--length) on the whole mipmap hierarchy.

 

Maybe this is a little late in the thread to ask this, but: Who the hell is Derek Smart anyway? I don't think I've ever played any game he worked on (or even read about one). I've never honestly heard about him, except when he's mouthing off about something.

 

I think he made this game called Battle Cruiser 3000 AD. It was buggy. =)

 

I'll second that. Last time I heard of the guy he was preaching off his "soapbox" with basically the same message. I think that he is attempting to pimp out his very buggy game while making a stink about ATI. Funny that. He is the only developer with so much to complain about. Given his history I am surprised ATI bothers with the guy at all.

 

sure. it was an early attempt (started in 1998, ended in 2k) at 3d RTS, named 'trans'. for one reason or another (essentially being low-budgetted for the respective game-market which it targeted and techologically-rushed at that) the title failed with securing a publisher and eventually shared the fate of most pc game titles. you can take at peek at it here http://www.trans-game.com/gamespecs.html , though the shots are from various early versions and most of them for some weird reson have an out-of-order gamma.

since then i've stayed out of the gamedev business, earning my living in other sectors of the software industry. that, oth, has left me with more spare time to spend on my hobby graphics projects.

 

Just curious, but have you ever played a game that was not buggy? If so, let me know, I'd like to play one for once in my life.

 

BC3000AD V1.0 was released in an unfinished state by Take2 Interactive, after they had become tired of waiting for a game they've funded for 7 years....


Hmmm me being somewhat of a Duke Nukem Fan....3Drealms appears to be going for the record.

As for games that were not buggy, there have been lots released over the years that needed balancing patches etc...that really had nothing to do with bugs, this was different there was parts of the game that wasn't even there..you would select a destination and the game would crash as that part of the program wasn't there

I do agree developers NEED TO SPEND more time testing on a broad range of hardware, and of course develop on more than one IHV.

 

It's there because developers asked for it, as are many features of DX. I guarantee you that hardware vendors would do away with Lock/Unlock semantics for rendering surfaces in a heartbeat if they were allowed to...