Another 6 months before VEGA?

[CSI_PC]

Do we know the actual power usage on P100 and how much of that is consumed by the HBM?

If the performance boost was worth it NV could have updated NVlink to support more power.

Unfortunately it is academic and pointless to try and correlate this as a confirmation Samsung is the issue, the card is at the limits for its NVLink and PCIe spec (250W) used by Nvidia and still with double the bandwidth of previous Nvidia Tesla cards.
Again there is only the Samsung production news, until we see other products (unlikely outside of Nvidia for awhile if rumours true they locked the production orders to themselves) or the latest 1H 2017 product selection guide.
Do you really think Samsung can still only do as you are suggesting 1.4Gbps since they went into product back in early 2016?
The Nvidia cards still have not changed their HBM2 clock rates.
Cheers

 

[Shintai]

Cards wont change their clocks after release. But I think its clear that at P100 release, 1.4Ghz was what Samsung could do.

Hynix is just first able now in Q1 to deliver 1.6Ghz.

 

[CSI_PC]

Cards wont change their clocks after release. But I think its clear that at P100 release, 1.4Ghz was what Samsung could do.

Hynix is just first able now in Q1 to deliver 1.6Ghz.

They could if the issue as exmaster76 is getting at that HBM2 is not affecting the 250W and 300W ceiling spec the P100 is hitting - tbh we both know that 300W and the 250W would mean it is impossible to increase the clocks of HBM2.
There is not going to be a new Pascal Tesla model with HBM2, meaning all they can do is revise existing P100.

You keep on about 1.4Gbps, but sorry there is no proof as it is not possible to use the P100 as an example and there is nothing else apart from the production news Samsung released that may or may not be true depending upon ones opinion.
Cheers

 

[N4CR]

God damn racist, xenophobic, nazi, islamophobic ismist Trump is at fault for this! Trump is literally hitler and AMD is a big bad corporation and trump told them to delay it to troll us so we'd REEEEEEEEEEeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

edit: AMD IS RED ITS RUSSIAN GUUYZ!! TRUMP IS RUSSIAN AND THEY ARE SPYING ON HARDOCP USERS FOR THE TARRARRISTS HBM2 STASHES!! ISIS AND TRUMP STOLE ALL THE 6GHZ HMB3 THATS WHY THE P100 RUNS SO SLOW!

 

[Ieldra]

God damn racist, xenophobic, nazi, islamophobic ismist Trump is at fault for this! Trump is literally hitler and AMD is a big bad corporation and trump told them to delay it to troll us so we'd REEEEEEEEEEeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

edit: AMD IS RED ITS RUSSIAN GUUYZ!! TRUMP IS RUSSIAN AND THEY ARE SPYING ON HARDOCP USERS FOR THE TARRARRISTS HBM2 STASHES!! ISIS AND TRUMP STOLE ALL THE 6GHZ HMB3 THATS WHY THE P100 RUNS SO SLOW!

Don't do drugs kids

 

[Spoonie_G]

LOL all I asked why you feel you need watercooling thats all. Cuz it does cost 60-70 more especially on pascal when it runs cool as hell. That's all. Now I did say what you want is what you want, no one can change that. You don't like being asked a question? Stop assuming everyone is out to get you, or you are mad over getting advice in a forum?

anyways, lets end it.

Cheers.

Dude, This is a snide remark

"But I guess if thats what you want then thats what you want lol".

Why are you "lol"'ing my purchase? What is that all about? Why do you even care about what someone else purchases enough so to "lol" them about it? Can you see why someone wouldn't be cordial to you after saying some mess like that?

 

[noko]

Unfortunately you wont find the parts catalogue, only one currently available is the 1H 2016 from Samsung and it has no mention of HBM2.
But it is not vaporware because Nvidia has been using it since summer 2016 in their two P100 models, and these really did ramp up in production late Q3/early Q4 2016.
Rumour (emphasis on that point) though last year was that Nvidia had tied up all of Samsung's HBM2, I think latest Samsung parts catalogue 1H 2017 comes out around May-June.
Cheers

Samsung has exclusive deal with Nvidia, no one else has a product using HBM2 thus not in cat.

AMD has exclusive deal with Hynix, the 2gz HBM2 could be all slotted for AMD or by contract first dibs thus not available for anyone else.

 

[Shintai]

Samsung has exclusive deal with Nvidia, no one else has a product using HBM2 thus not in cat.

AMD has exclusive deal with Hynix, the 2gz HBM2 could be all slotted for AMD or by contract first dibs thus not available for anyone else.

That's untrue. There have been other HBM2 products out for quite some time. Couple of examples:
https://www.altera.com/content/dam/...literature/pt/stratix-10-mx-product-table.pdf
https://www.xilinx.com/products/silicon-devices/fpga/virtex-ultrascale-plus.html

The exclusive deals seems to be made up rather than reality. They dont make sense from a business perspective either, unless really big bucks is paid and you are willing to alienate other customers that will hurt your future business.

 

[CSI_PC]

That's untrue. There have been other HBM2 products out for quite some time. Couple of examples:
https://www.altera.com/content/dam/...literature/pt/stratix-10-mx-product-table.pdf
https://www.xilinx.com/products/silicon-devices/fpga/virtex-ultrascale-plus.html

