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 0xff > > > > Do 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#L3016 > -Daniel > > > > > Regards, > > 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
