[Mesa-dev] [PATCH v6 2/2] mesa/teximage: accept ASTC formats for 3D texture specification

[Roland Scheidegger]

Am 26.10.2015 um 19:31 schrieb Ilia Mirkin:
> On Mon, Oct 26, 2015 at 2:15 PM, Neil Roberts <neil at linux.intel.com> wrote:
>> Nanley Chery <nanleychery at gmail.com> writes:
>>
>>> +      /* Throw an INVALID_OPERATION error if the target is
>>> +       * TEXTURE_CUBE_MAP_ARRAY and the format is not ASTC.
>>> +       */
>>> +      if (target_can_be_compresed &&
>>> +          ctx->Extensions.KHR_texture_compression_astc_ldr &&
>>> +          layout != MESA_FORMAT_LAYOUT_ASTC)
>>>           return write_error(error, GL_INVALID_OPERATION);
>>
>> This seems to cause regressions in the following Piglit tests for Gen9:
>>
>> piglit.spec.ext_texture_compression_s3tc.getteximage-targets cube_array s3tc
>> piglit.spec.arb_texture_cube_map_array.fbo-generatemipmap-cubemap array s3tc_dxt1
>>
>> I think the spec for the extension is based on the GLES spec. Perhaps
>> the intention was to add ASTC support for cube-map array textures
>> whereas previously in GLES no compressed formats were supported for this
>> target. However in regular GL presumably S3TC is supposed to be
>> supported. As it stands this patch disables cube-map array textures for
>> any formats other than ASTC whenever the ASTC extension is available, so
>> it disables S3TC on Gen9.
>>
>> Maybe this section should be limited to GLES?
> 
> I'm having trouble parsing what you're saying, but just want to
> confirm that s3tc is definitely supposed to work on cubemaps, at least
> in desktop GL.
> 

FWIW compressed textures (all formats) not working with cube map
_arrays_ is imho a spec bug in both GL and GLES (in GLES it's just more
explicit with newest spec as it has a table listing all the compressed
formats NOT working for cube map arrays). Seems to be a result of the
compressed formats being developed when cube map arrays weren't arround
thus most of the wording in the spec now only allows them for 2d, 2d
array, cube maps, but not cube map arrays, which totally doesn't make
sense. s3tc itself (in contrast to rgtc etc.) doesn't say anything wrt
to cubemap arrays (spec was updated for 2d arrays, but not cubemap
arrays, thus you could theoretically conclude one way or another, albeit
as I said not allowing them makes no sense imho just like it doesn't for
the other formats).
I've filed bugs for this at khronos bugtracker and it looks like at
least for gles it's going to get fixed (no word on GL, unfortunately).
Of course, binary blobs ignored this bit since forever already, and mesa
was changed to do the same too. Thus imho every test expecting cube map
targets to fail for compressed formats should be ignored.

Roland