Vega Rumors

[Simplyfun]

, it did nothing for them, no marketshare gain, they were in the red at that point too. That was not their goal with the 7970, they wanted to be back at the top end and compete at the top end with that card, they even stated it not once or or twice, many times, and how proudly they did it by saying how large their die size was too.

What they told the press doesn't matter. The card made all the internal sales numbers. It did exactly what they thought it would within a very small percentage. My point was , they knew it would sell regardless of perf/watt, they forecast it and nailed it dead on. Whatever spiel they gave out to the masses doesn't matter a lick.

Again, I'm sorry it disappointed you, it didn't disappoint AMD really. Oh sure, when a company releases a new product they hope it will blow away any sales forecasts they made, every VP prays it does for the sake of their bonuses, but that's just the lottery aspect. Sometimes it hits.

They stated what a whopping success Polaris would be many times too, if you bought that story, I have a bridge to sell you. It seems they scraped up their forecast numbers by dumping silicon on partners that would be just fine for the 580 launch to do this, but they did it.

Don't shoot the messenger. AMD aims low, you aim high.

 

[razor1]

What they told the press doesn't matter. The card made all the internal sales numbers. It did exactly what they thought it would within a very small percentage. My point was , they knew it would sell regardless of perf/watt, they forecast it and nailed it dead on. Whatever spiel they gave out to the masses doesn't matter a lick.

Again, I'm sorry it disappointed you, it didn't disappoint AMD really. Oh sure, when a company releases a new product they hope it will blow away any sales forecasts they made, every VP prays it does for the sake of their bonuses, but that's just the lottery aspect. Sometimes it hits.

They stated what a whopping success Polaris would be many times too, if you bought that story, I have a bridge to sell you. It seems they scraped up their forecast numbers by dumping silicon on partners that would be just fine for the 580 launch to do this, but they did it.

Don't shoot the messenger. AMD aims low, you aim high.

If you think their figures were to stay in the red, I don't know what to think. I doubt that was their plan, I think they wanted to get back to the 4870 days, and make it back into the black with that card.... Doesn't matter how much in the black, just get back into the black, because AMD graphics was holding up the rest of AMD up till that point and thought they could go big and do better.

 

[Simplyfun]

At this point, the only reason I'm even remotely considering Vega (based on current rumor/educated guesses) is because if I did, I'll probably be getting a 40"+ 4K FreeSync monitor (like the LG 43UD79 which we already have a thread on the Displays forum here) to replace my current "budget" 42" 4K@60Hz TV.
At a mere $700, that is much cheaper than a roughly equivalent-sized (give or take 4+ inches) G-Sync monitor.
What I'm curious about is if Vega will be able to match a stock-clocked GTX 1080 Ti (possibly with overclocking? but I doubt it).
Otherwise, I'll just get a nice custom GTX 1080 Ti and call it a day, waiting for Black Friday/wintertime for G-Sync monitor releases and sales.

I honestly think that the price/slection of monitors and the Freesync tech has more to say about final sales than our friend is giving credit for, but I have no numbers to back this. I know my kid loves his Freesync stuff in FPS, so I'm not getting him off AMD anytime soon, but that's life. I mean sure, if you want to see what's coming, it's not all that far away, months doesn't mean much to me and I doubt it will be a total dog. I don't really care if it burns 300 watts to Nvidias 200, makes no difference in a gaming rig as long as it's not noisy as all get out.

 

[Simplyfun]

If you think their figures were to stay in the red, I don't know what to think. I doubt that was their plan, I think they wanted to get back to the 4870 days, and make it back into the black with that card.... Doesn't matter how much in the black, just get back into the black, because AMD graphics was holding up the rest of AMD up till that point and thought they could go big and do better.

Internal sales numbers are put forward and approved, whether the company is in the red or black isn't the goal of a single product. Never is. Graphics will never get AMD in the black, nothing consumer will at this point (imo). Either they make inroads back into server land or they give it up and cede the field to ARM vs Intel. I'd be sad, but business is business.

 

[Bahanime]

Raja never mentioned Tress FX, if it was Tress FX demo, I would be even more weary about the front end changes.

Also I just re watched the Capsacian and Cream presentation, no mention of Tress FX.

Also forgot Tress FX isn't purely compute if I'm not purely mistaken part of it is but the Geometry shaders are still needs.

