+everyone again On Tue, Sep 4, 2018 at 2:39 PM Bas Nieuwenhuizen <bas@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Sep 4, 2018 at 2:22 PM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > > > Hi, > > > > On Tue, 4 Sep 2018 at 11:44, Christian König > > <ckoenig.leichtzumerken@xxxxxxxxx> wrote: > > > Am 04.09.2018 um 12:15 schrieb Daniel Stone: > > > > 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. > > > > Sure, that's fine, but I'm not sure why, for instance, 'half of the > > memory channels are bad and must be avoided' would be attached to a > > format in the same way that macrotile size/depth would be? Similarly, > > what happens if you encode a channel or lane blacklist mask into a > > modifier, and then you import a buffer with that modifier into a > > client API on another device. Does that also apply to the other device > > or only the source device? > > > > How then do you handle the capability query between them: is it > > relevant to device B attempting to import and sample from an image > > that device A only has a 128-bit memory bus because of SKU > > configuration? How does generic userspace look at a token which > > encodes all of this information and know that the buffer is > > interchangeable between devices? > > So my idea here is to encode all the bits that determine format in a > way that as much as possible if it > results in the same layout it should get the same modifier(i.e. remove > useless info): > > https://lists.freedesktop.org/archives/dri-devel/2018-September/188418.html > > An example of the per-chip things is the PIPE_CONFIG, which is used > for address calculation in the macro-tiled mode: > > https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/amd/addrlib/r800/siaddrlib.cpp#L666 > > two chips with different PIPE_CONFIG will have different texture > layouts, as the address swizzles are different. > > So it gets included in the modifier (the PIPE_CONFIG is pretty much > constant per chip but multiple chips might have the same PIPE_CONFIG). > > > > > Cheers, > > Daniel > > _______________________________________________ > > 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
