Bug 54877

Summary:	[bisected] rendering corrupted for windows larger than 2048 pixels in one dimension
Product:	Mesa	Reporter:	Niels Ole Salscheider <niels_ole>
Component:	Drivers/Gallium/r600	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium	CC:	niels_ole, ptpzz
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	fix

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.