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

For shaders that modify depth doesn't that affect early-Z not Hi-Z? Although I don't really know if Hi-Z is used for the late(normal) depth test.

Also has there been any documentation in regards to DSBR that have stated whether binning and rasterization occur in a pipelined fashion or non-overlapping? I'm asking because I wondering about contention for the Hi-Z data if it is used in the binning stage.

 

reading this conversation about Vega "broken" hardware reminds me S3 Savage 2000 T&L decelerator failure... a highly controversial GPU that was developed under the lead of a certain Raja K...
Looks like history runs in circles

 

Oh my God, I remember that catastrophe vividly. Damn, why ain't Raj somewhere flipping burgers?

Sent from my SM-G950U using Tapatalk

 

The S3 was that a logical failure or a production failure?

It will be nice to know if Primitive Shaders are broken in hardware or logically or in software.

 

Well, haha, if you ask if there's official confirmation that a piece of hardware isn't working right, and someone replies, "yes, here is a quote from a reputable website editor, which says nothing about the hardware working right or not", would you consider the question answered?

No disrespect to Anandtech's editors, but they're not AMD spokespeople. (Would be worrysome if that was the case! ) Also, the quote did not actually confirm the hardware isn't working as intended. It just said it's not working right now. So its status is up in the air. And again to reiterate, I asked if there was official confirmation that it wasn't working right.

No need to get snippy! I was just asking if you had an official quote, answering "no" would have been sufficient.

That's not logic though, that's a lingual song and a dance. If you state that a product isn't working as intended, and just leave it like that, the obvious implication is that it IS broken, because that's how english works.

If you just mean that a feature isn't implemented right now, then you merely say so.

I don't see how it would be his fault. It's company leadership who have to authorize a respin, and they in all probability said, "fuck it, we'll ship it as it is, we're not spending any more money." (Or other words to the same effect. )

One could perhaps blame Raja for him and his team designing a broken T&L unit in the first place, but that would place an impossible standard on the man. If you're not allowed to screw up ever, then nobody is qualified for any leadership position in hardware design.

 

I doubt it terminates the use, just skips certain tests or steps. A shader modifying depth obviously can't be occluded until depth is known. Transparent geometry can, but can't quite overwrite depths. PixelSync/OIT for example technically has a depth that would work for occlusion. Just need x samples or a certain weight of opaqueness to figure it out. So a pixel shader could yield a valid depth despite being transparent.

As for contention of resources, it's the writes and locking that would be an issue. Simple way around that is to only update depths when a bin fills and re-evaluate.

 

I'm not sure how current implementations handle it, but there were references in older architectures from ATI that indicated both were disabled if modifying depth--at least within the current pass. For the purposes of matching what the deferred mode for the DSBR, it would be covering any early checks that block unneeded pixel shading.

I'm making a distinction between a number of broadly-described embodiments in patents related to AMD's hybrid binning rasterizer versus the specific implementation marketed as Vega's DSBR, since AMD has not given that much detail on the DSBR and there can be significant variations on the theme.

The batching process was described as being potentially double-buffered, so that a new batch could be in progress while a finalized one starts to launch pixel wavefronts.
Once a batch has been finalized, the DSBR steps through bins sequentially in some chosen marching order. Within each bin, there's a processing sequence for the primitives that could include calculating the what primitives will be handled when the rasterizer moves on to the next bin. Since the list of intercepts for the next bin starts getting built while the current bin is being processed, there could be some element of pipelining involved.
Since the bins are partitions of screen space, at least from a tiling standpoint what the current bin is doing shouldn't interfere. What the actual hardware supports in terms of data paths or units is not clear, although if the DSBR maintains a separate local buffer of coverage for the current bin it might be able absorb more of the checks locally and allow more run-ahead culling for the next bin(s).

Part of the question is where in the process such querying could be placed, and what level of complexity and additional hardware AMD has added. Using the same data paths could be affected by many cycles the front end takes up versus export cycles used by the CUs. In that case, a big GPU with fully-populated shader engines might have more time taken up with actual exports versus a more modest APU GPU with 11 or fewer contending for the data.
One idea I had for a more streamlined DSBR would be one that might re-use existing buffers in its deferred mode. Since the bin processing monopolizes a region's resources and sizes bins so that they don't thrash, the DSBR might perform a bit of sleight of hand similar to how the primitive shader separates position-based calculations from the rest of the vertex work.
It could build up a list of primitives and run through depth export portion of the work per triangle ID, then read back the final accumulated results at pixel shader launch. The PS4 Pro's ID buffer seems to be writing out this data in parallel to the rest of its work, so this might be leveraging existing paths internally.

 

Well, wasnt he also lead for R300?.

 

