R520 launch delayed?

I wasn't aware of that R420 can only utilise the co-issue masked ops if they're both identical. Maybe Huddy said it, but it went right over my head. :oops: Comes from never having written any shader code.

He also said that 5 scalars can be co-issued.

But anyway, this identical/non-identical co-issue ability of the two architectures is an interesting extra piece of information. Thanks.

So that leaves 6800 able to perform two Vec2 operations whilst texturing. Presumably that also means it can do a Vec3 + scalar or a Vec2 + two scalars.

That thread is where I first saw this topic come up. :LOL: It was you all the time. :LOL: :LOL: :LOL: If only I'd remembered the thread, huh?

Jawed
 
Jawed said:
I wasn't aware of that R420 can only utilise the co-issue masked ops if they're both identical. Maybe Huddy said it, but it went right over my head. :oops: Comes from never having written any shader code.

He also said that 5 scalars can be co-issued.
I think that applies to the VS, because it's vec4 + scalar.
From the GDC presentation pdf:
Vertex Engines II
• HLSL is your best approach...
• Expect one op per clock per pipe
– Sometimes you’ll get 2 ops instead...
– Masking out unused channels helps
– You can get up to 5 ops at once!
Again, that's only 5 identical scalar ops.

So that leaves 6800 able to perform two Vec2 operations whilst texturing. Presumably that also means it can do a Vec3 + scalar or a Vec2 + two scalars.
I never tested it, but it seems the first ALU is only blocked the same cycle the texture fetch is issued. In subsequent cycles it seems both ALUs can be fully utilized (as long as the math doesn't depend on the texture fetch).

That thread is where I first saw this topic come up. :LOL: It was you all the time. :LOL: :LOL: :LOL: If only I'd remembered the thread, huh?

Jawed
It's not too bad having topics like this come up from time to time. There always seem to be lots of new and undiscovered aspects, and sometimes someone with the right hardware can bring interesting facts to the table :D
 
Xmas said:
I never tested it, but it seems the first ALU is only blocked the same cycle the texture fetch is issued. In subsequent cycles it seems both ALUs can be fully utilized (as long as the math doesn't depend on the texture fetch).
From GPU GEMS2:
the first fp32 shader can be used for perspective
correction of texture coordinates when needed (by dividing by w), or for general-purpose
multiply operations. In general, it is possible to perform eight or more math operations
in the pixel shader during each clock cycle, or four math operations if a texture fetch
occurs in the first shader unit.
This make sense with an ALU being 'blocked' when the hw has to issue a texture fetch.
 
Xmas said:
Jawed said:
He also said that 5 scalars can be co-issued.
I think that applies to the VS, because it's vec4 + scalar.
From the GDC presentation pdf:
Vertex Engines II
• HLSL is your best approach...
• Expect one op per clock per pipe
– Sometimes you’ll get 2 ops instead...
– Masking out unused channels helps
– You can get up to 5 ops at once!
Again, that's only 5 identical scalar ops.

I think you're right. Just going through the WMV now. He says much more on this subject while discussing vertex shaders and only briefly mentions it when pixel shaders come up.

I was juggling the two scalars plus vec3 in the PS to conclude that 5 scalars are possible in PS. I was assuming that the scalar ALU that goes with the vec3 PS1.4 unit isn't limited to PS1.4.

So that leaves 6800 able to perform two Vec2 operations whilst texturing. Presumably that also means it can do a Vec3 + scalar or a Vec2 + two scalars.
I never tested it, but it seems the first ALU is only blocked the same cycle the texture fetch is issued. In subsequent cycles it seems both ALUs can be fully utilized (as long as the math doesn't depend on the texture fetch).
Teehee, someone will get to the bottom of it eventually!

Jawed
 
To go back on topic, an interesting blurp on a popular Dutch tech-forum has some info about a possible launch date and other R(V/X)5xx configurations. It seems credible and the poster has been correct on several occasions.

Dunno if it has been mentioned here but a search for RX550 and RV515/RV530 didn't give me any similar results, so here it goes... (If it's old news... sorry for that and I'll delete it).

Value
RV515 > MP date Oct.
RV515 LE 250Mhz DDR1 TSOP / 128bit / 512MB / AIB, Retail, OEM
RV515 PRO 400Mhz DDR2 / 128bit / 512MB / OEM
RV515 PRO 500Mhz GDDR3 / 128bit / 256MB / OEM
RV515 SE 250Mhz DDR1 TSOP / 64bit / 256MB / LP design / AIB, Retail, OEM
RV515 SE HM 500Mhz GDDR3 / 32bit / 32MB / LP design / OEM
RV515 PRO 500Mhz GDDR3 / 128bit / 128MB / LP design / OEM

RX550, based on RV370 core, 500/250
128/64bit
pcb: pin to pin compatible with current X300 and X600 pro
standard config: 256MB / 128bit
Target product: 6200TC 256
MP: Mid June
>> X300SE HM continue

Mainstream
RV530 > MP date Sept
RV530 DDR1 TSOP / 64&128bit / 64&128MB / LP design
RV530PRO DDR2 / 128bit / 256&512MB / 4 layer
RV530XT GDDR3 / 128bit / 256MB / 8 layer
>> X700 and X600 PRO continue

Performance
R520 > MP date July / Aug
R520XT PE & XT GDDR3 / 256bit / 512MB / Dual slot cooling / PCI-E (aug)
R520 PRO GDDR3 / 256bit / 256MB / Dual slot cooling / PCI-E or AGP (sept)
>> X800PRO, X800XL continue
Source: The Source @ Tweakers.Net
 
Au contraire, that seems typical of ATI. Confuse the market with a multiplicity of graphics cards in each segment.

Jawed
 
R520XT PE & XT GDDR3 / 256bit / 512MB / Dual slot cooling / PCI-E (aug)

I really hope they've dropped the X850 series dual slot cooler. Sure, it's effective, but only if you up the fan speed with ATI tool. But it ain't fun playing games with a Boeing 747 in the same room. :LOL:
 
ATI Multi VPU will need an external connector

The guys over at The Inq have confirmation that ATI will need an external connector in order to make its Multi VPU work. ATI tried to avoid using an internal connector but it ended up with an external one as you will have to connect the cards, after all. If you work with two cards, card number two has to get information from the first card before it displays the final image.

However, ATI decided to use an external connector simple because it didn’t want to release new series of Multi VPU capable cards powered with an internal connector. If it had done that, it would have ended up upsetting many customers who bought X800 or X850 cards. So ATI views this as an easy move for its customers to dual cards and can offer it to every single X800 and X850 card owner. A smart move for upgrade market.

http://www.theinquirer.net/?article=23265
 
That's just bad engineering. I'd take an internal connector over an external dongle every day of the week.

Oh, and combining a SM2b and a SM3whatever card doesn't sound very clever to me either. What a mess!
 
Jawed said:
I wonder if you can piggy-back dongles to get three, four or more cards working together :LOL:

Jawed

I wish this were doable with Vooodoo 2s :D

How will the ATI solution work?
for instance you have an old X800XT, you'll buy a X850XT AMR-able with DVI input and have an external DVI-DVI cable?

that sounds fishy, maybe they didn't understand their 'insider information' and that external connector is actually the PCI-E bus :p
 
Blazkowicz_ said:
How will the ATI solution work?
for instance you have an old X800XT, you'll buy a X850XT AMR-able with DVI input and have an external DVI-DVI cable?

BAsed on the rumors, that's exactly how it'd work.

How else (other than no connector at all) would you be able to get existing X800XTs to work with new AMR-able boards?
 
IgnorancePersonified said:
How much bandwidth is avialable on a dvi to dvi connector?
Was hoping there would be a "connector less" dual vid card solution at some stage.

to be honest i think that this amr will be dongle-less and that faud is wrong

no reason why it can't be done via chipset
 
DevilsRejection said:
IgnorancePersonified said:
How much bandwidth is avialable on a dvi to dvi connector?
Was hoping there would be a "connector less" dual vid card solution at some stage.

to be honest i think that this amr will be dongle-less and that faud is wrong

no reason why it can't be done via chipset

Maybe they discovered that they could do it over the bus but that it would impact peformance more than they'd like. The nV guy in Josh's interview suggested as much.
 
Back
Top