From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 54877] [bisected] rendering corrupted for windows larger than
2048 pixels in one dimension
Date: Fri, 14 Sep 2012 06:35:08 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path:
Received: from culpepper.freedesktop.org (unknown [131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id 076269E7B1
for ;
Thu, 13 Sep 2012 23:35:08 -0700 (PDT)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=54877
--- Comment #3 from Vadim Girlin 2012-09-14 06:35:08 UTC ---
(In reply to comment #2)
> Created attachment 67121 [details] [review]
> fix
>
> This fixes it. I need to find out how the quant mode affects the range of
> values.
My guess is that QUANT_MODE determines the position of fixed point for internal
calculations in hw. Quantization precision 1/4096 means 12 bits, and it looks
like we have 11 bits before the point in that case, with 23 bits total. So if
we need to increase the range, we have to move the point lowering the
precision.
I've tried 1/256 and other values on evergreen for initial implementation of
that patch in hope that it'll be enough, but IIRC 1/4096 fixed more tests
(though possibly some test results were simply random). If some tests are
really failing due to lower precision, I guess we might want to adjust
QUANT_MODE dynamically.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.