The exclusive deals seems to be made up rather than reality. They dont make sense from a business perspective either, unless really big bucks is paid and you are willing to alienate other customers that will hurt your future business.

I think both of those are SK Hynix collaboration or associated with/using.
Definitely Altera but will need to check Xilinx.
Cheers

 

[Shintai]

I think both of those are SK Hynix collaboration or associated with/using.
Definitely Altera but will need to check Xilinx.
Cheers

Feel free to document it if you think so.

 

[NKD]

Dude, This is a snide remark


Why are you "lol"'ing my purchase? What is that all about? Why do you even care about what someone else purchases enough so to "lol" them about it? Can you see why someone wouldn't be cordial to you after saying some mess like that?

Really? Wtf? You sound like a butt hurt kid. That was the point we all get what we want, it was me saying my opinion doesn't matter. Get real bro. Don't comment to me again. You are annoying, getting offended for no apparent reason. Grow up. I won't be replying to anything you say. Nice talking to you.

 

[NKD]

That's untrue. There have been other HBM2 products out for quite some time. Couple of examples:
https://www.altera.com/content/dam/...literature/pt/stratix-10-mx-product-table.pdf
https://www.xilinx.com/products/silicon-devices/fpga/virtex-ultrascale-plus.html

The exclusive deals seems to be made up rather than reality. They dont make sense from a business perspective either, unless really big bucks is paid and you are willing to alienate other customers that will hurt your future business.

True, it doesn't make sense but I can actually believe AMD having exclusive on the 2ghz part for a certain time since they helped with HBM.

But yea long term it doesn't make any sense but I have seen a lot of company do short term exclusives.

 

[Spoonie_G]

Really? Wtf? You sound like a butt hurt kid. That was the point we all get what we want, it was me saying my opinion doesn't matter. Get real bro. Don't comment to me again. You are annoying, getting offended for no apparent reason. Grow up. I won't be replying to anything you say. Nice talking to you.

How about you not comment to me? You are calling me butthurt when the reality is that you cannot take it when someone points out how much of a jerk you are. You are right, we get what we want. But only an adolescent would "LOL" someone about it. Grow up.

 

[CSI_PC]

Feel free to document it if you think so.

Here is the Altera: Altera Discloses Industry’s First Heterogeneous SiP Devices that Integrate HBM2 DRAM with FPGAs
https://newsroom.intel.com/news-rel...eneous-sip-devices-integrate-hbm2-dram-fpgas/

Altera Corporation (Nasdaq: ALTR) today disclosed the industry’s first heterogeneous System-in-Package (SiP) devices that integrate stacked High-Bandwidth Memory (HBM2) from SK Hynix with high-performance Stratix® 10 FPGAs and SoCs. Stratix 10 DRAM SiP represents a new class of devices that are specifically architected to meet the most demanding memory bandwidth requirements in high-performance systems.

Also worth noting Stratix 10 just went into sampling Oct 2016.

For Xilinx I will need to look in as I am not entirely sure but thought it was SK Hynix.

Edit:
Just checked and looks like the Stratix 10 with HBM (Stratix 10 MX product) will not go into production until middle of 2017.
Cheers

 

[CSI_PC]

That's untrue. There have been other HBM2 products out for quite some time. Couple of examples:
https://www.altera.com/content/dam/...literature/pt/stratix-10-mx-product-table.pdf
https://www.xilinx.com/products/silicon-devices/fpga/virtex-ultrascale-plus.html

The exclusive deals seems to be made up rather than reality. They dont make sense from a business perspective either, unless really big bucks is paid and you are willing to alienate other customers that will hurt your future business.

Just a heads up none of these products will be available until mid-late 2017, so there is still the possibility of a sort of production exclusivity (or what I think in the case of Nvidia is buying a massive chunk of the production order now-future and so tying it to them), but agree not sure if SK Hynix can be tied down as it has many collaborations although those companies inlcuding AMD probably get preferential orders.

While Altera did go into sampling status Oct 2016 I am not sure it includes the MX family (HBM2 spec version) and the expected shipping date for the MX is mid 2017 earliest.
Looking at Xilinx, the Ultrascale+ HBM (as they call it) is only on a roadmap to date and maybe late 2017, also the product has a spec of 32GB and 64GB HBM2 memory so that cannot be this release.

I double checked other sources and seems correct, also re-inforcing this the only Virtex Ultrascale+ eval board available is the DDR4.

I must say I am having problems confirming what memory Xilinx is using (well I guess they were expecting 8Hi so narrows it down, or maybe 8GB density stack fo the 32GB model *shrug*); I am trying to find a specific presentation I have/read that goes into a bit of detail from Xilinx but a nightmare to find.
Cheers

 

[Anarchist4000]

PS just a hint graphics doesn't really use those...... CPU side of things yeah, but not graphics, and that is what you are saying, that graphics uses those, cause you were talking about shaders, and those two don't have anything to do with graphics portion of a game. Although with LLAPI's you can intiate some things to happen at a certain time with a mutex and lock down threads with semamorphes they are really only when critical path becomes an issue and that is rare if you want to use async shaders lol, so pretty much you don't want to use them if you want things done without user intervention in graphics.

