On Mon, Mar 2, 2015 at 12:11 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Interesting. The way I read this though is that this format is more or > less solely used as a workaround for chips not supporting (or at least > not exposing) s3tc. I guess I understand now why the encoding format > wasn't published...
I didn't look carefully, but I suspect it has to do with getting around some specific claims in the s3tc patent. FWIW a3xx also supports s3tc, but the blob driver does not expose the relevant extensions. (I found them by brute force.) > Well ok I can live with this if it's indeed still useful (I guess > there's still plenty of gles only chips out there not supporting s3tc > and some apps may not even expect the chips to support it probably). > You are quite right that the gallium changes are minimal, I was more > concerned with the fact that lacking a formal specification it was some > "magic" more or less untestable feature. Could you link somewhere in the > commit to that paper detailing the format? Sure. Also I sent a test to the piglit list with a compressed and equivalent uncompressed image (generated by AMD's Compressonator tool), similar to the ETC1 test. The test passes on my a320 ifc6410 board. You could try to make a software version of the decoder based on that paper's recommendations, but I didn't bother. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
