Bug 47166

Summary:	Bad datatype in interpolate_int_colors
Product:	Mesa	Reporter:	hdewey2
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	medium
Version:	8.0
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description hdewey2 2012-03-09 12:52:57 UTC

I have a program that uses Mesa for calculation of radiosity view factors. During drawing/reading I get the following errors:

Mesa 8.0.1 implementation error: bad datatype 0x1010101 in interpolate_int_colors
Please report at bugs.freedesktop.org
Mesa 8.0.1 implementation error: Invalid datatype in _mesa_convert_colors
Please report at bugs.freedesktop.org

I have tried Mesa 8.0.1, 7.11.2, and 7.8.1 and they all have the same issue.

The errors seem to be related to the near clipping plane distance. Due to the geometry that is being rendered, the global near clipping plane that is required is 7.178571e-08 (compared to a global far clipping plane value of 1.195193e+02). A total of 108 stacked frustums are used to avoid Z-buffer precision issues stemming from this small value, so the nearest frustum has near and far clipping plane distances of 7.178571e-08 and 3.263309e-05, respectively. If I manually change the nearest near clipping plane distance by +/- 10%, I do not get the Mesa errors. Manually changing this value by a smaller amount, +/- 5%, still produces errors.

After the Mesa errors appear, some of the pixel data read using glReadPixels contains junk data (RGBA = 0x01010101) ... the same value as the invalid datatype mentioned in the error message.

The program runs just fine on ATI and NVIDIA hardware (Windows desktops without Mesa), but not when using OSMesa without graphics hardware (on a SUSE Linux HPC).

Here's some additional information in case any of it matters:
The scene consists of ~270,000 GL_QUADS that are drawn from ~1,000,000 different eye locations.
The drawing is done into a hemicube (drawing is done 5 times using different orientations and viewports for each eye location).
The program is using 2 PBOs to asynchronously draw and read the framebuffer data.
The PBOs are read using glReadPixels with a type of GL_UNSIGNED_BYTE and a hint of GL_STATIC_READ.
The drawing is done into a FBO with RBOs that are using GL_RGBA for color and GL_DEPTH24_STENCIL8_EXT for depth and stencil data.
The drawing is done with multiple VBOs that are limited to 4.8 MBytes in size each (for performance reasons).
The VBOs consist of interleaved color (4 x GL_UNSIGNED_BYTE) and location (3 x GL_FLOAT) data for each vertex.

Comment 1 Brian Paul 2012-03-13 08:10:26 UTC

Is it possible to get a test program or an apitrace of the app?  The later tool is available at https://github.com/apitrace/apitrace

Does the failure still happen if you draw fewer polygons?

You might also try running with valgrind to see if it's a memory corruption issue.  But valgrind will be pretty slow if the dataset is large.

Comment 2 hdewey2 2012-03-15 09:09:46 UTC

Is there a secret to getting apitrace to work with OSMesa?  Since I'm using either OSMesaGetProcAddress or dlopen("libOSMesa.so",...)/dlsym(...) to get the extension function pointers, they do not get logged by apitrace which only redirects calls to libGL.so.  If you want, I can give you a trace that doesn't have the extension function calls logged, but that doesn't seem like it will give you what you need to reproduce the problem since so many extension function calls are being used.

I have tried reducing the drawing to 10,000 quads (leaving everything else identical), and that works without any problems.

We have tried using valgrind with this program before, but the program uses other 3rd party libaries that are not "valgrind clean" and do not have suppression files, so the output is pretty much useless.

Comment 3 Jose Fonseca 2012-03-15 10:05:58 UTC

(In reply to comment #2)
> Is there a secret to getting apitrace to work with OSMesa?  Since I'm using
> either OSMesaGetProcAddress or dlopen("libOSMesa.so",...)/dlsym(...) to get the
> extension function pointers, they do not get logged by apitrace which only
> redirects calls to libGL.so.  If you want, I can give you a trace that doesn't
> have the extension function calls logged, but that doesn't seem like it will
> give you what you need to reproduce the problem since so many extension
> function calls are being used. 

apitrace doesn't support OSMesa, and it would require some work to support it.

Before that, it would be better to recode the application using a standard OpenGL implement, and see if that allows to reproduce the problem when retracing on Mesa.

apitrace works on windows too. You can also try to trace with AMD/NVIDIA drivers on Windows.

Comment 4 Timothy Arceri 2018-05-11 04:43:34 UTC

trace was never provided. Closing as wontfix.

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.