By using this site, you agree to our Privacy Policy and our Terms of Use. Close
Pemalite said:

And they didn't take advantage of it this generation either.


So how many generations do we give AMD before your statement can be regarded as true?

Maybe until the next generation arrives ? It'll be way more pronounced from then on ... 

Pemalite said:

Functionally the Wii/Gamecube GPU's could technically do everything (I.E. From an effects perspective) the Xbox 360/Playstation 3 can do via TEV.
However due to the sheer lack of horsepower, such approaches were generally not considered.

As for the Xbox 360... It's certainly an R500 derived semi-custom part that adopted some features and ideas from R600/Terascale, I wouldn't say it closely resembled Adreno though... Because Adreno was originally derived from Radeon, so of course there are intrinsic similarities from the outset.

Why reinvent the wheel?

No they really couldn't. The Wii's TEV was roughly the equivalent of shader model 1.1 for pixel shaders so they were still missing programmable vertex shaders. The Flipper still used hardware accelerated T&L for vertex and lighting transformations so you just couldn't straight add the feature as easily since it required redesigning huge parts of the graphics pipeline. Both the 360 and the PS3 came with a bunch of their own goodies as well. For the former, you had a GPU that was completely 'bindless' and 'memexport' instruction was nice a precursor to compute shaders. With the latter, you have SPUs which are amazingly flexible like the Larrabee concept and you effectively had the equivalent of compute shaders but it even supported hardware transnational memory(!) like as featured on Intel's Skylake CPU architecture ... (X360 and PS3 had forward looking hardware features that were far into the future) 

The Xbox 360 is definitely closer to an Adreno 2XX design than the R5XX design which is not a bad thing. Xbox 360 emulator developers especially seek Adreno 2XX devices for reverse engineering purposes since it much helps further their goals ... 

Pemalite said:

Actually OpenGL support wasn't to bad for the Radeon 5000/6000 series, even when I was running quad-Crossfire Radeon 6950's unclocked into 6970's. - You might recall I did some bandwidth scaling benchmarks of those cards years ago.


The Radeon 5870 was certainly a fine card that stood the test of time though, more so than my 6950 cards. (I actually have one sitting on my shelf next to me!)

That's not what I heard among the community. AMD's OpenGL drivers are already slow in content creation, professional visualization, games, and I consistently hear about how broken they are in emulation ... (for blender, AMD's GL drivers weren't even on the same level as the GeForce 200 series until GCN came along)

The last high-end game I remembered using OpenGL were No Man's Sky and Doom but until a Vulkan backend came out, AMD got smoked by Nvidia counterparts ...

OpenGL on AMD's pre-GCN arch is a no go ... 

Pemalite said:

Nah. Maxwell and Pascal can be lumped together.
https://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review/4

Kepler and Fermi too.

Volta never really made a big appearance on Desktop... So Turing is the start of a fresh lineup.

And just like if you were building software targeting specific features in AMD's Next-Gen Compute unit... Compatibility will likely break with older variants of Graphics Core Next. It's just the nature of the game.

AMD re-badging hardware obviously does result in less occurrence of this happening... But I want more performance. AMD isn't delivering.

CUDA documentation seems to disagree that you could just group Kepler with Fermi together. Kepler has FCHK, IMADSP, SHF, SHFL, LDG, STSCUL, and a totally new set of surface memory instructions. The other things Kepler has deprecated from Fermi were LD_LDU, LDS_LDU, STUL, STSUL, LONGJMP, PLONGJMP, LEPC but all of this is just on the surface(!) since NVPTX assembly is not Nvidia's GPUs native ISA. PTX is just a wrapper that makes Nvidia GPUs true ISA hidden so there could be many other changes going on underneath there ... (people have to use envytools to reverse engineer Nvidia's blob so that they could make open source drivers)

Even with Turing, Nvidia does not group it together with Volta since Turing has specialized uniform operations ... 

@Bold No developers are worried about new software breaking compatibility with old hardware but just about everyone is worried about new hardware breaking compatibility with old software and that is becoming unacceptable. AMD does NOT actively do this in comparison to Nvidia ... 

