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

[Nanley Chery]

On Mon, Oct 26, 2015 at 11:53 AM, Roland Scheidegger <sroland at vmware.com>
wrote:

> 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.
>
>
Thank you for filing the spec bugs.

Nanley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151026/fd14bbf4/attachment.html>