One is measured in bytes. As bins cover less screen space or triangles become larger, the context data increases as the geometry will more frequently intercept multiple bins.
The existing disclosures state this is building a batch of primitives before evaluating bins.
The pipeline accumulates primitives into a batch, and stores references to what bins each primitive intercepts.
The batch's context (or estimated context size) grows with each primitive, but the bins are evaluated at a later stage with a more firm limit on their impact since the process works through bins in a sequential fashion.
A large primitive could intercept every bin and require storing a reference in each. If a bin holds 16 primitives, there exists a case where 256 bins could only store 16 total primitives.
The size of the batch is a variable number of primitives, which have references to what bins they intercept. This may be a set or range of bins, or an initial bin intercept with the understanding that further bin intercepts will be calculated as that bin is processed (being processed sequentially helps with this).
If a condition is met where the pipeline determines further batch growth will cause something to exceed on-chip storage, it would close the batch. AMD has not exhaustively listed context types that could trigger this condition.
The bin size appears to be primarily concerned with whether the worst-case amount of pixel context being tracked can overflow on-chip storage, which is built into the sample count and format of the target buffer(s). That determination is based on the number of pixels as determined by the screen-space dimensions of the bin, rather than the primitive count that is more of a concern for the prior batch generation step. With occlusion, there could be more batched primitives being processed for a bin than there are pixels in the 2D area of the bin.
If you look at that commit the bins are following the stencils.
Which commit, and which portion?
Small screen space bins should only be desirable when there is a high chance of occlusion, which implies edges.
There are various parameters that need to be balanced against, such as the granularity of the hardware paths that can most quickly cull primitives, or what parts of the pipeline cannot be subdivided without utilization concerns. Having many smaller bins also raises the cost of formerly trivial conservative checks. If a larger occluding triangle covers multiple bins fully, what would have been a small number of trivial checks scales with the number of additional bins the original set was subdivided into, and increases the encoding size for bin identifiers. If handling even smaller triangles, it also increases the chance of a bin having very few actionable primitives (scan converter works on unchanging pixel/sample point scale) whereas increasing complexity in bin evaluation raises the cost of selecting or using each bin and slows their submission to the back end.
Looking across a barren terrain for example, a third or more of screen space could be empty. The bins would be largely wasted.
If truly empty of geometry, no primitives in any batches would reference those bins, and they would not be stepped through by the DSBR. Even in the absence of a DSBR, what does a vast swath of screen space without geometry that the front end wouldn't be evaluating and no shaders would be invoked for cost?
That's not what I'm saying, however multi-sampling could be viewed that way. I'm suggesting recursively binning into multiple levels alongside a depth/stencil mip tree. Repeatedly testing coverage, essentially scanning out, a primitive at each level of the tree to test occlusion. That's why I said pixels and bin intercepts are synonymous. Only difference is resolution in this case.
To be clear, this is adding an uncertain number of iterations on a per-triangle basis for every triangle covering one or more bins, and cross-referencing the subdivisions arrived at by prior triangles or ignoring them and then merging checks afterwards, repeatedly accessing or calculating coverage and depth, coupled with a tree traversal of unspecified time complexity and memory access behavior.
This is between vertex/primitive shader export and wavefront launch, where there are 4 points chip-wide that can go through this.
On top of that, this looks to setting up values as part of a hardware context change. The number of those is limited and exceeding the chip's support of them is globally expensive. Changing at the granularity of individual primitives does seem expensive.
Consider the following for Early Fragment Test:
This states the overall API-level decision that permits a GPU to suppress fragment shader invocation if the fragment does not affect final rendering, which the DSBR tries to accomplish more frequently. What does this alter in a debate concerning work and culling done prior to fragment shader launch, which I would have assumed has this as a given?
This is what I'm arguing the instruction is accelerating. Accelerating the binning process alongside a stencil mip tree.
What does this instruction provide that provides more context related to what bins a triangle covers?
It takes a conservative bounding box composed of 2 bits each from the x_min,y_min and x_max,y_max values of the bounding box, and the output is a 4-bit mask for coverage. The bounding box's dimensions are in pixels measured in terms of overall screen space. Anything that covers 4 or more tiles has the same output.
What is this process doing with the various mask outcomes? If all SEs are covered, further iteration creates more bins that might be covered. If not all bits are set, further subdivision in effect creates more bins that do not have coverage but put work into a primitive anyway, and more bins that might have coverage and will be performing work anyway. At some point, the system needs to move on and submit something.
Whether the tile size can vary beyond what is documented in the ISA isn't clear, but the granularity isn't inconsistent with the bin sizes offered in the Raven Ridge binning patch, although it is conservative in the narrowest bin case. This may indicate a difference in the "tile" AMD's white paper calls a bin, versus the tile related to the SE backends mentioned by the instruction. This may in the final account change what level of concurrency there is in this part of the process, and in conjunction with the values in the binning patch may mean we've seen most if not all of the options that are available.
Definition of rasterization or scan out? They are both sampling onto an ordered grid, just with different resolution.
A bin is a region of screen space that is many times larger and can vary against the overall subdivided screen space, whereas a pixel is a fixed component of both. Saying they occur at different resolutions when one is literally made of the other seems like a problem in treating them interchangeably. The rules concerning what is allowed to be conservative and inaccurate in spatial terms are also reserved for the bin.
What the scan converter's output actually creates for wave launch and active lanes is also not 1:1 to either. Neither actually perform actions, as much as they are a measure of the alignment and allocations for the elements that perform the actual actions and checks.
The problem is when and what data is being fetched. Deferred attribute interpolation for example would be part of that.
In the description of a visibility buffer type deferred attribute interpolation, the fragment shader would have a primitive ID that would look back into a buffer. That method would be after the DSBR, although the fully deferred DSBR mode behaves like a localized visibility buffer.
For the purposes of outlining a specific feature of the DSBR and not in conjunction with a hypothetical use of the optional primitive shader, I think AMD was not discussing that particular technique. The shader-based methods involve writing to a buffer that the DSBR would not be aware of, at any rate.
How fetch-once is accomplished is not clear, perhaps by storing the necessary geometry stage outputs into dedicated storage or careful management and back-pressure from the DSBR or pixel shader wavefront creation stage.
Being that it is likely more efficient to assemble, transform and cull with FP16 on Vega, fetch once is a bit disingenuous. Data is only fetched once, but for the most part not passed along throughout the pipeline anyways.
This is saying one thing and then immediately stating the other. Primitive-side data being fetched once seems like it can be honestly described as "fetch-once", it's not fetch-once-and-resolve-all-future-concerns. So long as data needs from vertex export through pixel shader invocation for a triangle are kept on-chip, it seems like a fair descriptor.
