AMD Vega 10, Vega 11, Vega 12 and Vega 20 Rumors and Discussion

The "Fiji fallback driver" or "Fiji drivers" meme needs to stop. That's not how it works or should be described. Otherwise you should start calling Volta drivers Pascal drivers Maxwell drivers. There is obviously commonality -- that's just how software engineering needs to work for a GPU -- but calling it a Fiji driver or Fiji fallback is wrong.

How else can Vega's current uncanny similarity to Fiji's performance-per-clock be called despite having 40%/4.2B transistors more, then?

As much as the term "Fiji fallback" feels wrong to people on the inside, it sure looks like every single architectural difference that would make Vega 10 work faster than Fiji clock-for-clock is simply not working in games.
 
Going by that gamer nexus analysis it seems like the card pcb is seriously over built, I only hope the actual 3d performance of it will improve dramatically with new drivers.
 
The "Fiji fallback driver" or "Fiji drivers" meme needs to stop. That's not how it works or should be described. Otherwise you should start calling Volta drivers Pascal drivers Maxwell drivers. There is obviously commonality -- that's just how software engineering needs to work for a GPU -- but calling it a Fiji driver or Fiji fallback is wrong.

It's AMD's fault for throwing the term out there back in January or so. If you want people to be more technically accurate, then don't do that! ;)

That said, can we hope for some kind of substantial increase in performance with the RX driver? Besides draw stream rasterizer are any other architectural features disabled for the sake of stability? Will the new rasterizer (and/or other features if applicable) be enabled in time for the RX launch?
 
There is a fair amount of begging the question (in the classical sense, even) in those queries.
Outside observers are stating the rasterizer is disabled.
Saying it is disabled for the purposes of stability is asserting something beyond that.
Saying any other features are disabled because of stability is asserting beyond even that.

Also, I'm not entirely sure he's in a position to comment at this juncture...
 
The "Fiji fallback driver" or "Fiji drivers" meme needs to stop. That's not how it works or should be described. Otherwise you should start calling Volta drivers Pascal drivers Maxwell drivers. There is obviously commonality -- that's just how software engineering needs to work for a GPU -- but calling it a Fiji driver or Fiji fallback is wrong.

smh. you can't just say that and not add anything. people probably weren't literally thinking fiji fallback drivers but a driver closer to previous relive than what will launch with rx vega, so even that doesn't help.

At least tell us something. for example, how old is the driver?

That would be wrong too, AMD already told PCPer they include all the gaming optimizations of the RX driver in the Vega FE driver.

actually, based on what he said, this is not what he was told. He simply interpreted it as close to that. He was told that the driver had optimizations up till it was forked off to be readied for launch. that could be days or months before launch. He assumed that was recently.
 
Yeah, I am sure the way this thread is turning will greatly encourage future participation from IHV personnel in general and Rys inparticular.
 
The fiji drivers thing apparently originated in december and with AMD themselves calling it something similar. Modified Fiji drivers or some such. Guessing some folks there weren't happy with that terminology then

Thats alot to ask of somebody who most likely is under NDA or some employment agreement with regards to releasing information.

couldnt he restate what raja has already said? even "wait for rx vega launch for real performance" would be a lot

Yeah, I am sure the way this thread is turning will greatly encourage future participation from IHV personnel in general and Rys inparticular.

I doubt they are going to get emotional over regular conversation. weird you would think they would. "If you can't answer, don't answer" is likely how they already do things.
 
Last edited:
you can't just say that and not add anything.
This is what really bothered me about what you said, yes he can. He has no obligation to say anything and again most likely isn't supposed to reveal anything. Your post almost comes off as a demand, and thats not right.
couldnt he restate what raja has already said? even "wait for rx vega launch for real performance" would be a lot
And would you have been satisfied with that?
 
Yeah, I am sure the way this thread is turning will greatly encourage future participation from IHV personnel in general and Rys inparticular.

It's obviously not Rys's fault in any way but by now AMD has the collective experience to write a few books on how to get bad publicity. The company's communication around this launch leaves a great deal to be desired in my opinion.
 
There is a fair amount of begging the question (in the classical sense, even) in those queries.
Outside observers are stating the rasterizer is disabled.
Saying it is disabled for the purposes of stability is asserting something beyond that.
Saying any other features are disabled because of stability is asserting beyond even that.

  1. Since the tests showing rasterization behaves like all previous GCN architectures were live streamed, it's a fairly reasonable assumption.
  2. Also a reasonable assumption. Purposefully holding back would be insane, and there's close to zero chance that the driver team is so far behind that the code for the new rasterizer is totally non-functional. That leaves stability as the most likely candidate. Another one is that the new rasterization branch breaks so many existing optimisations that a fallback is currently more performant. Whichever the case, it doesn't change much of anything so the possible distinction isn't exactly relevant.
  3. A straw man. Nowhere did I assert that other architectural features were disabled.
 