You don't think HSA that is executing CPU code paths on the GPU would use those? Current shaders won't really use them, the ISA will use similar mechanisms.

They never used nV intristics because they weren't available at the time, I suggest you look at the time line when nV intrinsic were available, they still aren't fully available....

So Doom is a bad example because they didn't use Nvidia's intrinsics that still aren't fully available? Odd with all the claims Nvidia isn't behind with Vulkan drivers that after all this time they still lack the intrinsics that they don't have full hardware support for.

Oh so that is how AMD is marketing their cards now, PCI slot max? They didn't do that with with the other instinct cards......

Marketing them as being compliant with the specification? The only card it applied too is full of question marks on capabilities.

Oh you fabled SM 6.0 that you talked about 8 months ago? You want me to pull up that post, it was about Polaris man.... yeah now its for Vega.... What lets see what its going to be for Navi next?

Go ahead, it will apply to all of them. The same shit is used for XB1 and that's been around for a while now. I'd imagine it applies to Navi as well.

you don't feel like it because you are talking out of you ass...... Still haven't seen a game where AMD has any lead in VR over its competition in comparative cards yet.....

Because there aren't any real VR games beyond the indie dev shit that plagues the market. It's all small production shit built on UE or unity for the most part. Even the VR industry guys like Carmack admit as much.

So you're telling be because AMD strictly complies to OpenGL specs, they are slower while Nvidia cuts corner for huge performance benefits that users can't seem to differentiate in gameplay? Any links that you can cite? You're claiming bold claims.

http://www.extremetech.com/gaming/1...programmer-discusses-wretched-state-of-opengl
Fairly widely known issue. Hear about it a lot more with linux ports as they always complain about needing different paths for each vendor because the results differ.

Oh, so you're telling me an average increase of 5% in performance over an AMD GPU's lifetime is suddenly enough for AMD GPUs to still be relevant when a new GPU generation comes out, that gives you anywhere between 50-100% increase in performance? Any more bullshit that's busted you wanna throw out there? Still clinging to AMD FineWine FUD?

That's not what the "FindWine" is about. Games generally improve over time, but the concept was that the relative performance gap between cards increases as newer games release. Pull up some 290 vs 780 benchmarks in this years games and there's a trend.

Dude he just made shit up about mutexes and semaphores in graphics programming, (neither of which have much do with graphics, more to do with how the program will interact with the OS though) pretty much just threw words out there and didn't understand what he was posting, so can you even have a discussion with a person like this? Calls us kids and then says crap lol.

Showing your ignorance here. Saying they're used, but not used? They become relevant once you start looking at multiple threads of execution on a GPU. Something that only starts to occur with async shaders, but even that is a relatively narrow scope. Get into multi-engine with physics, sound, etc running parallel to graphics on the card and suddenly those terms mean something. They surely aren't in the specifications because they look cool on paper.

Oh you sneaky little bugger you! Posting reviews from mid July, how subtle! How fresh!

I'm not the one that claimed [H] already did the work. Well that's the work and I referenced it.

Yes it would be fan-fucking-tastic if Kyle were to invent an entirely new, far more contrived, benchmarking system and performance metrics just to paint AMD in the best light possible. Because what really matters to the consumer is whether or not their video card is more efficient than the competition's when slowed to a crawl. Not like power-frequency curve matters or anything, 500mhz @ 50W polaris best GPU

It's not that contrived, but if the intention was to settle which architecture was more power efficient, that would do it. Everyone keep saying how one vendor has better perf/watt than the other so I proposed a test for it.

 

[razor1]

You don't think HSA that is executing CPU code paths on the GPU would use those? Current shaders won't really use them, the ISA will use similar mechanisms.

They will not use them in a direct way, synchronization is different which will affect the threading between between the GPU and CPU, so there needs to be some sort of switch or translation going on in the background for the same code to work across different processors. Which I don't have the information to, nor where to find that information because dev's shouldn't need to worry about that, so I don't see your point.

So Doom is a bad example because they didn't use Nvidia's intrinsics that still aren't fully available? Odd with all the claims Nvidia isn't behind with Vulkan drivers that after all this time they still lack the intrinsics that they don't have full hardware support for.

Its a good example of full potential or good potential of AMD's Vulkan implementation in drivers, that is all it is.

They don't lack it, they just didn't work on them at a driver level yet. Different strokes for different folks. What is priority for nV is not what is priority for AMD when it comes to driver development.

Marketing them as being compliant with the specification? The only card it applied too is full of question marks on capabilities.

That is not how they are marketing their graphics products nor their CPU products for that matter when it comes to TDP, or power usage.

Go ahead, it will apply to all of them. The same shit is used for XB1 and that's been around for a while now. I'd imagine it applies to Navi as well.

Right and there is no drivers that use SM 6.0 yet...... lets see how dev's do without them. So when those drivers come out how long to do you think it will take for software to come out that uses SM 6.0 and what is the release date of Vega, and Vega console parts? Again, they don't match up. with anything in the short term in Vega's life time.

Because there aren't any real VR games beyond the indie dev shit that plagues the market. It's all small production shit built on UE or unity for the most part. Even the VR industry guys like Carmack admit as much.

So how do you expect your assumptions to be valid when there is NO data to back up what you say. The only data available to us in regards to VR performance are indie games right now, and AMD is way behind.

