Bug 54877 - [bisected] rendering corrupted for windows larger than 2048 pixels in one dimension
Summary: [bisected] rendering corrupted for windows larger than 2048 pixels in one dim...
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-13 15:36 UTC by Niels Ole Salscheider
Modified: 2019-09-18 19:00 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
fix (1.23 KB, patch)
2012-09-13 21:30 UTC, Alex Deucher
Details | Splinter Review

Description Niels Ole Salscheider 2012-09-13 15:36:11 UTC
I have a Radeon HD 6870 under Linux 3.6.0-rc5.

Since commit f44bda17f515c411071ca8744ebd96039d9c583b, the output of OpenGL applications is corrupted if the window is larger than 2048 pixels in at least one dimension.
All parts of the image with a coordinate larger than 2047 show garbage while the textures seem to be shifted for the remaining parts of the image.
Comment 1 Andreas Boll 2012-09-13 16:27:30 UTC
Cc Vadim
Comment 2 Alex Deucher 2012-09-13 21:30:33 UTC
Created attachment 67121 [details] [review]
fix

This fixes it.  I need to find out how the quant mode affects the range of values.
Comment 3 Vadim Girlin 2012-09-14 06:35:08 UTC
(In reply to comment #2)
> Created attachment 67121 [details] [review] [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.
Comment 4 Alex Deucher 2012-09-14 13:47:19 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Created attachment 67121 [details] [review] [review] [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.

That makes sense.  The hw worked similarly on r300-r500.  We should adjust the mode based on the size of the buffer I suppose.
Comment 5 GitLab Migration User 2019-09-18 19:00:50 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/418.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.