AMD does not use geometry based hair-effects in TressFX, since they are geometry limited. It's purely Compute-based effects (lots of TressFX doc/presentation out there). NV's hair implementation is geometry based. You can make a game engine entirely out of Compute without even touching the Geometry (graphics) engine at all if you're a capable programmer.

RPM is a specific 2x FP16 use case that can 2x performance for that particular effect. This is entirely different to Primitive Shaders, which is AMD's programmable Geometry, as they bypass traditional fixed function steps.

NV actually had this feature since Fermi, with the PolyMoprh engine, it uses the Cuda Cores to process & cull primitives so it's not limited to fixed function performance.

AMD's been using fixed function geometry for a long time, they improved it with Polaris, again with a fixed function Discard HW. Vega is finally free of fixed function front-end.

When Raja said programmers don't need to do anything special for Vega's new high performance geometry, it's plain obvious that it's driver based. All the "programmable" means is that it's no longer fixed function.

 

[Bahanime]

IMO, Primitive Shaders is just a more advanced function of something AMD already did: http://gpuopen.com/gaming-product/geometryfx/

"improves triangle throughput by filtering out triangles that do not contribute to the final image using a compute based pre-process."

And if we dig further, DICE uses this in Frostbite for Battlefront/BF1 for GCN GPUs. They use compute shaders to cull a lot of invisible triangles to bypass GCN's fixed function geometry limitations.

http://www.frostbite.com/2016/03/optimizing-the-graphics-pipeline-with-compute/

Do read this presentation, really good stuff and it highlights GCN's weakness in low fixed function geometry performance, as well as how to overcome it by using it's Stream Processors to do the work.

I think through their close collaboration, DICE has given AMD their secret sauce to develop it further. Vega's front-end being "programmable" allows for these compute shaders to run on the Stream Processors to assist in primitive culling & processing.

 

[razor1]

AMD does not use geometry based hair-effects in TressFX, since they are geometry limited. It's purely Compute-based effects (lots of TressFX doc/presentation out there). NV's hair implementation is geometry based. You can make a game engine entirely out of Compute without even touching the Geometry (graphics) engine at all if you're a capable programmer.

I am very well aware of that but the current performance is not acceptable.

RPM is a specific 2x FP16 use case that can 2x performance for that particular effect. This is entirely different to Primitive Shaders, which is AMD's programmable Geometry, as they bypass traditional fixed function steps.

NV actually had this feature since Fermi, with the PolyMoprh engine, it uses the Cuda Cores to process & cull primitives so it's not limited to fixed function performance.

AMD's been using fixed function geometry for a long time, they improved it with Polaris, again with a fixed function Discard HW. Vega is finally free of fixed function front-end.

When Raja said programmers don't need to do anything special for Vega's new high performance geometry, it's plain obvious that it's driver based. All the "programmable" means is that it's no longer fixed function.

Yes and the programability will take it from 2 times the throughput increase of polygons to around 3 times ( up to 11 tris per clock), and that will match what Pascal will do in its fixed function set up as it is right now. Yeah that is how much of a polygon thoughput advantage nV has.

 

[razor1]

IMO, Primitive Shaders is just a more advanced function of something AMD already did: http://gpuopen.com/gaming-product/geometryfx/

"improves triangle throughput by filtering out triangles that do not contribute to the final image using a compute based pre-process."

And if we dig further, DICE uses this in Frostbite for Battlefront/BF1 for GCN GPUs. They use compute shaders to cull a lot of invisible triangles to bypass GCN's fixed function geometry limitations.

http://www.frostbite.com/2016/03/optimizing-the-graphics-pipeline-with-compute/

Do read this presentation, really good stuff and it highlights GCN's weakness in low fixed function geometry performance, as well as how to overcome it by using it's Stream Processors to do the work.

I think through their close collaboration, DICE has given AMD their secret sauce to develop it further. Vega's front-end being "programmable" allows for these compute shaders to run on the Stream Processors to assist in primitive culling & processing.

Yes I have read it and do you know that a good deal of that is incorporated into Polaris? (early discard ring a bell?) I'm the one that pointed it out just a few posts ago lol, didn't link it but I said it......

 

[Bahanime]

I am very well aware of that but the current performance is not acceptable.

Yes and the programability will take it from 2 times the throughput increase of polygons to around 4 times, and that will match what Pascal will do in its fixed function set up as it is right now. Yeah that is how much of a polygon thoughput advantage nV has.

NV does not have fix function Geometry Engines, it has been "programmable" ever since Fermi.

https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline

>Within a GPC, the Poly Morph Engine of one of the SMs takes care of fetching the vertex data from the triangle indices (Vertex Fetch).

>After the data has been fetched, warps of 32 threads are scheduled inside the SM and will be working on the vertices.

http://on-demand.gputechconf.com/gt...bisch-pierre-boudier-gpu-driven-rendering.pdf

The reason NV has been so ahead on Geometry is because they stopped using fixed function front-end since 2009's Fermi.

PolyMoprh engine <-> SM/Cuda Core both work together on primitive processing & culling.

Yeah, Vega is catching up for sure, they need to since games have been increasing in geometry complexity. Their fixed pipeline is swamped by high poly models and especially Tessellation.

 

[Bahanime]

Yes I have read it and do you know that a good deal of that is incorporated into Polaris? (early discard ring a bell?) I'm the one that pointed it out just a few posts ago lol, didn't link it but I said it......

Similar theory, but Polaris does it via HW, since they added a special unit for it to handle degenerate vertices even before it gets processed into primitives.

This goes 1 step upstream than regular primitive culling. Vertex culling is when draw calls come in as X,Y,Z, Polaris sees identical X,Y,Z (stores it in its cache to compare to new incoming ones), if its the same location, it discards it from further processing. This is useful for sub pixel primitives which really only occur with Tessellation.

They need both vertex culling as well as primitive culling.

Vega would have a much bigger L2 for these programmable steps & draw stream binning rasterizer. it's something NV did with Maxwell, huge L2 increase for these features.

 

[razor1]

NV does not have fix function Geometry Engines, it has been "programmable" ever since Fermi.

https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline

>Within a GPC, the Poly Morph Engine of one of the SMs takes care of fetching the vertex data from the triangle indices (Vertex Fetch).

>After the data has been fetched, warps of 32 threads are scheduled inside the SM and will be working on the vertices.

http://on-demand.gputechconf.com/gt...bisch-pierre-boudier-gpu-driven-rendering.pdf

The reason NV has been so ahead on Geometry is because they stopped using fixed function front-end since 2009's Fermi.

PolyMoprh engine <-> SM/Cuda Core both work together on primitive processing & culling.

Yeah, Vega is catching up for sure, they need to since games have been increasing in geometry complexity. Their fixed pipeline is swamped by high poly models and especially Tessellation.

Nah are fixed function units, programmers don't have control over what the polymorph engines do. The polymorph engines are dumb they can't be accessed through the API, so if a program calls for a vertex to be made, it will be made regardless. Now nV has more geometry units than AMD and a better function early discard function, that is where the performance is coming from for nV cards when concerning polygon through put.

Polymorph engine doesn't give a programmer access or the pixel shader access to the polymorph engines, there is no bi directional data transfer in nV hardware at that stage.

 

[razor1]

Similar theory, but Polaris does it via HW, since they added a special unit for it to handle degenerate vertices even before it gets processed into primitives.

This goes 1 step upstream than regular primitive culling. Vertex culling is when draw calls come in as X,Y,Z, Polaris sees identical X,Y,Z (stores it in its cache to compare to new incoming ones), if its the same location, it discards it from further processing. This is useful for sub pixel primitives which really only occur with Tessellation.

They need both vertex culling as well as primitive culling.

Vega would have a much bigger L2 for these programmable steps & draw stream binning rasterizer. it's something NV did with Maxwell, huge L2 increase for these features.

They are not the same nor do I have the time to explain its getting late for me.

 

[Bahanime]

Btw, it's also why NV focused so much on Tessellation post Fermi, because they saw AMD's GPU was still on fixed function Geometry, and without an effective culling which the PolyMoprh engine & SM had via it's programmable nature, they went balls to the walls to push Tessellation. Fixed function geometry cannot deal with that much triangles.

 

[razor1]

Btw, it's also why NV focused so much on Tessellation post Fermi, because they saw AMD's GPU was still on fixed function Geometry, and without an effective culling which the PolyMoprh engine & SM had via it's programmable nature, they went balls to the walls to push Tessellation. Fixed function geometry cannot deal with that much triangles.

PM's are not porgrammable with regards to geometry sorry.

same paper you linked to

Polymorph be locked where vertex fetch right? do you see that communicating with the pixel shader?

Just can't do it.

 

[Bahanime]