http://www.extremetech.com/gaming/1...programmer-discusses-wretched-state-of-opengl
Fairly widely known issue. Hear about it a lot more with linux ports as they always complain about needing different paths for each vendor because the results differ.

If you read the article you will see it has a lot of do with driver development. Now saying that yeah OGL is a complicated mess, so AMD's attempts of rewriting their driver code for Ogl, twice, failed miserably. But nV seems to have no problem, why is that?

Showing your ignorance here. Saying they're used, but not used? They become relevant once you start looking at multiple threads of execution on a GPU. Something that only starts to occur with async shaders, but even that is a relatively narrow scope. Get into multi-engine with physics, sound, etc running parallel to graphics on the card and suddenly those terms mean something. They surely aren't in the specifications because they look cool on paper.

Your assumption is GPU's are going to work like CPU's, but the data sets for GPU's are already set up for multithreading (multiple pipeline execution) they don't need things like that, that is why its not important on GPU's to have anything remotely resembling them. This didn't start with async compute or multi engine man, it was set up since the beginning of GPU development. It was the center and front of GPU development from the start.

I'm going to have to qoute Al Gore here "I invented the internet" sorry no async compute didn't create the need for HSA nor GPGPU nor multiple execution of a GPU. Silly to think that it had so much weight on multi pipeline execution and syncronization on GPU where it wasn't even around till last year!

 

[Anarchist4000]

They will not use them in a direct way, synchronization is different which will affect the threading between between the GPU and CPU, so there needs to be some sort of switch or translation going on in the background for the same code to work across different processors. Which I don't have the information to, nor where to find that information because dev's shouldn't need to worry about that, so I don't see your point.

That still depends on how the instructions were implemented. Some hardware designs can translate instructions on the fly in hardware. Devs wouldn't have to worry about that, but CPU code could actually run on a GPU given supported instructions. I'm not claiming this capability will be present, but technology, especially with HSA, is moving in that direction. All we know about the latest AMD architectures is that they are being designed to work alongside Zen more directly.

That is not how they are marketing their graphics products nor their CPU products for that matter when it comes to TDP, or power usage.

My point was that it wasn't even marketed as a certain TDP. The claim was ambiguous to a point and only stating it would fit within the standard power envelope of the slot.

Right and there is no drivers that use SM 6.0 yet...... lets see how dev's do without them. So when those drivers come out how long to do you think it will take for software to come out that uses SM 6.0 and what is the release date of Vega, and Vega console parts? Again, they don't match up. with anything in the short term in Vega's life time.

Not public at least, but my understanding was that some console devs likely have access. Most, if not all of the new capabilities, existing within console kits for XB1. SM6 should be relevant even on older hardware. Inclusive of instructions all IHVs should be able to implement with little difficulty or were suitably useful enough to be required, even if expensive to implement. For the most part it looked like the XB1 instruction set to make porting more transparent from console. Andrew (the Intel guy) and some of the others discussed this a while back over on B3D.

So how do you expect your assumptions to be valid when there is NO data to back up what you say. The only data available to us in regards to VR performance are indie games right now, and AMD is way behind.

Not assumptions, the issues have been laid out by VR and engine developers. There was a blog on this with the latest UE release. Nvidia's TBDR doesn't apply to forward renderers, to the best of my knowledge, and devs have been saying deferred doesn't work well for VR.

If you read the article you will see it has a lot of do with driver development. Now saying that yeah OGL is a complicated mess, so AMD's attempts of rewriting their driver code for Ogl, twice, failed miserably. But nV seems to have no problem, why is that?

Because even if they wrote the driver perfectly compliant, it wouldn't work because many games were coded to Nvidia's implementation. So they would need to write the driver, then proceed to optimize all the games around the specification. OGL is simply a mess and suffers from the same issues as DX11.

 

[razor1]

That still depends on how the instructions were implemented. Some hardware designs can translate instructions on the fly in hardware. Devs wouldn't have to worry about that, but CPU code could actually run on a GPU given supported instructions. I'm not claiming this capability will be present, but technology, especially with HSA, is moving in that direction. All we know about the latest AMD architectures is that they are being designed to work alongside Zen more directly.

Oh so we are guessing again on things we don't know, speculation is all good and fine, but what are the indications of this for these products? not sure if there are any, I haven't heard anything about them yet.

My point was that it wasn't even marketed as a certain TDP. The claim was ambiguous to a point and only stating it would fit within the standard power envelope of the slot.

The claim isn't ambiguous, the claim was for partners and OEM's to understand how to start building systems around these products. By saying < a certain figure, expect it to be somewhere below that figure, not 30% less or 50% less, because AMD would not want their partners to make systems that cost more if they don't have to...... Business implications of saying one thing but meaning another are going to cause frustration with AMD's partners, AMD doesn't need that at this point. You see them managing end user and partner expectations for the past launch of Polaris, you expect them to not do that now? If I was to say this will be like the r600 or Fiji launch that would be miss leading, because AMD is not doing that with expectations, they have been fairly accurate with of the numbers they have been giving, although in some areas a particular point, not in general. You seem to forget the insight presentation wasn't for end users....... although they used to give information to them it was more from AMD's partners and system builders.

