[RFC] drm/amdgpu: Add macros and documentation for format modifiers.

Christian König christian.koenig at amd.com
Tue Sep 4 12:59:09 UTC 2018


Am 04.09.2018 um 14:22 schrieb Daniel Stone:
> Hi,
>
> On Tue, 4 Sep 2018 at 11:44, Christian König
> <ckoenig.leichtzumerken at gmail.com> 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?

Because it results in a different memory layout.

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

If the other device doesn't have the same hardware config it probably 
can't access that buffer.

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

Well that is exactly the point where my understanding stops. No idea how 
the user space driver is handling this.

Marek came up with the interop interface, he needs to explain the details.

Regards,
Christian.

>
> Cheers,
> Daniel



More information about the dri-devel mailing list