Nah are fixed function units, programmers don't have control over what the geometry engines do. The polymorph engines are dumb they can't be accessed through the API, so if a program calls for a vertex to be made, it will be made regardless. Now nV has more geometry units than AMD and a better function early discard function, that is where the performance is coming from for nV cards when concerning polygon through put.

Polymorph engine doesn't give a programmer access or the pixel shader access to the geometry units, there is no bi directional data transfer in nV hardware at that stage.

Programmers don't need to do anything, NV's drivers do all of that for them. But they are tapping into the SM & Cuda Cores to do much of their culling & processing. The polymoprh is not a fixed function unit in that sense as it heavily relies on CC to function. The links I posted goes over these in detail. If you didn't read it, then I can see where your misunderstanding comes into it. But these aren't my sources, it's NVIDIA's official presentations.

This is why in the above, I used "programmable" in quotation, to indicate NV hasn't had fixed function geometry engines since Fermi.

 

[razor1]

Programmers don't need to do anything, NV's drivers do all of that for them. But they are tapping into the SM & Cuda Cores to do much of their culling & processing. The polymoprh is not a fixed function unit in that sense as it heavily relies on CC to function. The links I posted goes over these in detail.

This is why in the above, I used "programmable" in quotation, to indicate it's not fixed function.

its not programmable at all! All it does is tells the rest of the pipeline here are the polys, do what you want with them. That's it. The sm working on vertices are vertices that are already made man.

That is not how the primitive shaders work, at least not the way AMD talked about them, it sounds like they are like pixel shaders, where the programmer can tell them exactly what to do and when. And I think they do that by communicating with the pixel shaders (no reason to have different units if it can all be done within one unit a guess but could be wrong, it could be that flexible of a unit as well but that would require more changes and backward compatibility will likely be cumbersome.) Which goes to a more advanced geometry engine.

 

[Bahanime]

https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline

Read through points 1 to 15, how their pipeline works.

At no point is there a fixed function geometry step. It is all distributed to the SMs, then output back to L2/DRAM, then the next step, again, distributed to the SMs.

NV has been using their entire Cuda Cores for Geometry processing since Fermi.

On AMD, 2 Geometry Engines perform the same clock for clock as another GPU with 2 Geometry Engines but more Stream Processors. Likewise, 4 Geo Engines perform similar to each other regardless of the Stream Processor count. That is the difference, it doesn't scale based on Stream Processors. Fury X is very much Tonga in Geometry despite 2x the Stream Processor counts. This by definition is a fixed function unit since it is not leveraging the ALUs to do work.

Vega in theory enables AMD to scale Geometry performance by using it's Stream Processors. Capiche?

 

[razor1]

https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline

Read through points 1 to 15, how their pipeline works.

At no point is there a fixed function geometry step. It is all distributed to the SMs, then output back to L2/DRAM, then the next step, again, distributed to the SMs.

NV has been using their entire Cuda Cores for Geometry processing since Fermi.

On AMD, 2 Geometry Engines perform the same clock for clock as another GPU with 2 Geometry Engines but more Stream Processors. Likewise, 4 Geo Engines perform similar to each other regardless of the Stream Processor count. That is the difference, it doesn't scale based on Stream Processors. Fury X is very much Tonga in Geometry despite 2x the Stream Processor counts.

Vega in theory enables AMD to scale Geometry performance by using it's Stream Processors. Capiche?

You are thinking the polymorph engines are in direct conjunction with the shader units within the sm in a bi directional relationship, they are not, no where is that even mentioned in that document either. BTW point 10 and onward has nothing to do with anything we just talked about, its all about the raster engine. So don't know what you are saying 1 to 15, when you should be saying 1 to 9, and not even that, cause 6 to 9 is the vertex shader.

 

[noko]

Its going to come down to @ what power usage. If its GTX 1080 performance @250 watts, forget it, its done. If its above the gtx 1080 by lets say 10% at 250 better, but still won't look that good. If its at 225 watts, that is doable.

Price, it will be priced at where it should be, just like any AMD products in the past withstanding FuryX and Nano.



Raja never mentioned Tress FX, if it was Tress FX demo, I would be even more weary about the front end changes.

Also I just re watched the Capsacian and Cream presentation, no mention of Tress FX.

Also forgot Tress FX isn't purely compute if I'm not purely mistaken part of it is but the Geometry shaders are still needs.

yes he does say its Tress FX missed the first 10 secs when he stated when I was scrubbing forward. So that really gets me worried about its front end changes man. If they need to use RPM and primitive shader to access RPM (which Raja does mention new programmable geometry pipeline which will be shown later today, which was the RPM demo)

