Do you see these efficiency improvements on Fermi as well? Do you see same (or similar) improvements on Fermi as on older nv GPUs (ie, those without caches)?
I don't have fermi hw so I am asking.
AMD: R9xx Speculation
- Thread starter Lukfi
- Start date
Do you see these efficiency improvements on Fermi as well? Do you see same (or similar) improvements on Fermi as on older nv GPUs (ie, those without caches)?
I don't have fermi hw so I am asking.
I neither own a GF100, but for something memory intensive one should look into using textures which are cached on every GPU. Somehow related, in my opinion CUDA people often use local memory for no reason (i.e. just as a software managed cache). Just using textures and exploiting the texture cache is easier and often even faster (if one can allow for the additional latency). But maybe that was just bad luck with the stuff I've got to see.
Last edited by a moderator:
Did this also apply to the GT200 line where nv increased the register files? But I agree that on G80/G92 register pressure is/was often a limitation.
Nevertheless, GF100 has about half the registers of Cypress, but also only half the peak performance. So something that performs close to peak on a Cypress (vectorized) shouldn't be that much more demanding (relatively speaking) on a GF100.
My gut feeling is that vectorize-to-get-higher-bw is limited to gpus without a real cache hierarchy.
IIRC, AMD's optimization guide (the one with sdk 2.2) says coalesced loads of float's or float4's (evergreen family presumably) has a very small difference on bw.
This applies on all Nvidia architectures.
To fill a G80 (GT100) all the way, each thread must use 10 registers or fewer
To fill a GT200 all the way, each thread must use 16 registers or fewer
To fill a GF100 all the way, each thread must use 21 registers or fewer.
Filling the chip all the way is not necessarily the right thing to do. However, register pressure is a key performance barrier, and it's very common to optimize code in an attempt to get below some register pressure limit, since performance is very discontinuous. Scalar code (not-vectorized) I wriften uses 15 or so 32-bit registers. Vectorizing with float4 data requires 4 32-bit registers for every vectorized piece of data. That can easily lift my code past the register limits and severely impact performance.
So, vectorization can be good for the reasons you suggested, but if you apply it blindly, you will have severe performance problems on Nvidia hardware. I've seen vectorized code perform 2-3x slower than non-vectorized code.
That's not saying much when your starting point is a 100% theoretical advantage for the 5870. So even with lower efficiency its absolute AF performance is still considerably higher according to those numbers. 0.381*850*80 >> 0.597*607*56 !
Cypress' instantaneous shader throughput is much higher, yet does not result in an overall performance benefit so either GF100 has a similar advantage in instantaneous performance on other workloads (no analysis available) or the shader portion of a typical gaming workload is so small as to limit the potential benefit and Amdahl's law is smacking you in the face. My question is why does AMD bother and I guess the most popular answer is that the shaders are cheap so why not.
My curiosity is limited to utilization and measured performance given the available horsepower. Die size doesn't affect that either way.
Yep, I was looking forward to AlexV's article. Guess he missed his own deadline, start of this week wasn't it?
For better thermal characteristics? Or more complex power circuits? Both 5750 and 5770 are 128bit, but 5750 has 6 layers, 5770 has 8 (acc. to vr-zone). Custom OC models of HD5870 has also 2 additional layers.
Jawed
Legend
Exactly. AMD added 2 cores to RV770 because the die would have had a huge blank spot otherwise.
It's worth noting if you add up all the blank areas of GT200 on 65nm, it's quite a surprise. 6.5% of the die I reckon.
Jawed
Legend
Is it power or is it memory clocks?
It occurred to me that GDDR5 at the craziest speeds might just be easier with more layers.
How many layers is HD5870 reference?
reference HD5870 has 8 layers
Jawed
Legend
OK, so reference HD5770 and HD5870 both have 8 layers. We can say two things:
- Barts having 8 layers doesn't indicate it has a 256-bit bus, since HD5770 has 8 layers too
- layers don't seem to correlate with the power difference between HD5770 and HD5870 - 80W TDP difference for reference boards
It seems drivers are already present for R9xx in the newest Mac OS X 10.6.5 beta.
ATIRadeonX3000.kext (and other relevant kexts) has the following devices listed.
Could it really be that Apple is about to get updates that line up with their PC bretheren?
Interesting to say the least.
ATIRadeonX3000.kext (and other relevant kexts) has the following devices listed.
Could it really be that Apple is about to get updates that line up with their PC bretheren?
Interesting to say the least.
Last edited by a moderator:
How does that go with intel GMA X3000 chips?
Hehe, not well, considering Macs have only used GMA950 and X3100 as far as I recall.
Well, just good seeing support for Northern islands in the newest Mac OS X beta.
DavidGraham
Veteran
Partial truth , or Complete speculation ?
What about this ?
Partial truth , or Complete speculation ?
http://www.3dcenter.org/news/2010-08-26
What about this ?
Partial truth , or Complete speculation ?
http://www.3dcenter.org/news/2010-08-26
Makes sense to me. GTX 485 would be the fully unlocked Fermi. GTX 490 would be single card SLI GTX 460.
Everything on Ati side seems to rhyme with those code names previously found.
Not sure why some cards have more accurate release schedule (Nov) than others (Q4)
I'm pretty sure Q4 for 69x0 will be later than the Q4 for 67x0
Everything on Ati side seems to rhyme with those code names previously found.
Not sure why some cards have more accurate release schedule (Nov) than others (Q4)
I'm pretty sure Q4 for 69x0 will be later than the Q4 for 67x0
6830 going up against 5850, must be quite a die.
Price points not performance...
Similar threads
