On 15 September 2017 at 23:36, Jason Ekstrand <ja...@jlekstrand.net> wrote:
>> --- a/src/intel/vulkan/anv_private.h
>> +++ b/src/intel/vulkan/anv_private.h
>> @@ -2162,12 +2162,22 @@ anv_pipeline_compile_cs(struct anv_pipeline
>> *pipeline,
>> struct anv_format_plane {
>> enum isl_format isl_format:16;
>> struct isl_swizzle swizzle;
>> +
>> + /* Whether this plane contains chroma channels */
>> + bool has_chroma;
>> +
>> + /* For downscaling of YUV planes */
>> + uint8_t denominator_scales[2];
>> +
>> + /* How to map sampled ycbcr planes to a single 4 component element. */
>> + struct isl_swizzle ycbcr_swizzle;
>
>
> I'm getting a bit concerned about how bloated the format table is getting.
> The old table had 184 entries each of which was 32 bits. Now we're looking
> at more like 32 bytes per entry and most of it isn't used for your average
> format. It probably isn't a huge deal but it does seem a bit excessive.
> I'm not quite sure what to do about it though.
>
Couple of ideas:
- have a separate table (map the entries are not sequential) with the
extra plane information
- const struct foo* containing the extra plane information
With the latter anv_format::can_ycbcr becomes
for (unsigned i = 0; i < anv_format::n_planes; i++) {
if (anv_format::anv_format_plane planes[i]->foo)
return true;
}
return false;
-Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