These are the combinatorial configurations that Nvidia has to currently maintain ... 

APIs: CUDA, D3D11/12, Metal (Apple doesn't do this for them), OpenCL, OpenGL, OpenGL ES, and Vulkan 

Platforms: Android (still releasing quality drivers despite zero market share), Linux, MacOS, and Windows (all of them have different graphics kernel architecture)

Nvidia has to support ALL of that on at least 3 major instruction encodings which are Kepler, Maxwell/Pascal, Volta, Turing and they only MAKE ENDS MEET in terms of compatibility with more employees than AMD by comparison which only have to maintain the following ... 

APIs: D3D11/12, OpenGL (half-assed effort over here), and Vulkan (Apple makes the Metal drivers for AMD's case plus AMD stopped developing OpenCL and OpenGL ES altogether) 

Platforms: Linux and Windows 

AMD have 2 major instruction encodings at most with GCN all of which are GCN1/GCN2/Navi (Navi is practically a return to consoles judging from LLVM activity) and GCN3/Vega (GCN4 shares the same exact ISA as GCN3) but despite focusing on less APIs/platforms they STILL CAN'T match Nvidia's OpenGL driver quality ... 

Pemalite said:

I am actually not disagreeing with you. I actually find AMD's drivers to actually be the best in the industry right now. - Which was typically the crown nVidia held during the early Graphics Core Next and prior years.

I do run hardware from both companies so I can anecdotally share my own experiences.

AMD drivers are pretty great but they'd be even better if they didn't have to deal with maintaining D3D11 drivers and by extension especially OpenGL drivers ... 

Pemalite said:

DDR5 will not offer the appropriate levels of bandwidth to allow APU's to equal a Geforce 1080. Especially at 7nm... That claim is without any basis in reality.

Either way, Anandtechs analysis isn't painting nVidia outlook as bleak. They are growing, they are diversifying, they have billions in the bank, they are actually doing well. Which is a good thing for the entire industry, competition is a must.

I don't see why not ? A single channel DDR4 module at 3.2Ghz can deliver 25.6 GB/s An octa-channel DDR5 modules clocked at 6.4Ghz can bring a little under 410 GB/s which is well above a 1080 and with 7nm, you play around with a more transistors in your design ...

Anandtech may not paint their outlook as bleak but Nvidia's latest numbers and attempt at acquisition doesn't bode well for them ... 

Pemalite said:

Intels 7nm seems to still be on track with it's original timeline. I am optimistic, but I am also realistic, Intel and Graphics have a shitty history, but you cannot deny that some of the features Intel is touting is wetting the nerd appetite?

I doubt it, Intel are not even committing to a HARD date for the launch of their 10nm products so no way am I going to trust them anytime soon with 7nm unless they've got a contingency plan in place with either Samsung or TSMC ... 

Pemalite said:

Crysis is demanding for today's hardware because it wasn't designed for today's hardware.
Crysis was designed at a time when clockrates were ever-increasing and Crytek thought that trajectory would continue indefinitely.

Today CPU's have gotten wider with more cores, which means that newer successive Cry Engines tend to be more performant.

In saying that, GTA 5 isn't as old as Crysis anyway and certainly has an orders-of-magnitude greater player base.

I believe that benchmarks should represent the games that people are playing today. - If a game is older and based in a Direct X 9/11 era, so be it, it's still representative of what gamers are playing... In saying that, they also need newer titles to give an idea of performance in newer titles.

It's like when Terascale was on the market, it had amazing Direct X 9 performance... But it wasn't able to keep pace in newer Direct X 11 titles, hence why AMD architectured VLIW 4, to give a better balance leaning towards Direct X 11 titles as each unit was able to be utilized more consistently.

So having a representation of mixed older and newer games is important in my opinion as it gives you a more comprehensive data point to base everything on.

We should not use old games because it's exactly as you said, "it wasn't designed for today's hardware" which is why we shouldn't skew a benchmark suite's to be heavily weighted in favour of past workloads ...