From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 89156] r300g: GL_COMPRESSED_RED_RGTC1 / ATI1N support broken Date: Thu, 26 Feb 2015 11:46:17 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1776626862==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id E57D56E217 for ; Thu, 26 Feb 2015 03:46:16 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1776626862== Content-Type: multipart/alternative; boundary="1424951176.87802f0.21655"; charset="UTF-8" --1424951176.87802f0.21655 Date: Thu, 26 Feb 2015 11:46:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://bugs.freedesktop.org/show_bug.cgi?id=3D89156 --- Comment #6 from Stefan D=C3=B6singer --- (In reply to Marek Ol=C5=A1=C3=A1k from comment #5) > So it's a compiler bug. In which sense? Is there something in the spec that tells me I should expect garbage when I use texture2D().xxxx? Or is this something the driver tells = the compiler and the compiler is supposed to generate a swizzle-free texture2D statement? > > static const char ati1n_data[] =3D > > { > > /* A 4x4 texture with the color component at 50%. */ > > 0x7f, 0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > > }; >=20 > That's expected. ATI1N operates at lower precision. I'm afraid I can't > change that. Windows gives me a proper value (0x7f, which is pretty close to 0x80). Do y= ou have any idea how it does that? I can try to find a scheme behind the imprecision if it helps you. There ma= y be something like an off by one error that the driver can account for. --=20 You are receiving this mail because: You are the assignee for the bug. --1424951176.87802f0.21655 Date: Thu, 26 Feb 2015 11:46:16 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Comment= # 6 on bug 89156<= /a> from Stefan D=C3=B6singer 
(In reply to Marek Ol=C5=A1=C3=A1k from comment #5)
> So it's a compiler bug.
In which sense? Is there something in the spec that tells me I should expect
garbage when I use texture2D().xxxx? Or is this something the driver tells =
the
compiler and the compiler is supposed to generate a swizzle-free texture2D
statement?

> > static const char ati1n_data[] =3D
> > {
> >     /* A 4x4 texture with the color component at 50%. */
> >     0x7f, 0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > };
>=20
> That's expected. ATI1N operates at lower precision. I'm afraid I can't
> change that.
Windows gives me a proper value (0x7f, which is pretty close to 0x80). Do y=
ou
have any idea how it does that?

I can try to find a scheme behind the imprecision if it helps you. There ma=
y be
something like an off by one error that the driver can account for.

You are receiving this mail because: =20=20=20=20=20=20
  • You are the assignee for the bug.
--1424951176.87802f0.21655-- --===============1776626862== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1776626862==--