[Mesa-dev] [PATCH 1/6] i965: add missing BRW_SURFACEFORMAT constants from Ivybridge PRM

Kenneth Graunke kenneth at whitecape.org
Fri Oct 12 09:51:49 PDT 2012


On 10/11/2012 10:48 PM, Matt Turner wrote:
> On Tue, Oct 9, 2012 at 2:33 AM, Chris Forbes <chrisf at ijw.co.nz> wrote:
>>  From the master surface formats list in the Sampler Engine chapter.
>> The relevant formats for 2_10_10_10 are mentioned in the Sandybridge
>> PRM as vertex attribute types, but the 0x1b*- encodings are missing from its
>> list in the Sampler Engine chapter.
>> ---
>>   src/mesa/drivers/dri/i965/brw_defines.h | 33 +++++++++++++++++++++++++++++++++
>>   1 file changed, 33 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h
>> index 6dc4707..4ae89da 100644
>> --- a/src/mesa/drivers/dri/i965/brw_defines.h
>> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
>> @@ -424,6 +424,39 @@
>>   #define BRW_SURFACEFORMAT_R16G16B16_SNORM                0x19D
>>   #define BRW_SURFACEFORMAT_R16G16B16_SSCALED              0x19E
>>   #define BRW_SURFACEFORMAT_R16G16B16_USCALED              0x19F
>> +#define BRW_SURFACEFORMAT_BC6H_SF16                      0x1A1
>> +#define BRW_SURFACEFORMAT_BC7_UNORM                      0x1A2
>> +#define BRW_SURFACEFORMAT_BC7_UNORM_SRGB                 0x1A3
>> +#define BRW_SURFACEFORMAT_BC6H_UF16                      0x1A4
>> +#define BRW_SURFACEFORMAT_PLANAR_420_8                   0x1A5
>> +#define BRW_SURFACEFORMAT_R8G8B8_UNORM_SRGB              0x1A8
>> +#define BRW_SURFACEFORMAT_ETC1_RGB8                      0x1A9
>> +#define BRW_SURFACEFORMAT_ETC2_RGB8                      0x1AA
>> +#define BRW_SURFACEFORMAT_EAC_R11                        0x1AB
>> +#define BRW_SURFACEFORMAT_EAC_RG11                       0x1AC
>> +#define BRW_SURFACEFORMAT_EAC_SIGNED_R11                 0x1AD
>> +#define BRW_SURFACEFORMAT_EAC_SIGNED_RG11                0x1AE
>> +#define BRW_SURFACEFORMAT_ETC2_SRGB8                     0x1AF
>> +#define BRW_SURFACEFORMAT_R16G16B16_UINT                 0x1B0
>> +#define BRW_SURFACEFORMAT_R16G16B16_SINT                 0x1B1
>> +#define BRW_SURFACEFORMAT_R32_SFIXED                     0x1B2
>> +#define BRW_SURFACEFORMAT_R10G10B10A2_SNORM              0x1B3
>> +#define BRW_SURFACEFORMAT_R10G10B10A2_USCALED            0x1B4
>> +#define BRW_SURFACEFORMAT_R10G10B10A2_SSCALED            0x1B5
>> +#define BRW_SURFACEFORMAT_R10G10B10A2_SINT               0x1B6
>> +#define BRW_SURFACEFORMAT_B10G10R10A2_SNORM              0x1B7
>> +#define BRW_SURFACEFORMAT_B10G10R10A2_USCALED            0x1B8
>> +#define BRW_SURFACEFORMAT_B10G10R10A2_SSCALED            0x1B9
>> +#define BRW_SURFACEFORMAT_B10G10R10A2_UINT               0x1BA
>> +#define BRW_SURFACEFORMAT_B10G10R10A2_SINT               0x1BB
>> +#define BRW_SURFACEFORMAT_R64G64B64A64_PASSTHRU          0x1BC
>> +#define BRW_SURFACEFORMAT_R64G64B64_PASSTHRU             0x1BD
>> +#define BRW_SURFACEFORMAT_ETC2_RGB8_PTA                  0x1C0
>> +#define BRW_SURFACEFORMAT_ETC2_SRGB8_PTA                 0x1C1
>> +#define BRW_SURFACEFORMAT_ETC2_EAC_RGBA8                 0x1C2
>> +#define BRW_SURFACEFORMAT_ETC2_EAC_SRGB8_A8              0x1C3
>> +#define BRW_SURFACEFORMAT_R8G8B8_UINT                    0x1C8
>> +#define BRW_SURFACEFORMAT_R8G8B8_SINT                    0x1C9
>>   #define BRW_SURFACE_FORMAT_SHIFT       18
>>   #define BRW_SURFACE_FORMAT_MASK                INTEL_MASK(26, 18)
>>
>> --
>> 1.7.12.2
>
> A lot of these formats aren't actually supported by the hardware, so
> they probably shouldn't go in the code until there's hardware that can
> actually use them.
>
> For instance, IVB's IHD_OS_Vol4_Part1.pdf says
>
> Errata : BC6H_SF16, BC6H_UF16, and BC7_SRGB are not supported and may
> result in data corruption
> if used.
>
> Also, IVB doesn't support ETC1 or ETC2. Not sure about some of the others.
>
> Probably best to only add the formats needed for this extension.

I don't really mind either way.  We'll need (for example) the ETC bits 
at some point, and it's unlikely that they'll renumber the enums.  (At 
least, I've never seen it happen.)

--Ken


More information about the mesa-dev mailing list