The NEXT LAST R600 Rumours & Speculation Thread

They also reported gazillion other "exact numbers" in case you forgot, so what makes you think this would be related to that in any way?

 

That was my plan, if the 2600 is decent enough to hold me over until the refresh options.

Did anyone notice this?

 

That the 225 obviously wasn't guesswork, unlike the temperature numbers in which R600 does a better job at staying cool...

 

That would be an utter waste of money. Better invest it in a quad-core CPU, or a balanced CrossFire setup.

 

Anyone knows how much you gain running a gfx that calculate physics?

I guess it must be implemented in every single game, are there any games that support this today?

 

No game is currently implementing it and therefore its currently impossible to say. I wouldn't hold my breathe on the issue personally. But if you have say a X1900 card currently then it might be useful holding onto it for the time being.

 

Correct source:
http://www.nordichardware.com/forum/viewtopic.php?topic=8428&forum=45

//Andreas

 

That's not the only point. CTM could be used for a wide variety of APIs both by first and third-party developers, there just isn't any created yet.. Perhaps first physics will be off-loaded, but later perhaps AI will be, as well as many other things. There's tons of room for middleware IE what havok/AGEIA have done for physics, specifically aimed towards using the FLOPs of a secondary lesser card, which should still be much greater than or comparative to that of a high-end CPU (wish I could find that slide with RV630's flop count...). This is why I think it's a good option.

Currently physics are done mainly on the CPU; Havok 4.0 added using the GPU as well, I imagine it can be adapted for use on only secondary cards, leaving the main GPU for other things, although I havn't heard anything from ATi/Nvidia confirming that beyond that their physics systems were going to use Havok, but it would make the most sense. Any differance is a positive one, and considering how many current and future games use havok, it's a step in the right direction.

We don't really have anything to judge the impact it will cause because the only thing we have to compare it to is PhysX, which obviously isn't a great example, as it's proprietary.

 

I don't know R600's exact layout, but I was just trying to see why they went the co-issue route instead of the SOA route (as in G80) for scalar granularity. I heard about R600's scalar ability almost a year ago, and the SOA implementation was the first thought in my head due to its simplicity and efficiency.

If the 320 math units were divided further into smaller subgroups, then batch size would no longer be an issue. They could all execute the same instruction on the same channel, just like G80 does, and the co-issue decision remains a baffling one.

True, but I expect it to be the same as in G80. It's pretty trivial to use the mantissa of FP math units for most integer operations. AFAIK, everything from R300 onwards worked that way on DX8 shaders.

That's the other thing I was thinking about: 4 clocks to change the instruction.

It doesn't seem like much of a design issue to me if one was to reduce this. Maybe the dynamic branching aspect of instruction scheduling is a little expensive to make that fast, but I see no problem in stuffing some NOP instructions to keep jump frequency down to once every 4 instructions. The co-issue method wouldn't be any faster.

I know you have the Xenos documents, so you know that the three 16-ALU (5D) shader arrays operate on vectors of 64 pixels/vertices. It would take 4 clocks for an array to execute any instruction pair (4D+scalar) on a vector. Now imagine if the arrays were simply a group 64 ALUs executing the same 1D instruction. It would still take 4 clocks to execute a 4D instruction, but only one clock to execute a scalar instruction provided it wasn't a special function (which can be handled several different ways).

Yes, you need to change the instruction every clock instead of every 4 clocks, but you also have 64-way SIMD instead of 16-way SIMD for the R600 route (assuming 4x16 organisation). Moreover, you can have dependency between the instructions and don't have to worry about efficient packing by the compiler or scheduler.

 

Almost correct. You can't just pass through audio for HD-DVD (not sure about Blue-Ray) as HD-DVD requires you to composite different audio streams. In dedicated HD-DVD players, this is done in hardware usually. I'm assuming that for the R600 and RV6xx cards that the audio compositing will be done in software. At which point it will be passed to the Video Card which in turn just passes it through the HDMI connector.

However, I'm also assuming that you are correct in that it won't generate audio like a traditional sound card. Meaning it can either 1) pass through audio from a DVD source or 2) take the audio streams from a HD-DVD, composite them as required and pass them through.

Although since the low end cards ARE meant for HTPC. One might also assume that those people would do their computing on their HDTV's. So there is a possibility that RV6xx might be able to either pass through sound from onboard audio codecs (?) or have some software codec that would allow general system sounds to be passed through the HDMI connector.

Regards,
SB

 

Sweeney's comment shouldn't be a surprise as he's absolutely right. This has been known for some time now. The benefit of DX10 is the performance, but also the fact that the reduced overhead will allow greater complexity in rendered scenes.

 

We're talking about the 2600 as a third card here

 

Or for someone like me with multiple monitors where crossfire is basically useless (or at best a royal pain in the behind) since I'd have to constantly enable/disable it.

I'm actually more interested to see how the HD 2400 series does with Physics and GPGPU. If it does well, then a passively cooled card that can drive my 3rd and 4th monitors while also doing phsyics calcs in possible future games would be right up my alley.

Regards,
SB

 

An onboard audio codec doesn't even need hardware to go along with it. It just needs a way to get the data to the speakers. Then some inputs never hurt to have around. If the HDMI audio output is something that the system could easily map, and I hope it will be, I don't think it would be unreasonable to forward all audio data through the HDMI port. Since all audio is digital to begin with R600 could probably just grab the audio stream and forward it on.

This might even be a reason why Vista doesn't seem to like sound cards. On a lot of cards the audio compositing is done on the card. In this case you'd have to get the final audio stream back off the card to be forwarded elsewhere. I suppose SPDIF would work but there would be some quality loss and going over PCI-E seems to be problematic for sound cards. For the onboard solutions it seems fairly straightforward as long as they can provide some sort of handle to the audio stream.

 

I asked this because an extremely reliable source told me that if G80 organization can be seen as a 8-2-8 R600 is like a 4-4-4-5.

 

Core 2 Extreme QX6800: 93.8 GFLOPS
GeForce 8600 GTS: 92.8 GFLOPS

I know this is just multiply-accumulate, but the numbers don't lie: CPU's are catching up in floating-point performance, FAST. Prices for quad-cores will drop pretty quickly soon. And what else to use these cores for?

This is why I believe 'dedicated' physics will never be more than a gimmick. There's nothing special about physics calculations that would make another processor significantly faster than the CPU. The 530 million sphere collisions per second specified for PhysX is laughably low.

There's just no convincing reason to send the phyiscs calculations to another processor. I also utterly dislike the idea of being forced to invest in another co-processor just to play a game properly. With just a little more effort it can all be done on a multi-core CPU.

 

Hmmm, first post, hope I dont make a fool out of myself.
But, has anyone noticed the max clock: (750-800)E/1100M
Could this mean: 750-800 MHz economy; 1100 MHz max?
It couldnt be the DDR speed ; either true or effective....
Or am I completely missing something?
Gr. Paul

 

E = engine (core)
M = memory

 

Welcome Paul Atreides.

the clocks also go below 750. you'll see cards at, say 742, some at 750, some at 757. Memory speed will also vary but we know the current stock speed is 1Ghz

I haven't seen any XT yet which will ship at 800 but the professional overclock people allready wrote that this card easily does 1Ghz (cpu) on stock cooling with stock voltage.

 

Actually I don't think anyone said 1GHz would be on stock cooling, just stock volts.
Also, since the default coolers supposed "capacity" is 210W, I don't see that 1GHz happening on it.