How else can Vega's current uncanny similarity to Fiji's performance-per-clock be called despite having 40%/4.2B transistors more, then?
Personally I like Vega running a Fiji VM.

I'm not sure why the idea of falling back to Fiji paths is a bad thing. It seems an apt baseline, however that Phoronix article mentioned basing around R600.
 
In GN's testing, it appears that Vega FE is having better geometry and tessellation performance than FuryX at the same clock, at least in FireStrike GFX 1 test (which is geometry heavy).

vega-v-furyx-firestrike-normal_fps.png
Would be interesting to see, how it compares to Polaris.
 
  1. Since the tests showing rasterization behaves like all previous GCN architectures were live streamed, it's a fairly reasonable assumption.
  2. Also a reasonable assumption. Purposefully holding back would be insane, and there's close to zero chance that the driver team is so far behind that the code for the new rasterizer is totally non-functional. That leaves stability as the most likely candidate. Another one is that the new rasterization branch breaks so many existing optimisations that a fallback is currently more performant. Whichever the case, it doesn't change much of anything so the possible distinction isn't exactly relevant.
  3. A straw man. Nowhere did I assert that other architectural features were disabled.

1. Seems to be the most readily supported by the data available, but I did glean from the PC Perspective video that the reviewer didn't really know what to do with the test besides pick a few arbitrary slider positions given by the chat. Whether that mattered isn't clear, but the testing wasn't thorough. It's also not exhaustive, and since there are applications that were improved with Vega, it may not be universally true.
2. What about correctness? Things can look wrong without crashing the software, or possibly act in some non-compliant manner like not crashing when they probably should.
3. I took the second half of the rasterizer statement to be a logical continuation of the first, although I see now it can be interpreted more freely than the first half.
 
1. Seems to be the most readily supported by the data available, but I did glean from the PC Perspective video that the reviewer didn't really know what to do with the test besides pick a few arbitrary slider positions given by the chat. Whether that mattered isn't clear, but the testing wasn't thorough. It's also not exhaustive, and since there are applications that were improved with Vega, it may not be universally true.
2. What about correctness? Things can look wrong without crashing the software, or possibly act in some non-compliant manner like not crashing when they probably should.
3. I took the second half of the rasterizer statement to be a logical continuation of the first, although I see now it can be interpreted more freely than the first half.

1. I don't see the chances as being too high, but I can definitely get on board with the call for more thorough testing.
2. I imagine that scenario is basically the same as lack of optimisation, since the problem isn't likely to be so much as making things look correct, but looking correct while being performant.
3. Thank you. Yeah, I didn't mean to imply that more things are necessarily disabled, but I am curious if they are or not. That's another reason I'd like to see more thorough testing. Has anyone tried tessmark (or something similar) yet? How about packed math?
 
The "Fiji fallback driver" or "Fiji drivers" meme needs to stop. That's not how it works or should be described. Otherwise you should start calling Volta drivers Pascal drivers Maxwell drivers. There is obviously commonality -- that's just how software engineering needs to work for a GPU -- but calling it a Fiji driver or Fiji fallback is wrong.

I think most people know that. The intended takeaway is that this is the only level of optimization the driver has and that it is treating Vega, to the extent possible, as if it were just Fiji.

The apparent lack of tiled rasterization, performance, and efficiency - coupled with the driver declaring itself as 17.1.1 - certainly lead to that conclusion.
 
How else can Vega's current uncanny similarity to Fiji's performance-per-clock be called despite having 40%/4.2B transistors more, then?

As much as the term "Fiji fallback" feels wrong to people on the inside, it sure looks like every single architectural difference that would make Vega 10 work faster than Fiji clock-for-clock is simply not working in games.
Which of the architectural changes should show up it's nose under current testing though? HBCC on a 16GB card? FP16 needs game support. IHVs cant just show it down the games throat (well... :LOL:). Primitive shader (what ever it is) is again something that's not in DX description and is presumably something that will have to be explicitly coded for somehow. Are there geometry throughput improvements outside of primitive shader that we know about? Same with upgraded FL_12_1 features they need game support to show up.
The wildcard is the draw stream binning rasterizer. But I find it very strange that people are expecting it to show up and behave exactly the same as the NV approach does. And how long was Maxwell out anyway until general public caught up on that one? :smile:
 
The main advantage of TBDR is saving memory bandwidth (hence power too) but it can actually lead to worse performance due to extra overhead of binning and re-ordering of unseen fragments. This is especially true for applications heavy in geometry and if they already do a Z-prepass step in their engine then the benefit goes away. On Maxwell/Pascal, the driver fallsback to Immediate Rendering if a game isn't getting much benefit from TBDR mode. Now AMD should theoretically have a better implementation than NV here as they've designed all this from scratch but then again this is a brand new arch and anything can go wrong. People are expecting huge gains from TBDR but it's not a magic pill which makes everything run faster.
 
Back
Top