Not public at least, but my understanding was that some console devs likely have access. Most, if not all of the new capabilities, existing within console kits for XB1. SM6 should be relevant even on older hardware. Inclusive of instructions all IHVs should be able to implement with little difficulty or were suitably useful enough to be required, even if expensive to implement. For the most part it looked like the XB1 instruction set to make porting more transparent from console. Andrew (the Intel guy) and some of the others discussed this a while back over on B3D.

Oh yeah and that was stated about sm 3.0, sm 4.0, sm 5.0........

Not assumptions, the issues have been laid out by VR and engine developers. There was a blog on this with the latest UE release. Nvidia's TBDR doesn't apply to forward renderers, to the best of my knowledge, and devs have been saying deferred doesn't work well for VR.

Its an assumption because there is no data to tell use how forward renderers are going to work on different IHV hardware in VR. Big ass assumption. You can even leave out TBDR from this discussion.

Because even if they wrote the driver perfectly compliant, it wouldn't work because many games were coded to Nvidia's implementation. So they would need to write the driver, then proceed to optimize all the games around the specification. OGL is simply a mess and suffers from the same issues as DX11.

Well if AMD (should say ATi) got their shit together on OGL from the start that problem wouldn't be there right? Then again, DX11 is not nV favored lol, DX11 was brought to you by both companies, just one did tessellation right where another didn't in their GPU and the AMD driver overhead is not nV's take on the DX 11 API, so .... don't even know how you can correlate between the two.

 

[Pieter3dnow]

Well if AMD (should say ATi) got their shit together on OGL from the start that problem wouldn't be there right? Then again, DX11 is not nV favored lol, DX11 was brought to you by both companies, just one did tessellation right where another didn't in their GPU'

Wasting a lot of time AMD did something better then that.

The idea that you are going to optimize for a very old and very outdated API which did nothing more then segment the market except for one vendor says it all. OpenGL ES is the result of how well OpenGL functions. The vendor specific paths are notoriously bad. Wasn't there an OpenGL game a few years back that was streaming textures on console just fine but the same thing on the PC started producing all kinds of popping and other annoying things.

 

[CSI_PC]

So Doom is a bad example because they didn't use Nvidia's intrinsics that still aren't fully available? Odd with all the claims Nvidia isn't behind with Vulkan drivers that after all this time they still lack the intrinsics that they don't have full hardware support for.

http://www.extremetech.com/gaming/1...programmer-discusses-wretched-state-of-opengl
Fairly widely known issue. Hear about it a lot more with linux ports as they always complain about needing different paths for each vendor because the results differ.


That's not what the "FindWine" is about. Games generally improve over time, but the concept was that the relative performance gap between cards increases as newer games release. Pull up some 290 vs 780 benchmarks in this years games and there's a trend.

On Vulkan Nvidia back in July 2016 article regarding some Nvidia related functions and Vulkan did say:

In parallel, we are also working with the respective Khronos working groups in order to find the best way to bring cross-vendor shader intrinsics already standardized in OpenGL over to Vulkan and SPIR-V. We are furthermore working on Vulkan and SPIR-V extensions to expose our native intrinsics, but prioritized the cross-vendor functionality higher, especially since there is notable overlap in functionality.

Opengl I think it is a bit more nuanced, if AMD followed everything by the book and impeccable what went wrong with the Rage and the id Tech 5 engine.
A lot of the issues were not related to the engine.

FineWine, it is noticable that some of the modern-recent games are hit and miss when it comes to Fiji and Hawaii compared to Polaris, yeah not currently as bad though as we see between Kepler to Maxwell but a possible trend as consoles and AMD move forward with Polaris/Vega (not necessarily consoles but some tech of theirs is in the SoCs).
But we are all digressing from Vega.
Cheers

 

[Anarchist4000]

Oh so we are guessing again on things we don't know, speculation is all good and fine, but what are the indications of this for these products? not sure if there are any, I haven't heard anything about them yet.

Educated speculation. We know HSA/APUs have been a focus and seamlessly pushing threads onto a GPU would be beneficial. We haven't seen any details of what a Vega core looks like either. AMD could very well apply the X86 or Arm instruction set to Vega with SSE/AVX being SIMD work. I doubt that will be the case, but it's a possibility. Most likely however is the LLVM model where code is compiled to an intermediate level and then JIT for whichever processor gets used. Quite a few chip companies have had hardware implementations of the translations.

EDIT. Take a look at the Soft Machines VISC stuff that Intel gobbled up last year. No reason AMD couldn't have done something similar.

The claim isn't ambiguous, the claim was for partners and OEM's to understand how to start building systems around these products. By saying < a certain figure, expect it to be somewhere below that figure, not 30% less or 50% less, because AMD would not want their partners to make systems that cost more if they don't have to...... Business implications of saying one thing but meaning another are going to cause frustration with AMD's partners, AMD doesn't need that at this point. You see them managing end user and partner expectations for the past launch of Polaris, you expect them to not do that now? If I was to say this will be like the r600 or Fiji launch that would be miss leading, because AMD is not doing that with expectations, they have been fairly accurate with of the numbers they have been giving, although in some areas a particular point, not in general. You seem to forget the insight presentation wasn't for end users....... although they used to give information to them it was more from AMD's partners and system builders.

