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. -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
