Can we actually describe everything with positive capabilities and a few set constraints?

[gfxstrand]

Capbailities

My initial vision for memory allocation was to have independent blocks of capabilities where each block was fairly self-contained but could have complex interactions within it. This has the down-side that the driver has to be involved in the intersection process. The directions that @cubanismo was pushing was to have everything as small atomic capabilities. While this is less expressive, it's much simpler to perform an intersection operation. We need to double-check that everything needed is expressible this way.

Tentatively, we have said that the capabilities will be relative to the surface allocation parameters: width, weight, format, sample count, mip levels, array slices, etc. In other words, you don't have to worry about expressing every possible set of capabilities which could grow very large.

List of common capabilities (update as more common capabilities are found):

• linear (pretty much needed for cross-vendor sharing)

Constraints:

Constraints are a bit special because it will take more care to union them properly. We've determined that these constraints will have to be understood by the allocation library (and therefore common) so that they can be combined properly.

List of common constraints (update if more constraints are needed):

• Max pitch
• Min pitch alignment
• Start address alignment
• Max width/height (Maybe handled by the app?)
• dma mask/address range
• YUV multiplanar - planar, where U and V need to be positive offsets from Y < 64MB
• Need to have U and V in separate RAM banks.

[gfxstrand]

I'm going to attempt to list a set of atomic capabilities for us to use on Intel that describe everything we care about. Not all of them will apply to all image formats or dimensions. @chadversary, please check me on this:

• X-tiled
• Y-tiled
• Fast-clears (must be combined with Y-tiled on Sky Lake and above)
• CCS (must be combined with Y-tiled)
• Intel metadata version N (one capability for each supported version. A bit verbose, but it works)

I believe that those can be blindly intersected by an application or allocation library. As features get implemented that require additional capabilities, we can always add more. The thing that concerns me is if we suddenly discover a bug that requires some sort of capability negotiation to fix. In that case, I think we can handle it with the metadata versions.

[cubanismo]

@jekstrand Take a look at the descriptor set idea in the current header if you haven't yet. I'm curious whether that helps bridge the gap between the larger capability structure you'd initially considered and the smaller capability atoms discussed.

[gfxstrand]

@cubanismo I must say, calling it a "descriptor set" makes me shudder a bit and think of other similarly named over-complicated solutions to not-that-complicated problems. :-)

[cubanismo]

@jekstrand Agreed. And in fact, I censured myself when writing up the header. Currently it's called a "capability set", and I just realized it's missing the list of constraints I intended to include. I'll push a fix shortly.

[cubanismo]

Though it took me about 3 long iterations to get the logic for capability intersection to a reasonable place, with the current (untested) intersection logic I've managed to convince myself this assertion holds up for simple RGB surfaces uses most of the painful capability and constraint cases we run into.

I think this will get more interesting as we start trying to run things like YUV surfaces on those painful-sounding devices that need things like alternating memory banks for different planes or whatever it was. I was hoping someone with a better understanding of those corner cases could construct a prototype driver that exposes them as capabilities/constraints and run some trivial through them.