So to recap that demo, uses the programmable geometry pipeline of Vega, which is primitive shaders to give its 2x performance increase in geometry throughput. Which is now looking like not so good cause that is just above the synthetics tests of Polaris vs. Tonga.



Check out 9:25 he talks about RPM and next the new programmable geometry pipeline. They go hand in hand in the demo they show of tress Fx at 22:45

, grandstanding a little?

I know I would be more interested in a Vega if when OC it outperforms a 1080Ti OC even if it took 400w. Especially if similarly priced or cheaper. For a tower desktop, power is very low on my list of concerns. For other type of systems from HTPC, mobile, SFF etc. then yes. Sheer performance/$ rules here for top end gaming card. Each their own maybe.

 

[razor1]

, grandstanding a little?

I know I would be more interested in a Vega if when OC it outperforms a 1080Ti OC even if it took 400w. Especially if similarly priced or cheaper. For a tower desktop power is very low on my list of concerns. For other type of systems from HTPC, mobile, SFF etc. then yes. Sheer performance/$ rules here for top end gaming card. Each their own maybe.

not grand standing, if that was the case Fury X would have sold just as good as the 980ti. Did it? They were equal performance cards man and FuryX could show better 4k game play to boot.

 

[Bahanime]

I don't think it matters how it's done, but the important thing is to get more geometry performance with more ALUs, something AMD GPUs have not been able to do prior as they were fixed function front-end pipelines.

AMD's GeometryFX uses Compute shaders to cull. DICE's implementation is in the same vein, compute shaders to cull triangles.

Does not seem implausible that Raja's claim that Primitive Shaders do not need programmers to do anything special for higher geometry throughput is accurate. Driver implementation for Vega's new features.

 

[Bahanime]

not grand standing, if that was the case Fury X would have sold just as good as the 980ti. Did it? They were equal performance cards man and FuryX could show better 4k game play to boot.

We all know full well that this is bullshit. Fury X flop because 4GB fears and it's shit OC.

A 980Ti has 25% OC potential, a lot of performance on the table and in combination to it's 6GB vram attracted way more users.

Even today, a 980Ti vs 1070 may be comparable, but once OC v OC, the 980Ti pulls ahead. It was just a very good GPU and Fury X did not deserve to be priced the same, should have been $100 or $150 less.

Temps, power, OC, VRAM, all of these things matter and the final is price.

Vega can be between 1080 and 1080Ti, at $499 and it would sell much better than Fury X did.

 

[razor1]

I don't think it matters how it's done, but the important thing is to get more geometry performance with more ALUs, something AMD GPUs have not been able to do prior as they were fixed function front-end pipelines.

AMD's GeometryFX uses Compute shaders to cull. DICE's implementation is in the same vein, compute shaders to cull triangles.

Does not seem implausible that Raja's claim that Primitive Shaders do not need programmers to do anything special for higher geometry throughput is accurate. Driver implementation for Vega's new features.

That's not how AMD was saying things nor was that what Raja explicitly stated.

We all know full well that this is bullshit. Fury X flop because 4GB fears and it's shit OC.

A 980Ti has 25% OC potential, a lot of performance on the table and in combination to it's 6GB vram attracted way more users.

Even today, a 980Ti vs 1070 may be comparable, but once OC v OC, the 980Ti pulls ahead. It was just a very good GPU and Fury X did not deserve to be priced the same, should have been $100 or $150 less.

Temps, power, OC, VRAM, all of these things matter and the final is price.

Vega can be between 1080 and 1080Ti, at $499 and it would sell much better than Fury X did.

And are we expecting great overclocks from Vega?

Watercooled version Raja stated a small increase in clocks, as base/boost, if it had that much overclocking head room, I would expect him to say something like yeah it will, he wouldn't have used a diminutive word in his response. Actaully his response to that might hint at something like very little overclocking head room, and or also overclocking head room with a greatly increased power curve, hence the water cooling. Just like Fury X's water cooling, it was there for a reason, to keep it in a certain power envelope.

Same thing goes for the rx 580, many people though they could get what 100 mhz and more when overclocking, in reality we saw what 50 mhz was the average increase?

I agree Fury X should have been priced lower but 50 bucks would have been enough, Power usage isn't the end all as Noko stated and others have stated but it has some weight at the end as you stated.

 

[noko]

