AMD Vega Hardware Reviews

Well, it's probably enabled, because Vega seems to be less bandwidth dependent than Fiji, but If I remember correctly, current consensus is, that only "fetch once" is enabled, but "shade once" (culling of invisible pixels) isn't.
In some cases it seems to be just as bandwidth-limited as Fiji (e.g. Battlefield 1 when using equal core clocks, as seen in digitalfoundry's video review).
Another conclusion could be that most of the time Fiji has a lot more bandwidth than it actually needs and/or Vega's color compression is better.
 
It is my understanding that the culling portion isn't available because it relies on the primitives engine being available, which currently it is not.
 
DSBR is already enabled, it was enabled in the marketing slides of Vege in an old driver batch, that driver has been released long time ago. We are already at a new driver batch. As for primitives I suggest we take whatever AMD told about them with a huge sack of salt, if they were even partially the game chnager the evanglists want AMD would have statrted with them before any other feature and released vega with them enabled out of the door. AMD also never once talked about their potential performance uplift, they were happy talking about some RPM 15% projected fps uplift, and even the DSRB limited uplift, but said nill about primitive shaders.
Has that exact set been released to public? Just being newer driver doesn't mean it has everything one older set had. And even then, it could have been limited to those specific scenarios.
 
I wounder how long the specter of "Super Drivers!" will haunt the consciousnesses of hardware enthusiast? Will it become the new "Rampage", when for several years/generations, long after the demise of 3dfx people where sill chiming in about it being faster than the Nvidia/ATI producst being released.

Mid 2019: "Sure, this GTX 3080 GTX is a good improvement over the high-end TI variant of Volta that was releases late last year... but will it be able to contend with Vega 64 once the Drivers foretold in Vidcartasus 1.6-9 are upon us?"
 
DSBR is already enabled, it was enabled in the marketing slides of Vege in an old driver batch, that driver has been released long time ago. We are already at a new driver batch.
Define "a long time ago".
Because the only trustworthy knowledge we have about this is this post in this very same thread:

Quick note on primitive shaders from my end: I had a chat with AMD PR a bit ago to clear up the earlier confusion. Primitive shaders are definitely, absolutely, 100% not enabled in any current public drivers.

The manual developer API is not ready, and the automatic feature to have the driver invoke them on its own is not enabled.


It is my understanding that the culling portion isn't available because it relies on the primitives engine being available, which currently it is not.
This is my understanding as well.

Polaris had a (seemingly fixed function) Primitive Discard Accelerator which got it a substantial boost in geometry intensive scenarios when compared to Fiji. Vega seems to be behaving just like Fiji clock-for-clock in geometry performance. AFAIK, it's because the primitive shaders should be handling that functionality, and they're not.
 
AFAIK, it's because the primitive shaders should be handling that functionality, and they're not.
Coming up on three months after vega's launch (and 9 months after vega was first previewed), any thoughts on why there are still features not enabled - is it the ever-looming spectre of broken hardware, or something else?

Is the relative scarcity of this product perhaps a result of waiting on getting bugfixed silicon back from the fabs? :p (Wild speculation is fun, isn't it?)
 
Coming up on three months after vega's launch (and 9 months after vega was first previewed), any thoughts on why there are still features not enabled - is it the ever-looming spectre of broken hardware, or something else?

Is the relative scarcity of this product perhaps a result of waiting on getting bugfixed silicon back from the fabs? :p (Wild speculation is fun, isn't it?)

It would be at the very least extremely unwise—and possibly actionable—to advertise features known to be broken in hardware, so I assume it's just that there's a lot of development work to do, and perhaps not quite enough manpower to do it in a sufficiently timely manner.
 
DSBR is already enabled, it was enabled in the marketing slides of Vege in an old driver batch, that driver has been released long time ago.
AMD stated the feature is not enabled in current gaming drivers as linked above. Review sites have said it's not enabled. Testing indicates it isn't enabled. Yet somehow you reached a conclusion that it is enabled?

As for primitives I suggest we take whatever AMD told about them with a huge sack of salt, if they were even partially the game chnager the evanglists want AMD would have statrted with them before any other feature and released vega with them enabled out of the door.
I guess we'll have to live with the GDC and SIGGRAPH presentations from developers, AMD fellows, and simple math for the time being. There hasn't been much evangelizing here, just this is what the feature does and these are the results when tested. It's a relative simple feature with well understood capabilities. Exposing a new API and shader pipeline for graphics APIs will take time. Improving geometry in high margin compute focused markets that don't use geometry would be a lower priority. Even if the feature currently worked gamers would have a difficult time finding cards due to mining.

Well, it's probably enabled, because Vega seems to be less bandwidth dependent than Fiji, but If I remember correctly, current consensus is, that only "fetch once" is enabled, but "shade once" (culling of invisible pixels) isn't.
Doubling L2 and some other caches will do that. Simply making a texture cache larger will yield some reduction. I linked some Linux commits a week or so ago with devs reworking primitive submission to SEs, so there is work being done towards further culling. Little reason to touch that code otherwise.

Coming up on three months after vega's launch (and 9 months after vega was first previewed), any thoughts on why there are still features not enabled - is it the ever-looming spectre of broken hardware, or something else?
Going off the LLVM documentation, all cards are adopting a new memory model and what seems a new driver stack built on top of it. LLVM features, in the case of disabled FP16 at least, match consumer Window's drivers. End goal likely to compile C code. There have been some rumblings about moving from current shading languages and models due to limitations. That could explain what we're seeing here, with a push towards future models that aren't available with current ones being deprecated. That memory model change makes since in the context of HBCC and bindless models used in LLAPIs. Just how AMD is prioritizing work with available resources.
 
DSBR is partially enabled, as AMD did confirm in our discussions with them. It's just not generally enabled with a driver automatism, which makes it work everywhere and everytime.
https://translate.google.com/transl...n-Antworten-Vega-56-10-1235968/#a2&edit-text=
(google translate makes some sentences look quite strange, please do not judge grammar based upon this - german is said to be pretty hard to get right. ;))
 
Because designing GPUs this big is f'ing hard.
Point, however, if you yourself designed the hardware feature, why is it so hard slash time-consuming to write the software controlling it? Reasonably you ought to know what it is you designed, how it works and what is needed to drive it.
 
Point, however, if you yourself designed the hardware feature, why is it so hard slash time-consuming to write the software controlling it? Reasonably you ought to know what it is you designed, how it works and what is needed to drive it.
Writing the software relatively easy. Standardizing an API for integration with graphics APIs across vendors a bit more problematic. Intel and Nvidia should be able to do something similar, so just a matter of "quickly" pushing it through a committee.
 
Point, however, if you yourself designed the hardware feature, why is it so hard slash time-consuming to write the software controlling it? Reasonably you ought to know what it is you designed, how it works and what is needed to drive it.

Jen-Hsun Huang has, on multiple occasions I believe, described NVIDIA as a software company. That's his way of emphasizing that for every man-hour of hardware development, many man-hours of software development are required to support it. People with more direct experience of this could certainly make that point far better than I, and with supporting examples to boot.
 
DSBR is partially enabled, as AMD did confirm in our discussions with them. It's just not generally enabled with a driver automatism, which makes it work everywhere and everytime.
https://translate.google.com/transl...n-Antworten-Vega-56-10-1235968/#a2&edit-text=
Once again, this further proves how limited DSRB is, with 30 % memory savings only 10% higher fps was achieved, which is a best case scenario here, the driver dont really need to have it active for all applications, as most of them will not benefit from it anyway. as mentioned here before only turly bandwidth starved chips will have a tangible benefits from DSRB. Primitive Shaders also have a selective nature attached to them, they will be active only when AMD deems them useful or benefecial just like DSRB .

It's also amazing how a lot of old standards have been omitted by a lot of people in this launch, 1-suddenly MSAA performance is not important (guess what? it's still used extensively in current games like Forza 7), 2-running games on maximum settings are not important (a simple RX 580 can giveme 150fps on medium settings thank you very much dont need high end stuff anymore right?), 3-tangible out of the box improvements are not important (now manufacturers will resort to the ridiculous tactic of giving false hopes to potential buyers with the concept of magical drivers down the road!). Supporting company x is one thing, forgiving shortfalls and quirks is another.
 
Back
Top