For CPU performance a 6300 is Superior and under gaming a A8 7600 is really only decent for 720P monitors. I guess you could build a rig for 370$ with one. TDP is quite nice and i like having it configurable, but isn't a AMD Athlon 5350 already enough for 1080P HD move playback for HTPC rigs?
Actually, the NANOPC that AMD showed off earlier this year is enough for 1080p movie playback...(they were watching the world cup in 1080p via a mullins powered SoC in the nanopc)
I have never changed what Jim Keller said. He says it will be better. I do not doubt.
My source says if they shoot for better, and fall a bit short, they are still on par. Which I think is reasonable.
Either way, I am done talking with you...we will see who is right. I will hang your head on a pike when you are wrong beyond doubt for all to see as well. You will not be able to twist your words about ARM we have 100+ pages of your rubbish.
You changed the words that he supposedly said and you added the word "Intel" to a quote from him
This is not a personal competition between you and me (despite you see it that way). I would like to be wrong, because this would imply better products for all of us. But as several posters (not only me) are saying you, your claims are very difficult to accept.
I note that you have ignored again my technical, economic, and strategic remarks. You are only spreading hype, as you did before Steamroller. Finally, everything what you have said against ARM has been proven to be wrong, you continue beating a dead horse.
I believed that the PCIe2 vs PCIe3 issue had been settled down in this this thread...
Current games are designed with PCIe limits in mind. E.g. textures are transferred by the PCIe bus in compressed form with ratios of 1:4 or 1:8. Others form of CPU-GPU communication are maintained at a minimum, which cripples game development/evolution.
This is the reason why during MANTLE tech presentations the new feature of asymmetric multi-GPU configurations was illustrated with an example where the GPU attached to the PCIe handle the rendering load and offload all post-processing to the GPU in the APU.
Future games will require much more bandwidth and less latency than what PCIe 4 will provide. In fact, the big advantage of a console as the PS$ is that avoids the PCIe bottleneck and can use the GPU for novel applications including sound processing or physics.
Said that of above, here we can see some benchmarks showing that PCIe3 can provide 5%, 10%... gains over PCIe2 in some situations/configurations, even when using old games
A57 includes thousands of blocks. Chances are that some of them are better than ones in AMD's library.
What part of A57 core belongs to ARM and AMD cannot reuse "blocks" from it wasn't understood?
You also have problems with understanding "ideas aren't patented".
Ideas aren't patented, but "ideas" != "blocks". I am commenting on that you say about blocks. In the first post you pretended that AMD could use blocks from K10, llano, A57... but AMD only has intelectual property over its own designs and cannot reuse blocks from designs of others companies, not even when has a license to use core from another company.
Juan that site does not include anyone from Amd that said that they just used this quote
“People may increasingly depend on tablets and smartphones—instead of PCs—as their main point of contact with the Internet, experts say.”
What about people still on PC's or servers? I for one could care less about tablets or smartphones they are extremely limited in what they can do any screen under 15.6 inches is to low for me to do work or email's. I use a 28+Inch screen at work and i use a 32 inch 1080P screen for PC gaming,movies. Smartphones have their uses for things outside of real gaming and real work.
The site was mentioned to show that neither AMD nor myself are alone in the claims. There are lots of people, industry analysist, and similar that make the same claims.
Servers have been announced, demonstrated, and will start shipping this year. Desktop PCs will be the last to join due to Windows legacy. Performance is superior to x86. During the core conference, Keller explained why armv8 can bring more performance than x86-64: more registers, three-operand, simpler decoder...
As any expert know the new ARMv8 ISA has been designed for high-performance. Only ill-informed people can believe that the new 90W ARM SoCs will be inside smartphones. :lol: Those 90W ARM SOCs will beat 140W x86 Xeons.
It is not about being either optimistic or pessimistic, it is about being realist. The idea of AMD outperforming Intel because it did in the past is unfounded because the contexts are very different, as I explained before: DEC-legacy, foundries, funds, Intel mismanagement/underexecution, chip complexity...
Nobody is saying that AMD will be "trying to match what Intel has now". What we are saying is that we expect AMD new arch. to match Haswell performance. The new AMD arch will be superior to anything that "Intel has now" in other aspects such as efficiency, customization, and cost. AMD doesn't need to match Skylake core performance to be competitive.
I just maintain that they will be targeting Skylark with their design, NOT Haswell. Agreed it doesn't need to win in outright performance, but it HAS to at least match it from an efficiency standpoint (which means it either has to be much lower wattage for less performance, or similar performance at similar power levels). Now they may not achieve that, but to start out on a design project with the intent to make something inferior would be stupid, and Keller knows what he's doing (look at the Apple arm designs, they didn't just match the standard ARM cores they surpassed them on a number of fronts).
We are actually more in agreement than in disagrement. I understand you, but you are not understanding me.
As I said in the above quote I expect the new core to match Haswell "performance", only performance. as I said the new design will be superior in "other aspects such as efficiency, customization, and cost". In resume:
I expect K12 to match Haswell CPU performance.
I expect K12 to outperform Skylake efficiency.
I expect K12 to outperform Skylake graphics.
I expect K12 to be highly customizable, whereas Skylake isn't.
I expect K12 to be cheaper than Skylake.
Surpassing standard ARM cores is easy. ARM designs the standard cores to be cheap enough to be licensed by small companies without the resources to design their own cores. It makes no business sense if ARM design standard cores that was so fast that can compete with the customs cores of its own customers.
It is also worth mention that Keller has not designed the Apple cyclone core in A7 SoC. Keller designed A4/A5 and leaved Apple for AMD.
It is not about being either optimistic or pessimistic, it is about being realist. The idea of AMD outperforming Intel because it did in the past is unfounded because the contexts are very different, as I explained before: DEC-legacy, foundries, funds, Intel mismanagement/underexecution, chip complexity...
Nobody is saying that AMD will be "trying to match what Intel has now". What we are saying is that we expect AMD new arch. to match Haswell performance. The new AMD arch will be superior to anything that "Intel has now" in other aspects such as efficiency, customization, and cost. AMD doesn't need to match Skylake core performance to be competitive.
I just maintain that they will be targeting Skylark with their design, NOT Haswell. Agreed it doesn't need to win in outright performance, but it HAS to at least match it from an efficiency standpoint (which means it either has to be much lower wattage for less performance, or similar performance at similar power levels). Now they may not achieve that, but to start out on a design project with the intent to make something inferior would be stupid, and Keller knows what he's doing (look at the Apple arm designs, they didn't just match the standard ARM cores they surpassed them on a number of fronts).
We are actually more in agreement than in disagrement. I understand you, but you are not understanding me.
As I said in the above quote I expect the new core to match Haswell "performance", only performance. as I said the new design will be superior in "other aspects such as efficiency, customization, and cost". In resume:
I expect K12 to match Haswell CPU performance.
I expect K12 to outperform Skylake efficiency.
I expect K12 to outperform Skylake graphics.
I expect K12 to be highly customizable, whereas Skylake isn't.
I expect K12 to be cheaper than Skylake.
Surpassing standard ARM cores is easy. ARM designs the standard cores to be cheap enough to be licensed by small companies without the resources to design their own cores. It makes no business sense if ARM design standard cores that was so fast that can compete with the customs cores of its own customers.
It is also worth mention that Keller has not designed the Apple cyclone core in A7 SoC. Keller designed A4/A5 and leaved Apple for AMD.
Ah I think we were talking cross purposes here- I agree with you fully on K12- matching Haswell for outright performance with an ARM core will be impressive but quite possible I think.
I was more referring to the x86_next uarch... That will probably be tuned for more outright performance, whilst K12 will fulfil the high efficiency requirements for servers and other non-pc devices. Don't get me wrong I think there is a good chance for ARM to move into the PC space eventually.
I believed that the PCIe2 vs PCIe3 issue had been settled down in this this thread...
Current games are designed with PCIe limits in mind. E.g. textures are transferred by the PCIe bus in compressed form with ratios of 1:4 or 1:8. Others form of CPU-GPU communication are maintained at a minimum, which cripples game development/evolution.
This is the reason why during MANTLE tech presentations the new feature of asymmetric multi-GPU configurations was illustrated with an example where the GPU attached to the PCIe handle the rendering load and offload all post-processing to the GPU in the APU.
Future games will require much more bandwidth and less latency than what PCIe 4 will provide. In fact, the big advantage of a console as the PS$ is that avoids the PCIe bottleneck and can use the GPU for novel applications including sound processing or physics.
Said that of above, here we can see some benchmarks showing that PCIe3 can provide 5%, 10%... gains over PCIe2 in some situations/configurations, even when using old games
It is even more clear when you look at both three-card setups, GeForce GTX 680 3-Way SLI versus Radeon HD 7970 3-Way CrossFireX. With GeForce GTX 680 3-Way SLI there were three instances where performance was improved with the PCIe 3.0 system, three separate games with advantages going all the way up to 9.6%. However, with Radeon HD 7970 3-Way CrossFireX there were no instances where the PCIe 3.0 syste, improved performance in any meaningful way. It seems as GPU count increases, so does the benefit of Ivy Bridge PCIe 3.0 with NVIDIA GTX 680, but it does not with AMD Radeon HD 7970.
The only times it made it difference were in extreme multiple GPU setups where the normal x16 bandwidth would of been divided up amongst several GPU's. This was a test of PCIe 2.0 8x vs PCIe 3 8x. A PCIe 2.0 16x channel has about the same bandwidth as a PCIe 3 8x channel.
Also game development is NOT being nerfed nor hindered due to PCIe, that is horribly incorrect. The very nature of how GPU's process data means that the graphics processor or the geometry source (CPU) will be the limitation. dGPU's tend to have 3~6GB of high speed memory, with PCIe 2.0 the per-lane transfer speed is 500MB's. That would allow you to transfer the entire contents of nearly any mid to upper midrange dGPU in under one second. With a 16x slot your looking at 8GB's which is the entire capacity of everything but the Titan Z in under one second. Games aren't anywhere close to needing more then 8GB's worth of new graphics data per second. They upload everything they need to the dGPU, then just go about their business rasterizing frames while slowly swapping out unneeded data for needed data.
Heck a 32-bit NT executable can't address more then 2GB of application memory, with only about 1.7~1.8GB being usable for the application. So there's no way a 32-bit application can even dream about using more then ~3GB of video memory, hell most don't use more then 512MB ~ 1GB. Which leads me to the real user of graphics memory, the GPU itself as a working area. Many graphic enhancement techniques employed at the driver level are executed inside the dGPU itself, the textures are loaded into graphics memory then rendered to larger levels inside the memory with the shaders and aliasing being done. There is next to no additional burden placed on the interconnect bandwidth, unless your rendering at a much higher internal resolution then your dGPU's memory can support and thus need to constantly swap in and out graphics resources. Of course that creates other problems which are significantly more severe then graphics bandwidth.
Anyway the technical details of how all this works leads to the result that graphics I/O interconnects are usually well ahead of what the current need is in the consumer space, usually by an entire generation.
A57 includes thousands of blocks. Chances are that some of them are better than ones in AMD's library.
What part of A57 core belongs to ARM and AMD cannot reuse "blocks" from it wasn't understood?
You also have problems with understanding "ideas aren't patented".
Ideas aren't patented, but "ideas" != "blocks". I am commenting on that you say about blocks. In the first post you pretended that AMD could use blocks from K10, llano, A57... but AMD only has intelectual property over its own designs and cannot reuse blocks from designs of others companies, not even when has a license to use core from another company.
It's really not a problem. They have all details needed to implement something similar in their own design whenever they find something good (as long as it's not covered by any patent).
I believed that the PCIe2 vs PCIe3 issue had been settled down in this this thread...
Current games are designed with PCIe limits in mind. E.g. textures are transferred by the PCIe bus in compressed form with ratios of 1:4 or 1:8. Others form of CPU-GPU communication are maintained at a minimum, which cripples game development/evolution.
This is the reason why during MANTLE tech presentations the new feature of asymmetric multi-GPU configurations was illustrated with an example where the GPU attached to the PCIe handle the rendering load and offload all post-processing to the GPU in the APU.
Future games will require much more bandwidth and less latency than what PCIe 4 will provide. In fact, the big advantage of a console as the PS$ is that avoids the PCIe bottleneck and can use the GPU for novel applications including sound processing or physics.
Said that of above, here we can see some benchmarks showing that PCIe3 can provide 5%, 10%... gains over PCIe2 in some situations/configurations, even when using old games
*gasp* PCIe3 does slightly better in high-bottleneck situations at insane resolutions? I'm SHOCKED I tell you.
Again, you take an edge case and consider it a rule. There is no significant difference between the two at this point, and nowhere near enough to warrant a $200 platform upgrade.
I believed that the PCIe2 vs PCIe3 issue had been settled down in this this thread...
Current games are designed with PCIe limits in mind. E.g. textures are transferred by the PCIe bus in compressed form with ratios of 1:4 or 1:8. Others form of CPU-GPU communication are maintained at a minimum, which cripples game development/evolution.
This is the reason why during MANTLE tech presentations the new feature of asymmetric multi-GPU configurations was illustrated with an example where the GPU attached to the PCIe handle the rendering load and offload all post-processing to the GPU in the APU.
Future games will require much more bandwidth and less latency than what PCIe 4 will provide. In fact, the big advantage of a console as the PS$ is that avoids the PCIe bottleneck and can use the GPU for novel applications including sound processing or physics.
Said that of above, here we can see some benchmarks showing that PCIe3 can provide 5%, 10%... gains over PCIe2 in some situations/configurations, even when using old games
It is even more clear when you look at both three-card setups, GeForce GTX 680 3-Way SLI versus Radeon HD 7970 3-Way CrossFireX. With GeForce GTX 680 3-Way SLI there were three instances where performance was improved with the PCIe 3.0 system, three separate games with advantages going all the way up to 9.6%. However, with Radeon HD 7970 3-Way CrossFireX there were no instances where the PCIe 3.0 syste, improved performance in any meaningful way. It seems as GPU count increases, so does the benefit of Ivy Bridge PCIe 3.0 with NVIDIA GTX 680, but it does not with AMD Radeon HD 7970.
The only times it made it difference were in extreme multiple GPU setups where the normal x16 bandwidth would of been divided up amongst several GPU's. This was a test of PCIe 2.0 8x vs PCIe 3 8x. A PCIe 2.0 16x channel has about the same bandwidth as a PCIe 3 8x channel.
Also game development is NOT being nerfed nor hindered due to PCIe, that is horribly incorrect. The very nature of how GPU's process data means that the graphics processor or the geometry source (CPU) will be the limitation. dGPU's tend to have 3~6GB of high speed memory, with PCIe 2.0 the per-lane transfer speed is 500MB's. That would allow you to transfer the entire contents of nearly any mid to upper midrange dGPU in under one second. With a 16x slot your looking at 8GB's which is the entire capacity of everything but the Titan Z in under one second. Games aren't anywhere close to needing more then 8GB's worth of new graphics data per second. They upload everything they need to the dGPU, then just go about their business rasterizing frames while slowly swapping out unneeded data for needed data.
Heck a 32-bit NT executable can't address more then 2GB of application memory, with only about 1.7~1.8GB being usable for the application. So there's no way a 32-bit application can even dream about using more then ~3GB of video memory, hell most don't use more then 512MB ~ 1GB. Which leads me to the real user of graphics memory, the GPU itself as a working area. Many graphic enhancement techniques employed at the driver level are executed inside the dGPU itself, the textures are loaded into graphics memory then rendered to larger levels inside the memory with the shaders and aliasing being done. There is next to no additional burden placed on the interconnect bandwidth, unless your rendering at a much higher internal resolution then your dGPU's memory can support and thus need to constantly swap in and out graphics resources. Of course that creates other problems which are significantly more severe then graphics bandwidth.
Anyway the technical details of how all this works leads to the result that graphics I/O interconnects are usually well ahead of what the current need is in the consumer space, usually by an entire generation.
iron8orn :
just ignore pallidan... anyone who professionally renders or works for microsoft would school his babel.
i got better things to do..
iron8orn leaves a cookie for pallidan<
Palladin is 100% correct though. The old 32-bit 2GB limitation remains a significant limiting factor in terms of how much graphical memory you can even send over PCIe. Graphics bandwidth is NOT a problem, and won't be until we get to 64-bit native games that actually use more then a GB or so for graphics. When that happens though, I fully expect to see super-high end 16GB GPU's start to appear, as VRAM will start to become a MAJOR limiting factor. When it happens, 64-bit is going to be a MASSIVE thing for gaming.
Palladin is 100% correct though. The old 32-bit 2GB limitation remains a significant limiting factor in terms of how much graphical memory you can even send over PCIe. Graphics bandwidth is NOT a problem, and won't be until we get to 64-bit native games that actually use more then a GB or so for graphics. When that happens though, I fully expect to see super-high end 16GB GPU's start to appear, as VRAM will start to become a MAJOR limiting factor. When it happens, 64-bit is going to be a MASSIVE thing for gaming.
is it the issue with the games or the gpus? i was reading about gcn yesterday and gcn can use 64bit addressing mode. are game developers sticking with 32bit mode for compatibility's sake? i don't know much about older gpus.
Palladin is 100% correct though. The old 32-bit 2GB limitation remains a significant limiting factor in terms of how much graphical memory you can even send over PCIe. Graphics bandwidth is NOT a problem, and won't be until we get to 64-bit native games that actually use more then a GB or so for graphics. When that happens though, I fully expect to see super-high end 16GB GPU's start to appear, as VRAM will start to become a MAJOR limiting factor. When it happens, 64-bit is going to be a MASSIVE thing for gaming.
Interestingly enough, there are games coming out with native 64bits executables (haven't seen if the libs are full 64bit though).
In the coming year (2014 -> 2015) I'm sure we'll see more games chugging more resources (I hope), since we already have some that actually do.
I gave a link to one that got my attention a while ago called "Planetary Annihilation". Also, we have "Star Citizen" and some other big games announced to be native 64bits (can't remember more though).
And iron8orn, read carefully every post in here instead of dismissing them easily (specially palladins', gamerks', 8350rocks' and juans'), since they usually contain a lot of good information to think about. That attitude only destroys good conversation and doesn't add anything meaningful to it; in other words: "if you don't have anything nice to say, then stay quiet".
Palladin is 100% correct though. The old 32-bit 2GB limitation remains a significant limiting factor in terms of how much graphical memory you can even send over PCIe. Graphics bandwidth is NOT a problem, and won't be until we get to 64-bit native games that actually use more then a GB or so for graphics. When that happens though, I fully expect to see super-high end 16GB GPU's start to appear, as VRAM will start to become a MAJOR limiting factor. When it happens, 64-bit is going to be a MASSIVE thing for gaming.
Interestingly enough, there are games coming out with native 64bits executables (haven't seen if the libs are full 64bit though).
In the coming year (2014 -> 2015) I'm sure we'll see more games chugging more resources (I hope), since we already have some that actually do.
I gave a link to one that got my attention a while ago called "Planetary Annihilation". Also, we have "Star Citizen" and some other big games announced to be native 64bits (can't remember more though).
And iron8orn, read carefully every post in here instead of dismissing them easily (specially palladins', gamerks', 8350rocks' and juans'), since they usually contain a lot of good information to think about. That attitude only destroys good conversation and doesn't add anything meaningful to it; in other words: "if you don't have anything nice to say, then stay quiet".
Cheers!
Yeah PA is basically 64 bit only.... (there is a 32 bit windows version however it's really crippled)..
PA can max out as much ram as you can throw at it, the amount of memory effectively serves as a cap on system size.
I have never changed what Jim Keller said. He says it will be better. I do not doubt.
My source says if they shoot for better, and fall a bit short, they are still on par. Which I think is reasonable.
Either way, I am done talking with you...we will see who is right. I will hang your head on a pike when you are wrong beyond doubt for all to see as well. You will not be able to twist your words about ARM we have 100+ pages of your rubbish.
You changed the words that he supposedly said and you added the word "Intel" to a quote from him
This is not a personal competition between you and me (despite you see it that way). I would like to be wrong, because this would imply better products for all of us. But as several posters (not only me) are saying you, your claims are very difficult to accept.
I note that you have ignored again my unqualified technical, economic, and strategic remarks. You are only spreading hype, as you did before Steamroller. Finally, everything what you have said against ARM has been proven to be wrong, you continue beating a dead horse.
FTFY!
It is not a personal competition, however, you fail to understand what you are talking about on multiple levels, and I refuse to allow anyone to spout nonsense conjecture without qualification to reasonably back up their claims beyond some ancient marketing propaganda. You cannot produce anything that is not a marketing piece, and what you can produce is old material. If you were arguing against someone who was providing such materials, you would dismiss it outright because it is so old it is not relevant.
The fact remains, JK said that, NOT me, and NOT my source. However, considering he did actually do the cores for A7 (remember, design to tape out is about a 2 year process in most cases and A7 taped out a year after he left...), as well as many other things since leaving and returning to AMD. I have immense faith in him delivering what he says. Though as my source has pointed out, if you shoot for Mars and hit the moon, you are still on the moon. AMD has a lot of stuff coming soon, and unfortunately I cannot expound beyond that. All I can say is, leave ARM to die until it shows up in a HEDT PC, once that occurs, we will have a conversation about ARM. As for AMD catching up...we shall see. Things are very different from what they were in the 1990's, while they are also very similar to what they were as well. So, I would expect you to sit back and watch as things unfold, I can only lead you to water, whether or not you drink it is your own business.
Palladin is 100% correct though. The old 32-bit 2GB limitation remains a significant limiting factor in terms of how much graphical memory you can even send over PCIe. Graphics bandwidth is NOT a problem, and won't be until we get to 64-bit native games that actually use more then a GB or so for graphics. When that happens though, I fully expect to see super-high end 16GB GPU's start to appear, as VRAM will start to become a MAJOR limiting factor. When it happens, 64-bit is going to be a MASSIVE thing for gaming.
Interestingly enough, there are games coming out with native 64bits executables (haven't seen if the libs are full 64bit though).
In the coming year (2014 -> 2015) I'm sure we'll see more games chugging more resources (I hope), since we already have some that actually do.
I gave a link to one that got my attention a while ago called "Planetary Annihilation". Also, we have "Star Citizen" and some other big games announced to be native 64bits (can't remember more though).
And iron8orn, read carefully every post in here instead of dismissing them easily (specially palladins', gamerks', 8350rocks' and juans'), since they usually contain a lot of good information to think about. That attitude only destroys good conversation and doesn't add anything meaningful to it; in other words: "if you don't have anything nice to say, then stay quiet".
Cheers!
Yeah PA is basically 64 bit only.... (there is a 32 bit windows version however it's really crippled)..
PA can max out as much ram as you can throw at it, the amount of memory effectively serves as a cap on system size.
Well, adding to that; I remember that buffer pools are kept in ram (for old games at least). I don't know if that model is still being used for new games (I think it was also called "vram mirroring"; used in SLI and XFrie, for sure, but don't remember if single cards as well), so having 64bits will allow games to chug more bandwidth from PCIe since they'll need it badly. Now VGAs will come in 4GB flavors, so 32bit addressing won't be an option anymore (for games) that want to put a buttload of textures or big enough stages/maps in front of us, haha.
To keep the context: PCIe bandwidth will be saturated when we go past 4GB as a regular size for Video cards memory. I'm willing to believe we're at 2GB as "standard" for enthusiasts and upper mainstream. Consoles also have more than that to work with, right? PS4 has like 3-4GB dedicated to video (up to 5GB, IIRC)? XB1 similar. So devs should start saturating PCIe 2.0 more evidently sooner than later... I guess it will depend on the CPU as well to saturate the PCIe interface, haha.
I forgot to ask about something.
What does it mean "better than Skylake" excactly?
IPC? IPC*maximum clock? Performance per watt? Performance per $? Performance per mm^2?
FX-8150 was close to i7-2700K in multithreaded benchmarks, but failed at everything else (size, TDP, single thread, IPC, memory brandwith).
Your crazy palladin, You should get some quieter fans for your cpu instead of downgrading to a worse cpu.
For an HTPC and light gaming an A8-7600 is actually a great upgrade. According to Tom's original review even using the lower configured 45W TDP the 7600 can usually meet or even surpass the 6850K's performance while gaming. Not to mention that the TDP is half of his current APU which would most likely completely eliminate his annoying fan noise.
Emulators could be a different performance story as they may place more stress on the CPU but that is not something I am familiar with.
Palladin is 100% correct though. The old 32-bit 2GB limitation remains a significant limiting factor in terms of how much graphical memory you can even send over PCIe. Graphics bandwidth is NOT a problem, and won't be until we get to 64-bit native games that actually use more then a GB or so for graphics. When that happens though, I fully expect to see super-high end 16GB GPU's start to appear, as VRAM will start to become a MAJOR limiting factor. When it happens, 64-bit is going to be a MASSIVE thing for gaming.
is it the issue with the games or the gpus? i was reading about gcn yesterday and gcn can use 64bit addressing mode. are game developers sticking with 32bit mode for compatibility's sake? i don't know much about older gpus.
Devs are mostly sticking with 32 bit for WinXP support, nevermind the users with Vista/7 32-bit. Simple as that. And while the top-tier games are starting to move to 64-bit, most are going to stick with 32 until MSFT stops releasing 32-bit OS's.
Remember, even on Windows 64, 32-bit applications compiled without PAE enabled are limited to <2GB of Address Space usage. With PAE, they are locked to no more then 4GB. These are hard limits that can NOT be bypassed. So even modern games are very limited in how much data they can access at any one point in time. They can use more, just not all at once, and you becomes a LOT more affected by HDD/RAM speeds.
Well, adding to that; I remember that buffer pools are kept in ram (for old games at least). I don't know if that model is still being used for new games (I think it was also called "vram mirroring"; used in SLI and XFrie, for sure, but don't remember if single cards as well), so having 64bits will allow games to chug more bandwidth from PCIe since they'll need it badly. Now VGAs will come in 4GB flavors, so 32bit addressing won't be an option anymore (for games) that want to put a buttload of textures or big enough stages/maps in front of us, haha.
To keep the context: PCIe bandwidth will be saturated when we go past 4GB as a regular size for Video cards memory. I'm willing to believe we're at 2GB as "standard" for enthusiasts and upper mainstream. Consoles also have more than that to work with, right? PS4 has like 3-4GB dedicated to video (up to 5GB, IIRC)? XB1 similar. So devs should start saturating PCIe 2.0 more evidently sooner than later... I guess it will depend on the CPU as well to saturate the PCIe interface, haha.
You can actually address larger then 4GB VRAM without a problem, the same way HDD's can address >2TB on a 32-bit OS. You can do this because you are addressing the bus, not the VRAM directly, so you can do some trickery inside the GPU driver to handle larger sizes. Hence why you can SLI 2 4GB cards on Win32 and not have the OS crash due to not having any available memory.
And bringing up 64-bit executable, even though they are compiled as Win64, until they take advantage, you really aren't gaining anything.
I forgot to ask about something.
What does it mean "better than Skylake" excactly?
IPC? IPC*maximum clock? Performance per watt? Performance per $? Performance per mm^2?
FX-8150 was close to i7-2700K in multithreaded benchmarks, but failed at everything else (size, TDP, single thread, IPC, memory brandwith).
I can only postulate, as there was no clarification, though I would assume in the HEDT platform they would be discussing outright performance. However, I cannot clarify as I did not have clarification myself...speculate as you will.
a8 is junk children.. the fx is hardly a gaming cpu because of the just barley useable memory latency and ipc.. if a cpu cant hold over 60fps in everything you should just buy a game system. most of the cpu's on tom's lists are a horrible waist of money except i guess if you go cheap intel you can at least get something good. overclocking does not count because 90 percent of people damage something before they figure it out.
I know that people are really good at breaking things, but looks like it's hard to damage anything during overclocking nowdays (at least at short run). MoBos usually reboot and reset settings if something is wrong.
a8 is junk children.. the fx is hardly a gaming cpu because of the just barley useable memory latency and ipc.. if a cpu cant hold over 60fps in everything you should just buy a game system.
You mean the game systems which now run games @ 30 FPS?