It is ambiguous in regards to the actual power of the card. The Instinct Mi25 was passively cooled in a server design standardized on 300W cooling capacity per slot. Regardless of how much heat needs dissipated, those fans are running all out. Actual partners and builders already had access to that information as racks were already designed and displayed. Even then it's a rack assuming 300W per slot and standardized card dimensions.

Its an assumption because there is no data to tell use how forward renderers are going to work on different IHV hardware in VR. Big ass assumption. You can even leave out TBDR from this discussion.

We've seen how forward vs deferred work in other games. While not VR, it does provide some indications.

On Vulkan Nvidia back in July 2016 article regarding some Nvidia related functions and Vulkan did say:

Not implying that's the incorrect approach. I'd imagine what happened was AMD exposed the feature at the request of devs porting something from console. Even in the case of Doom they would have had the console dev tools for originally authoring and optimizing the shaders.

 

[IcePickFreak]

Don't do drugs kids

You gotta be on drugs to spend any amount of time in any graphics card forum. If you're not, you'll be looking for some soon.

 

[Maddness]

You gotta be on drugs to spend any amount of time in any graphics card forum. If you're not, you'll be looking for some soon.

That's by far the best post in this thread.

 

[ChosenUno]

http://www.extremetech.com/gaming/1...programmer-discusses-wretched-state-of-opengl
Fairly widely known issue. Hear about it a lot more with linux ports as they always complain about needing different paths for each vendor because the results differ.

So Nvidia actually pushes OpenGL forward and make it work instead of focusing on spec, while AMD wants to force devs into their own API garden, while neglecting support and optimizing for APIs devs actually use. Cool.

That's not what the "FindWine" is about. Games generally improve over time, but the concept was that the relative performance gap between cards increases as newer games release. Pull up some 290 vs 780 benchmarks in this years games and there's a trend.

Upon 290 release, 780 and 290 are neck and neck. GTX 780 was released end of May, 2013. Over 5 months later, R9 290 was released and AMD finally has that level of performance. Good.

By the release of the 980, they're still neck and neck, Sep 2014.

Around the release of the 950, R9 290 pulled away by 10%. Aug 2015.

Finally, upon the release of the 1080, May 2016, the gap is 20%. Finally a significant gap, but it comes after Kepler is basically EOL'ed and irrelevant. And at the price point the 780 originally released at, the 1080 is now 2.6 times faster for roughly the same price. And that level of performance is now low-end/mainstream.

3 years for a 20% "increase" in performance is a hollow victory. In addition, a possible explanation for the low performance is due to the rather lacking amount of VRAM the 780 possesses.

Maybe like fine wine, when we come back to this in 50-100 years the 290 will be the card to buy again?

 

[razor1]

Educated speculation. We know HSA/APUs have been a focus and seamlessly pushing threads onto a GPU would be beneficial. We haven't seen any details of what a Vega core looks like either. AMD could very well apply the X86 or Arm instruction set to Vega with SSE/AVX being SIMD work. I doubt that will be the case, but it's a possibility. Most likely however is the LLVM model where code is compiled to an intermediate level and then JIT for whichever processor gets used. Quite a few chip companies have had hardware implementations of the translations.

EDIT. Take a look at the Soft Machines VISC stuff that Intel gobbled up last year. No reason AMD couldn't have done something similar.

So you don't know? Ok lets leave it at that.

It is ambiguous in regards to the actual power of the card. The Instinct Mi25 was passively cooled in a server design standardized on 300W cooling capacity per slot. Regardless of how much heat needs dissipated, those fans are running all out. Actual partners and builders already had access to that information as racks were already designed and displayed. Even then it's a rack assuming 300W per slot and standardized card dimensions.

err I understand that, just like people believed <150 watts for Polaris was like 120 watts lol, instead it ended up higher than 150 watts, guess what they used the same figure for Polaris Instinct in racks too <150 and we know that isn't right. Either way, they aren't being vague with polaris instinct why would you think vega instinct is vague when other numbers are lies lol. Maybe <300 means, 330 watts? Now that would be AMD marketing for you. I'm giving them the benefit of the doubt at 275 ok 250 but I doubt its less than that.

We've seen how forward vs deferred work in other games. While not VR, it does provide some indications.

Yep not in VR so we don't know what the implications are yet, so.......

 

[CSI_PC]

Just a point on the 300W cooling, it is also importantly TBP board power consideration (usually aligns with TDP that is not just core die) and they could standardise on either 250W or 300W.
This is seen with Nvidia that has both these categories for the P100 (the PCIe is 250W spec), and the P40 and lower models at 250W.
Currently then Vega is not hitting below 250W.
Remember back in September they were stating 225W and that would be a 250W spec if they could had kept to that estimation.
Cheers

 

[razor1]

Just a point on the 300W cooling, it is also importantly TBP board power consideration (usually aligns with TDP that is not just core die) and they could standardise on either 250W or 300W.
This is seen with Nvidia that has both these categories for the P100 (the PCIe is 250W spec), and the P40 and lower models at 250W.
Currently then Vega is not hitting below 250W.
Remember back in September they were stating 225W and that would be a 250W spec if they could had kept to that estimation.
Cheers

I agree, server specs are pretty strict because of the form factor they go in, none of the specs are ever vague lol.

 

