Am 04.09.2018 um 15:17 schrieb Daniel Vetter:
On Tue, Sep 4, 2018 at 3:12 PM, Christian König <ckoenig.leichtzumerken@xxxxxxxxx> wrote:Am 04.09.2018 um 15:03 schrieb Daniel Vetter:On Tue, Sep 04, 2018 at 02:33:02PM +0200, Bas Nieuwenhuizen wrote:On Tue, Sep 4, 2018 at 2:26 PM Daniel Vetter <daniel@xxxxxxxx> wrote:On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:Am 04.09.2018 um 12:15 schrieb Daniel Stone:Hi, On Tue, 4 Sep 2018 at 11:05, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote:On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen <bas@xxxxxxxxxxxxxxxxxxx> wrote:+/* The chip this is compatible with. + * + * If compression is disabled, use + * - AMDGPU_CHIP_TAHITI for GFX6-GFX8 + * - AMDGPU_CHIP_VEGA10 for GFX9+ + * + * With compression enabled please use the exact chip. + * + * TODO: Do some generations share DCC format? + */ +#define AMDGPU_MODIFIER_CHIP_GEN_SHIFT 40 +#define AMDGPU_MODIFIER_CHIP_GEN_MASK 0xffDo you really need all the combinations here of DCC + gpu gen + tiling details? When we had the entire discussion with nvidia folks they eventually agreed that they don't need the massive pile with every possible combination. Do you really plan to share all these different things? Note that e.g. on i915 we spec some of the tiling depending upon buffer size and buffer format (because that's how the hw works), not using explicit modifier flags for everything.Right. The conclusion, after people went through and started sorting out the kinds of formats for which they would _actually_ export real colour buffers for, that most vendors definitely have fewer than 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possible formats to represent, very likely fewer than 340,282,366,920,938,463,463,374,607,431,768,211,456 formats, probably fewer than 72,057,594,037,927,936 formats, and even still generally fewer than 281,474,976,710,656 if you want to be generous and leave 8 bits of the 56 available.The problem here is that at least for some parameters we actually don't know which formats are actually used. The following are not real world examples, but just to explain the general problem. The memory configuration for example can be not ASIC specific, but rather determined by whoever took the ASIC and glued it together with VRAM on a board. It is not likely that somebody puts all the VRAM chips on one channel, but it is still perfectly possible. Same is true for things like harvesting, e.g. of 16 channels halve of them could be bad and we need to know which to actually use.For my understanding: This leaks outside the chip when sharing buffers? All the information you only need locally to a given amdgpu instance don't really need to be encoded in modifiers. Pointers to code where this is all decided (kernel and radeonsi would be good starters I guess) would be really good here.I extracted the information on which bits are relevant mostly from the AddrFromCoord functions in addrlib in mesa: for macro-tiles: https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/amd/addrlib/r800/egbaddrlib.cpp#L1587 for micro-tiles (or the micro-tiles in macro-tiles): https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/amd/addrlib/core/addrlib1.cpp#L3016So this is the decoding thing. How many of these actually exist, even when taking all the other information into account? E.g. given a platform + memory config (seems needed) + drm_fourcc + stride + height + width, how much of all these bits do you actually still freely pick? It might be that all the things you need to know from the memory config don't encode smaller than the macro/micro/whatever else stuff. But that's kinda the angle that we looked at this for everyone else. E.g. for multi-plane stuff, if everyone picks the same config for the 2nd/3rd plane, then you don't actually need to encode that. It just becomes part of the implied stuff in the modifier.The pipe/bank configuration for the 2nd/3rd plane is the same, but the tile configuration is potentially different. We can make an educated guess, but I don't think that this is universal applicable as well.Why? The source code for amdgpu.ko, mesa, radv, amdvk is all open. Should be possible to figure out what's actually used (on buffers you want to share), and then figuring out how to best encode the information you need to reconstruct all the information. You might need to occasionally respin that if best practices for how to lay out buffers changes after you started upstreaming for a given generation. But ime hw people have pretty strong opinions on how to best tile things. You even know what's coming down the internal pipeline. Or do you mean something else with "educated guess"?
I mean something else. It can depend on the use case what a buffer object ends up with.
In other words when you want to transcode a video you could use a different layout as when you want to display the resulting image.
So essentially we would need to encode the use case and not the format of the buffer.
That might work, but my gut feeling strongly tells me that this is the wrong approach.
Christian.
-DanielRegards, Christian.-Daniel-DanielRegards, Christian.If you do use 256 bits in order to represent 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 modifiers per format, userspace would start hitting OOM pretty quickly as it attempted to enumerate and negotiate acceptable modifiers. Either that or we need to replace the fixed 64-bit modifier tokens with some kind of eBPF script. Cheers, Daniel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
