<div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Mon, Oct 26, 2015 at 11:53 AM, Roland Scheidegger <<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 26.10.2015 um 19:31 schrieb Ilia Mirkin: > On Mon, Oct 26, 2015 at 2:15 PM, Neil Roberts <<a href="mailto:neil@linux.intel.com" target="_blank">neil@linux.intel.com</a>> wrote: >> Nanley Chery <<a href="mailto:nanleychery@gmail.com" target="_blank">nanleychery@gmail.com</a>> 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). </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. </blockquote><div> </div><div>Thank you for filing the spec bugs. </div><div>Nanley </div></div></div></div>