[Anarchist4000]

So Nvidia actually pushes OpenGL forward and make it work instead of focusing on spec, while AMD wants to force devs into their own API garden, while neglecting support and optimizing for APIs devs actually use. Cool.

No, they allowed sloppy code to function and devs using their hardware just tested until it "worked". Hence it doesn't run on actual compliant hardware. AMD didn't force devs into anything, it was the devs that got AMD to make the new API because they were tired of the BS.

Finally, upon the release of the 1080, May 2016, the gap is 20%. Finally a significant gap, but it comes after Kepler is basically EOL'ed and irrelevant. And at the price point the 780 originally released at, the 1080 is now 2.6 times faster for roughly the same price. And that level of performance is now low-end/mainstream.

So you're acknowledging the FineWine concept is accurate? AMD products don't age well because the Nvidia parts are EOL'd after a couple years? That kind of sounds like they're pulling ahead over time. Getting better, relatively, with age.

guess what they used the same figure for Polaris Instinct in racks too <150 and we know that isn't right

Do you have any evidence the Instinct cards are exceeding that 150W limit? That would be rather surprising with the way the thermal limits are designed.

Just a point on the 300W cooling, it is also importantly TBP board power consideration (usually aligns with TDP that is not just core die) and they could standardise on either 250W or 300W.
This is seen with Nvidia that has both these categories for the P100 (the PCIe is 250W spec), and the P40 and lower models at 250W.
Currently then Vega is not hitting below 250W.
Remember back in September they were stating 225W and that would be a 250W spec if they could had kept to that estimation.
Cheers

And what specifically does that change with the actual system? 250W parts work just fine in 300W envelopes and I doubt vendors are changing out fans. The specification might be slightly different but the actual implementation is likely identical.

I agree, server specs are pretty strict because of the form factor they go in, none of the specs are ever vague lol.

So you're suggesting a 250W part might burn out a 300W specced slot?

 

[razor1]

Do you have any evidence the Instinct cards are exceeding that 150W limit? That would be rather surprising with the way the thermal limits are designed.

As long as P10 Instinct doesn't boost as much as the desktop variant they will be fine. But then the flops figure doesn't add up does it?

And what specifically does that change with the actual system? 250W parts work just fine in 300W envelopes and I doubt vendors are changing out fans. The specification might be slightly different but the actual implementation is likely identical.

Vendors don't do that, they only use parts that will fit with what they need, cause a 250watt chassis, is cheaper than a 300watt chassis, so they make more money or less money depending on that added to the individual component changes from the different TDP needs. Server chassis business is pretty cut throat when it comes to prices and competition. Remember the talk about Zen and servers and why Zen won't get picked up, its not the price of the chip itself that will drive sales, cause infrastructure costs are much higher then component costs.......and infrastructure includes chassis specs cause that influences utility bills too.

This is why those numbers AMD gave, they just didn't throw them out as vagaries, they have a very good idea where its going to end up when released. If they do and partners and vendors build chassis's based on those specs and they come out different at the end, its a lot money those guys have to eat for no reason what so ever.

So you're suggesting a 250W part might burn out a 300W specced slot?

When did I say that? I said I gave them the benefit of the doubt, and most likely its not going to hit as low as 250 watts as CSI_PC explained.

 

[Anarchist4000]

Vendors don't do that, they only use parts that will fit with what they need, cause a 250watt chassis, is cheaper than a 300watt chassis, so they make more money or less money depending on that added to the individual component changes from the different TDP needs. Server chassis business is pretty cut throat when it comes to prices and competition. Remember the talk about Zen and servers and why Zen won't get picked up, its not the price of the chip itself that will drive sales, cause infrastructure costs are much higher then component costs.......and infrastructure includes chassis specs cause that influences utility bills too.

This is why those numbers AMD gave, they just didn't throw them out as vagaries, they have a very good idea where its going to end up when released. If they do and partners and vendors build chassis's based on those specs and they come out different at the end, its a lot money those guys have to eat for no reason what so ever.

Not necessarily, as overspecced parts will likely lower support costs. Similar components also help with inventory. Larger power supplies are also more efficient on top of more robust if maintenance and utility bills are a concern. I'm sure they know where it will land, and even 200W is likely too close for comfort in a 250W spec'd slot.

When did I say that? I said I gave them the benefit of the doubt, and most likely its not going to hit as low as 250 watts as CSI_PC explained.

You implied that they aren't vague with the specs, in which case 250W wouldn't be compatible with 300W. Obviously the guys building the chassis had the specs as they made some already. The presentation however listed a less than absolute term, which makes sense if they are still obscuring details prior to launch.

 

[Shintai]

The WX 7100 Pro got tested at Toms. Its using ~140W and its clock profile looks like this.

Lets just say its 1243Mhz boost is a fairy tale.

As long as P10 Instinct doesn't boost as much as the desktop variant they will be fine. But then the flops figure doesn't add up does it?

We have a winner.

 

[razor1]

Not necessarily, as overspecced parts will likely lower support costs. Similar components also help with inventory. Larger power supplies are also more efficient on top of more robust if maintenance and utility bills are a concern. I'm sure they know where it will land, and even 200W is likely too close for comfort in a 250W spec'd slot.