As for Vega new geometry handling, programmable can mean AMD can program it via drivers or firmware or both and may not be API specific or changeable from the API. We just have to see how this cooks.

 

[noko]

That's not how AMD was saying things nor was that what Raja explicitly stated.



And are we expecting great overclocks from Vega?

Watercooled version Raja stated a small increase in clocks, as base/boost, if it had that much overclocking head room, I would expect him to say something like yeah it will, he wouldn't have used a diminutive word in his response.

Same thing goes for the rx 580, many people though they could get what 100 mhz and more when overclocking, in reality we saw what 50 mhz was the average increase?

I agree Fury X should have been priced lower but 50 bucks would have been enough, Power usage isn't the end all as Noko stated and others have stated but it has some weight at the end as you stated.

Who knows? New Arch, new design, new process. It may be clocked close to its max ability like Fiji or not. Perf/$.

 

[razor1]

As for Vega new geometry handling, programmable can mean AMD can program it via drivers or firmware or both and may not be API specific or changeable from the API. We just have to see how this cooks.

with the new API's hard to do shader replacement, well its harder lol. To me its sounds like a new shader, new syntax, new extensions.

 

[razor1]

Who knows? New Arch, new design, new process. It may be clocked close to its max ability like Fiji or not. Perf/$.

we already know what the process does, similar design/arch with tweaks (changes yeah but how big we don't know yet), unless they changed transistor layouts, which they didn't have time for, those 6 extra months man can't account for that drastic of a change. Same team members working on two projects too.

 

[Bahanime]

That's not how AMD was saying things nor was that what Raja explicitly stated.

This was his exact quote and response to a question from a programmer asking whether he had to code special for Vega's features:

"The new geometry pipeline in Vega was designed for higher throughput per clock cycle, through a combination of better load balancing between the engines and new primitive shaders for faster culling. As a programmer you shouldn't need to do anything special to take advantage of these improvements, but you're most likely to see the effects when rendering geometrically complex scenes that can really push the capabilities of the hardware."

Does not leave much room for interpretation. If he said "developers have to code for it".. would be entirely according to your hypothesis. But since he told a programmer that he would not have to do anything special to take advantage of the improvements, it really means it's a default. This could be automatic in Vega's Geometry Engine redesign, or via drivers.

The same applies to the "programmable" Pixel Engine in Vega, and it's draw stream binning steps. Much like Maxwell's rasterizer, no special coding is required by developers.

 

[SolidSnake3035]

I guess it depends on what you(or he) would consider something special. If he had said "shouldn't need to do anything to take advantage" or even "do anything differently" then it would be more explicit. As it is though, you could say that a developer having to code for something isn't "special" at all, because developers code things. In that case, the developer does have to code for it, and his statement isn't dishonest.

You'd have to be a bit strange to answer someone's question like that though, and I don't think that's the case. Though I don't know how good these types of people are at communicating, and I have known particularly intelligent nerdy types to be pretty terrible at it.

 

[lolfail9001]

As a programmer you shouldn't need to do anything special to take advantage of these improvements

So, you should do something after all, don't you get the hint?

but you're most likely to see the effects when rendering geometrically complex scenes that can really push the capabilities of the hardware

And that's basically making it explicit.

 

[Bahanime]

Where I come from, English being the national language, when someone says "You shouldn't need to do anything special to take advantage of these improvements", it means carry on as usual and you'll still get these improvements.

But you're free to interpret as you feel. If it makes you happier with a different interpretation, go for it.

 

[NKD]

Where I come from, English being the national language, when someone says "You shouldn't need to do anything special to take advantage of these improvements", it means carry on as usual and you'll still get these improvements.

But you're free to interpret as you feel. If it makes you happier with a different interpretation, go for it.

Don't waste your time. I read the same but some here won't believe it. Because well its AMD!

 

[funkydmunky]

I'm not going to give any slack to AMD for the amount of times they have outright lied, misconstrued reality, and hoodwinked with pre release info that just doesn't muster up in reality. They did it with ever single product for how long now? Even Ryzen!

Ah come on brother. Give it a rest. If your getting paid, then carry on as usual. If your claiming to be a hardware enthusiast than please drop the butt-hurt and say something rational. Mmmmkay?

 

[CSI_PC]

I'm not sure who would have had a demo to run outside of maybe DICE? Only the console devs have been toying with the concept to my understanding. Like I explained above, all demos we've seen are likely running some sort of basic primitive shader. Every stage prior to pixel shader being baked into one monolithic shader. At least that's how the driver devs were describing it, but I don't have a link to that mailing list discussion handy.

Well if it works without much dev intevention or programming to work, it should be easy to get a demo up and running with minimal work from one of the studios that works heavily with AMD.
It is pretty tricky to forgive AMD this if they also say it needs minimal intervention/dev work and yet cannot provide an actual game demo with/without it enabled just like they have done in the past for Async Compute/HBCC with 2GB/SSG for awhile now even back in prototype and visualisation-rendering pro software/etc.

Anyway from a simplicity perspective, if AMD could game demo it without too much work involved with the Devs/studio they would had, which does not tie into the OP about it being easy to use and so guarantees 2x performance gain.
Although in reality as you appreciate it is not an absolute even if optimised by direct coding and will be highly variable.
Cheers

 

[Bahanime]

Anyway from a simplicity perspective, if AMD could game demo it without too much work involved with the Devs/studio they would had, which does not tie into the OP about it being easy to use and so guarantees 2x performance gain.
Although in reality as you appreciate it is not an absolute even if optimised by direct coding and will be highly variable.
Cheers

Here's the thing, they live demo games, it's the best approach. If they live demo a synthetic, like the RPM TressFX, folks will just say "but who cares, it's a synthetic, baked or canned and all that"...

Computex is up and the launch is imminent. All will be tested by reviewers soon enough.

There is one interesting piece of info about the Primitive Shaders, dont know if you guys heard it, but Scott Wasson (former TechReport) was intereviewed by a youtuber about Vega's features. He got to PS, and was asked whether it would be a benefit for all games, and Scott said most, but then he later said something in the order of, not if they already do compute based culling steps in the engine. I believe he would be referring to the likes of Battlefront and BF1.

This is why I think PS is simply a more flexible compute based culling step, with some change they made in Vega's Geometry Engines to utilize more of the ALUs for this during the setup stages. If some engines already use this feature, then it would be redundant and therefore, driver would be aware and skip it.

 

[razor1]

Here's the thing, they live demo games, it's the best approach. If they live demo a synthetic, like the RPM TressFX, folks will just say "but who cares, it's a synthetic, baked or canned and all that"...

Computex is up and the launch is imminent. All will be tested by reviewers soon enough.

There is one interesting piece of info about the Primitive Shaders, dont know if you guys heard it, but Scott Wasson (former TechReport) was intereviewed by a youtuber about Vega's features. He got to PS, and was asked whether it would be a benefit for all games, and Scott said most, but then he later said something in the order of, not if they already do compute based culling steps in the engine. I believe he would be referring to the likes of Battlefront and BF1.

This is why I think PS is simply a more flexible compute based culling step, with some change they made in Vega's Geometry Engines to utilize more of the ALUs for this during the setup stages. If some engines already use this feature, then it would be redundant and therefore, driver would be aware and skip it.

LOOK do you realize you have no idea of what you are talking about right. First off how the hell does FP 16 calculations increase over 2x the performance of tress fx, you realize tress fx uses adaptive tessellation right? That is not using only compute. That is the first thing RPM changed, but to access tessellation through RPM they need something else there, other API calls to use the new functions.

Don't sit here and try to tell me things that I know a lot about. I know about tessellation and adaptive tessellation since the 486 days cause I programmed then to work on CPU only at the time! And also developed things on Truform when that was all the rage (Unreal engine). And have followed very closely when it was reintroduced with DX10.

 

[razor1]

Don't waste your time. I read the same but some here won't believe it. Because well its AMD!

Ah come on brother. Give it a rest. If your getting paid, then carry on as usual. If your claiming to be a hardware enthusiast than please drop the butt-hurt and say something rational. Mmmmkay?

you guys really should just stay on topic, I just got a 6 card AMD rx 580 rig setup just to see what mining is all about. I'll put up pics when it comes in ok? With a little post it note that says Razor1 says hi ok? And if it turns out good (not too time consuming), I will probably upgrade it to Vega's when Vega comes out. Also get one extra on the side. Sad isn't it, I'm more excited about Vega for mining than anything else.

I don't even give a shit about mining at the moment but I'll do it just to see what its all about. I buy things that are the best for what they are for, not for namesake, not for fanboyism, the people that use that card (pun intended), screw up, don't give a shit, they don't have the capability to talk about anything else, So as I have been doing, and will continue to do just report them. Mmmmmkay?

 

[Bahanime]

First off how the hell does FP 16 calculations increase over 2x the performance of tress fx, you realize tress fx uses adaptive tessellation right? That is not using only compute. That is the first thing RPM changed, but to access tessellation through RPM they need something else there, other API calls to use the new functions

Does not use Tessellation, not even a Geometry Shader at all. Not the recent versions of TressFX anyway.

Geometry based stands is the slow way to generate hair for GCN.

http://gpuopen.com/gaming-product/tressfx/

>TressFX makes use of the processing power of high-performance GPUs to do realistic rendering and utilizes DirectCompute to physically simulate each individual strand of hair.

More details on how it works:

Note early in the presentation (p5 onwards), they discard the use of Geometry Shaders & Tessellation right off the bat. Lots of focus on DirectCompute and Vertices data only, not transformed into geometry.

So maybe you weren't aware of recent versions (up to TressFX 4 or 5 or whatever nowadays).

A pure compute based demo for Vega's RPM, will certainly run faster with 2x FP16.

But you seem to think you know more than AMD, who demo it based on the RPM feature of Vega.

 

[razor1]

Does not use Tessellation, not even a Geometry Shader at all. Not the recent versions of TressFX anyway.

Geometry based stands is the slow way to generate hair for GCN.

http://gpuopen.com/gaming-product/tressfx/

>TressFX makes use of the processing power of high-performance GPUs to do realistic rendering and utilizes DirectCompute to physically simulate each individual strand of hair.

More details on how it works:

Note early in the presentation (p5 onwards), they discard the use of Geometry Shaders & Tessellation right off the bat. Lots of focus on DirectCompute and Vertices data only, not transformed into geometry.

So maybe you weren't aware of recent versions (up to TressFX 4 or 5 or whatever nowadays).

A pure compute based demo for Vega's RPM, will certainly run faster with 2x FP16.

But you seem to think you know more than AMD, who demo it based on the RPM feature of Vega.

It has to use the vertex shader man, that doesn't mean its pure compute lol, it uses the hull shader to create the vertices.

There is no way to access the hull shader without using direct compute.....

Geez, even without adaptive tessellation there and pure tessellation there is no way to access the hull shader without a shader component.

I'm not talking about the GS to do tessellation either, GS only has major issues as seen with DX10 (performance) which is what you are getting at. That is not what I'm talking about.

There was a reason why hairworks didn't use adaptive tessellation, cause without it, it would hurt AMD cards. And with Polaris same situation just at x2 the amounts.

The hull shader is fixed function and needs input from the vertex shader to start

this is the pipeline

Now you tell me what did AMD remove, then Geometry shader which is at the end. It still needs those front end issues solved cause they solved only a portion of it by going to compute instead of the GS. Hull sadaer and Domain shaders are fixed function units man.

Sorry had to step away for a moment.

Ok, now the Hull Shader, Tessellation, Domain Shader, are done, this is where then in AMD goes back to the shader array for Tress FX, by passing, the GS, which is its bottleneck. Why is it a bottleneck for AMD? It only has 2 or 4 GS units depending on gen, cause that is what its limited to. We all know that. For nV they have a GS unit per SM, so the bigger the chip the more GS's they have, A LOT more. While AMD hardware with the traditional DX11 and 12 pipeline would get bottlenecked before nV cards, that is why Fiji, Polaris if pushed too hard on the GS front, gets gtx 960 or lower in synthetic tests. Vega if its got 4 units will have the same problem just with factoring in clock speed with the traditional pipeline.

How do they get around that, primitive shaders. RPM can't get around that by itself, cause it just can't RPM is used in the vertex shader portion of the pipeline, before the fixed function components are involved.

 

[N4CR]

you guys really should just stay on topic, I just got a 6 card AMD rx 580 rig setup just to see what mining is all about. I'll put up pics when it comes in ok? With a little post it note that says Razor1 says hi ok? And if it turns out good (not too time consuming), I will probably upgrade it to Vega's when Vega comes out. Also get one extra on the side. Sad isn't it, I'm more excited about Vega for mining than anything else.

I don't even give a shit about mining at the moment but I'll do it just to see what its all about. I buy things that are the best for what they are for, not for namesake, not for fanboyism, the people that use that card (pun intended), screw up, don't give a shit, they don't have the capability to talk about anything else, So as I have been doing, and will continue to do just report them. Mmmmmkay?

Sorry to hear your account got hacked.

P.s. try undervolting and comparing it to 1060 undervolted and see how you do