No, it's not impossible. I work in product development for a living, and it's part of the production plan to have validation and qualification steps in place to detect catastrophes.

Ask yourself this: An engineer was the team lead on the Intel Pentium processor with the floating point bug, then they headed up the horrible NetBurst architecture, and finally was the visionary that created the horrible X299 platform. The only question you can have is why in the hell are they still employed?

You wonder how a high level executive was able to jump ship to an arch rival and get around non-compete clauses? It's because AMD thought this would be a competitive advantage to have Raj fuck up the serious graphics kick-off. It gives AMD at least three years head start.

Sent from my SM-G950U using Tapatalk

 

The FDIV scenario one may be an indication he knew how to distribute blame organizationally, although anecdotes concerning how that bug came about indicated that the go-ahead for removing parts of the lookup table came after formal proofs "verified" there would be no problem. While this likely led to the institution of more rigorous validation and a correction in whatever was missed in the original mistake, it was an error in an otherwise very successful complex engineering project.
For the Netburst architecture fiasco, which one? Williamette, which was a rough first implementation that had to go through a die diet? The very successful Northwood that knocked AMD and the K7 back until K8, or the Prescott architecture that got slammed by the abrupt end of power scaling that almost the entire industry got hit by? Nonetheless, it was a profoundly complex high-speed OoO x86 engine that also included the introduction of SMT and some of the best branch prediction there was at the time and for a while after.
There's a reason why may leading CPU architectural teams can trace their roots back to other leading CPU architectural teams, the technical leads remotely qualified to even fail at that level are extremely rare. I would love the opportunity to produce a not-so-good VLSI CPU that only managed to be among the best CPUs ever designed at the time that made billions of dollars in revenue.

Well, for one thing that occurred in an industry where such moves happen a lot, and a state that mostly negates such clauses.
Even being able to work at that level imperfectly is a very rare skillset, and AMD does not benefit if Koduri is able to "fail" his way to second-best versus Nvidia. We won't know if he's up to the task until some point in the future, and even flawed results could get Intel closer given it's something of a reset organizationally.
Before, AMD felt he had enough upside to give quite a bit to bring him in and keep him out of Intel.
Scenarios like his upside not being enough, or asking price being too high don't translate to his return being negative, particularly if the dispute came down to a resourcing trade-off Intel could make that AMD simply couldn't meet.

 

That's what I did for the last couple of posts. Apparently, my foreign language skills are insufficient for an endeadvour like that.

 

Better would have been to write "primitive shaders are proven to be disabled, I'm speculating that is due to x". We have no confirmation why primitive shaders are disabled. Reason for disabling could be broken design, broken hw, software not being ready, resources been moved to next project etc.

 

I have never commented on WHY they might be not enabled, only that they AREN'T. And that was decidedly on purpose, since I don't know why that might be the case. Maybe it's not a problem with what I write.

 

Disabled and not working don't have same meaning in English language.

 

"Not working" in german means "too lazy to bother". LOL
But serious "not working" is the absence of working, not the opposite. "Disabled" is still in the set of possiblities of which "working" isn't part of anymore. It's might not be common use of language, but's logically correct.

 

its all open to interpretation,

disabled could be broken or just turned off.
broken could just be software/firmware or it could be hardware.

either way both phrases could mean completed F***ed or its still a work in progress.

 

Not working is worse than disabled. You could disable fire alarm by removing battery or disable piece of code by using a macro. Disable can have positive meaning in SW context where something could be disabled to save space or speedup compilation.

Not working on the other hand means something is broken and needs to be fixed. There is no switch to flip or battery to insert.

Officially we know primitive shaders are disabled. Claiming they are broken is probably good guess but we have no confirmation on that. I don't think we even have any signals to know if disabling is done due to hw or sw. Though good guess would be a combination of tricky/broken hw, non triviality of software in question and likely also testing effort needed per title to tune/fix shaders.

There is a point where amd must start to focus on next chip assuming they don't have unlimited resources. Depending how next hw looks like investing to primitive shaders can be great or not valuable at all.

 

Well, no one has unlimited resources, and we also know that AMD is probably resource constrained.

So how many think that AMD will offer discounts to current Vega owners (on Vega Refresh/Navi) if its true current Vega is truly broken just to keep some loyalty? I know for certain, my loyalty is starting to run thin, and I haven't even forked over for a Vega yet...

Sent from my SM-G950U using Tapatalk

 

"Working" is equivalent to "running" in german, not to "functioning". That's why I made the lazyness joke.
A fire-alarm not working, means it makes no sound, not that it's not functioning when pressed.
I'm sure "not working" got it's life on it's own in english, because it's clearly not used by it's literal meaning, but it is in german. An atomic power plant not working means it's turned off, not that's it's broken.
Anyway, it's a sensible difference in language use, isn't really important.