No that is not how it works..... I think you should talk to a datacenter or server manager if you want to know those things, that isn't what I was told.

You implied that they aren't vague with the specs, in which case 250W wouldn't be compatible with 300W. Obviously the guys building the chassis had the specs as they made some already. The presentation however listed a less than absolute term, which makes sense if they are still obscuring details prior to launch.

You assumed that is what I implied, which I didn't, I have stated it twice thus far the reason why it wouldn't be less that 250watts, otherwise they would have given 250 watts as the spec as there are chassis with that TDP requirement. Even after CSI_PC stated it point blank, I don't see why you are even going down that line of thought. There is no implication in my statement, its just black and white, if it was lower than 250 they would give a TDP rating of less than 250. Simple, the lowest it will be for Vega Instinct at the current specs (which seem to be the same specs as the desktop variant that was shown) is 250 watts the highest is 300 watts, so its going to fall between those two figures, which I picked 275 because its the median.

 

[CSI_PC]

And what specifically does that change with the actual system? 250W parts work just fine in 300W envelopes and I doubt vendors are changing out fans. The specification might be slightly different but the actual implementation is likely identical.

Eh?
If their card managed 225W they would spec it to 250W NOT 300W....
They limit their market if they just spec it to 300W, why the heck do you think Nvidia goes to lengths to hit 250W and actually state that as spec for their upper cards instead of just saying 300W; hint only their K80 and the NVLink P100 are spec'd at 300W.

Also, if AMD did not care about HPC-pro spec under 300W, they would not had done estimations (important fact) back in September with around 225W, but now newer slides say under 300W.

By your logic back then should also be shown as under 300W but it wasn't.
This is a silly argument Anarchist, and would be bloody unprofessional of AMD if they just go "yeah lets say under 300W spec and ignore the usual 250W even if we are under that".

If accurate spec is wanted by consumers, what do you think HPC feel as they are very interested in the watt/performance envelope and calculations for their node/nodes.
Cheers

 

[Anarchist4000]

I'm implying they didn't spec it to anything. Even a 225W card could use 300W if they really wanted. There's also that Vega 10x2 part that looks a lot more questionable if a single Vega 10 is over 250W. Still an improvement, but that's really pushing limits. If they were listing an accurate spec they would have said 250W or 300W outright. Not <300W.

 

[razor1]

I'm implying they didn't spec it to anything. Even a 225W card could use 300W if they really wanted. There's also that Vega 10x2 part that looks a lot more questionable if a single Vega 10 is over 250W. Still an improvement, but that's really pushing limits. If they were listing an accurate spec they would have said 250W or 300W outright. Not <300W.

They have had dual GPU cards using more than 350 watts before, that weren't even given PCI-e certification.

Just like they stated for P10 which we know what the TDP is now as <150? Why would they do that? They still don't want to show the public the power connectors to Vega, which goes to speak they aren't ready to show how much power it consumes because it would make them look bad or give them bad press.

 

[CSI_PC]

I'm implying they didn't spec it to anything. Even a 225W card could use 300W if they really wanted. There's also that Vega 10x2 part that looks a lot more questionable if a single Vega 10 is over 250W. Still an improvement, but that's really pushing limits. If they were listing an accurate spec they would have said 250W or 300W outright. Not <300W.

If they did not spec it at all they would not even say less than 300W.....
It is a meaningless number according to you and therefore should not had been given as part of the more recent slides, why bother with even 225W estimate back in September if they do not care?
You really cannot see the issue here?
Especially when trying to market the card to HPC.

To put it into perspective, AMD did bother to spec their other Firepro server products with more tangible tdp/tbp; such as the S9170 that is 275W, the S9150 that is 250W and the S9000 that is 225W.
Also in the earlier September slide when they stated 225W for Vega10, they gave 150W-300W for Vega20, showing that by your example they could had said 250-300W if estimating MI25 but they did not and just went with <300 in the later December slide.
It is also worth noting AMD said in the same December slide <175W for the MI8, the 8.2 FP32 TFLOPs Fiji card, exact same spec as the Nano TDP-TBP that is 175W.
Cheers

 

[ChosenUno]

No, they allowed sloppy code to function and devs using their hardware just tested until it "worked". Hence it doesn't run on actual compliant hardware. AMD didn't force devs into anything, it was the devs that got AMD to make the new API because they were tired of the BS.

I'm just gonna say this: As a dev, an API is only as good as its usability. An API should conform to the devs' wants and needs, not the other way around. It's not AMD's fault that devs want something that differs from the OpenGL spec, but when you look at the landscape and how many devs differ from the spec, maybe AMD should've joined Nvidia and asked the Khronos group to change the spec to reflect what the devs are actually using and running.

Versioning is there for a reason, AMD just allowed themselves to fall behind by being too rigid. Now that Nvidia has the huge marketshare, Nvidia's spec might as well be the official spec, since they represent most of the market and most of the customers.

 

[Pieter3dnow]

Odd that more developers joined The Khronos group after Vulkan then before Vulkan, don't think so ....

 

[ChosenUno]

Odd that more developers joined The Khronos group after Vulkan then before Vulkan, don't think so ....

Doesn't that just means that devs were fed up with the OpenGL spec? It makes sense that when a more sensible API is pushed out more people are interested in using it.