On Mon, Oct 26, 2015 at 11:53 AM, Roland Scheidegger <srol...@vmware.com> wrote:
> Am 26.10.2015 um 19:31 schrieb Ilia Mirkin: > > On Mon, Oct 26, 2015 at 2:15 PM, Neil Roberts <n...@linux.intel.com> > wrote: > >> Nanley Chery <nanleych...@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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
