Bug 110468 - using swrAVX renders incorrectly at particular resolutions
Summary: using swrAVX renders incorrectly at particular resolutions
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/swr (show other bugs)
Version: 19.0
Hardware: x86-64 (AMD64) Windows (All)
: medium major
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-18 09:09 UTC by ayan908
Modified: 2019-09-18 18:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
WGLINFO (15.76 KB, text/plain)
2019-04-18 09:09 UTC, ayan908
Details
Image of failed rendering (8.91 KB, image/png)
2019-04-18 09:10 UTC, ayan908
Details
WGLINFO with GALLIUM_DRIVER=swr (8.58 KB, text/plain)
2019-06-02 06:57 UTC, ayan908
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ayan908 2019-04-18 09:09:15 UTC
Created attachment 144032 [details]
WGLINFO

At certain resolutions (360p, 720p, 1080p, 1440p and possibly others), the rendering is incorrect with GALLIUM_DRIVER=swr, using swrAVX.dll. For example, simply drawing a rectangle with glDrawElements results in an incorrectly rendered result. This works perfectly natively (with Intel's drivers) and with llvmpipe.


Steps to reproduce:

1) Create a window at 720p, OpenGL 3.3 Core.
2) Use the code below to set up the rectangle.
3) Draw the rectangle using glDrawElements.


Code (Unfortunately, I do not know how to use glut so the window creation and rendering loop has been omitted):
#include <iostream>


int main()
{
	// Set up OpenGL context
	// OpenGL 3.3 core, 720p

	GLuint vao, vbo, ibo;
	GLfloat position[] =
	{
		-0.5f, -0.5f, 0.0f,
		0.5f, -0.5f, 0.0f,
		0.5f, 0.5f, 0.0f,
		-0.5f, 0.5f, 0.0f
	};


	GLuint indices[] =
	{
		0, 1, 2,
		0, 2, 3
	};


	glGenVertexArrays(1, &vao);
	glBindVertexArray(vao);

	glGenBuffers(1, &vbo);
	glBindBuffer(GL_ARRAY_BUFFER, vbo);
	glBufferData(GL_ARRAY_BUFFER, sizeof(position), position, GL_STATIC_DRAW);
	glEnableVertexAttribArray(0);
	glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), 0);


	glGenBuffers(1, &ibo);
	glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);
	glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW);

	GLuint vertex = glCreateShader(GL_VERTEX_SHADER), fragment = glCreateShader(GL_FRAGMENT_SHADER);

	
	{

		const char* shaderSource =
			"#version 330 core\n"
			"layout(location = 0) in vec3 position;\n"
			"\n"
			"void main()\n"
			"{\n"
			"gl_Position = vec4(position, 1.0);\n"
			"}\n"
			"";


		glShaderSource(vertex, 1, &shaderSource, 0);
		glCompileShader(vertex);

		// Check compile status

	}

	{

		const char* shaderSource =
			"#version 330 core\n"
			"layout(location = 0) out vec4 col;\n"
			"\n"
			"void main()\n"
			"{\n"
			"col = vec4(0.3, 0.8, 0.2, 1.0);\n"
			"}\n"
			"";


		glShaderSource(fragment, 1, &shaderSource, 0);
		glCompileShader(fragment);

		// Check compile status
	}

	GLuint program = glCreateProgram();
	glAttachShader(program, vertex);
	glAttachShader(program, fragment);

	glLinkProgram(program);
	glValidateProgram(program);

	// Check link status
	glUseProgram(program);

	// Render using glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);

}
Comment 1 ayan908 2019-04-18 09:10:20 UTC
Created attachment 144033 [details]
Image of failed rendering
Comment 2 Jan Zielinski 2019-04-19 12:10:53 UTC
Thanks for reporting the issue and providing the reproducer. We will look into it.
Comment 3 Krzysztof Raszkowski 2019-05-31 18:50:12 UTC
(In reply to ayan908 from comment #0)
> Created attachment 144032 [details]
> WGLINFO
> 
> At certain resolutions (360p, 720p, 1080p, 1440p and possibly others), the
> rendering is incorrect with GALLIUM_DRIVER=swr, using swrAVX.dll. For
> example, simply drawing a rectangle with glDrawElements results in an
> incorrectly rendered result. This works perfectly natively (with Intel's
> drivers) and with llvmpipe.
> 
> 
> Steps to reproduce:
> 
> 1) Create a window at 720p, OpenGL 3.3 Core.
> 2) Use the code below to set up the rectangle.
> 3) Draw the rectangle using glDrawElements.
> 
> 
> Code (Unfortunately, I do not know how to use glut so the window creation
> and rendering loop has been omitted):
> #include <iostream>
> 
> 
> int main()
> {
> 	// Set up OpenGL context
> 	// OpenGL 3.3 core, 720p
> 
> 	GLuint vao, vbo, ibo;
> 	GLfloat position[] =
> 	{
> 		-0.5f, -0.5f, 0.0f,
> 		0.5f, -0.5f, 0.0f,
> 		0.5f, 0.5f, 0.0f,
> 		-0.5f, 0.5f, 0.0f
> 	};
> 
> 
> 	GLuint indices[] =
> 	{
> 		0, 1, 2,
> 		0, 2, 3
> 	};
> 
> 
> 	glGenVertexArrays(1, &vao);
> 	glBindVertexArray(vao);
> 
> 	glGenBuffers(1, &vbo);
> 	glBindBuffer(GL_ARRAY_BUFFER, vbo);
> 	glBufferData(GL_ARRAY_BUFFER, sizeof(position), position, GL_STATIC_DRAW);
> 	glEnableVertexAttribArray(0);
> 	glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), 0);
> 
> 
> 	glGenBuffers(1, &ibo);
> 	glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);
> 	glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices,
> GL_STATIC_DRAW);
> 
> 	GLuint vertex = glCreateShader(GL_VERTEX_SHADER), fragment =
> glCreateShader(GL_FRAGMENT_SHADER);
> 
> 	
> 	{
> 
> 		const char* shaderSource =
> 			"#version 330 core\n"
> 			"layout(location = 0) in vec3 position;\n"
> 			"\n"
> 			"void main()\n"
> 			"{\n"
> 			"gl_Position = vec4(position, 1.0);\n"
> 			"}\n"
> 			"";
> 
> 
> 		glShaderSource(vertex, 1, &shaderSource, 0);
> 		glCompileShader(vertex);
> 
> 		// Check compile status
> 
> 	}
> 
> 	{
> 
> 		const char* shaderSource =
> 			"#version 330 core\n"
> 			"layout(location = 0) out vec4 col;\n"
> 			"\n"
> 			"void main()\n"
> 			"{\n"
> 			"col = vec4(0.3, 0.8, 0.2, 1.0);\n"
> 			"}\n"
> 			"";
> 
> 
> 		glShaderSource(fragment, 1, &shaderSource, 0);
> 		glCompileShader(fragment);
> 
> 		// Check compile status
> 	}
> 
> 	GLuint program = glCreateProgram();
> 	glAttachShader(program, vertex);
> 	glAttachShader(program, fragment);
> 
> 	glLinkProgram(program);
> 	glValidateProgram(program);
> 
> 	// Check link status
> 	glUseProgram(program);
> 
> 	// Render using glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);
> 
> }

Hi,
Tried on win10 (mesa from https://gitlab.freedesktop.org/mesa/mesa/commit/5441d562433a6315ca00c0c69160ff848e5ec34a build using scons + MSVC + LLVM 6.0.1) and works fine with 720p and swr.

Could you attach wglinfo output with GALLIUM_DRIVER=swr? 
Could you describe more how mesa was build (build parameters, compiler name, version etc.)?
Could you describe your environment (env variables, OS version)?

Thanks,
Krzysztof
Comment 4 ayan908 2019-06-02 06:57:40 UTC
Created attachment 144405 [details]
WGLINFO with GALLIUM_DRIVER=swr
Comment 5 ayan908 2019-06-02 09:01:54 UTC
I was using this mesa build with per-app deployment (MSVC): https://github.com/pal1000/mesa-dist-win/releases/tag/19.0.2.

Environment Variables:
GALLIUM_DRIVER=swr
LIBGL_ALWAYS_SOFTWARE=true
MESA_GL_VERSION_OVERRIDE=3.3FC
MESA_GLSL_VERSION_OVERRIDE=330

Windows 10 10.0.17763.

i5-6300u with Intel HD 520 Graphics
Intel driver 26.20.100.6861
Mesa 19.0.2, using symbolic links for the dlls.
Using swrAVX.dll as swrAVX2.dll gave a black screen (assume this is just the build).

OpenGL was loaded by GLFW (from source) and glad (from web service).
Comment 6 Krzysztof Raszkowski 2019-06-06 16:11:00 UTC
1) I'm able to reproduce the problem using binary files from https://github.com/pal1000/mesa-dist-win/releases/tag/19.0.2

2) I've build the same mesa with llvm 8.0.0 (build from source) using Visual Studio 2017:
scons build=release platform=windows machine=x86_64 swr=1 openmp=1 libgl-gdi osmesa graw-gdi
and I don't see any problems (both swrAVX.dll and swrAVX2.dll works fine).

3) I've build the same way like in 2) but using Visual Studio 2019 (MSVC 14.20.27508 and 14.21.27702) and libraries generated by it seems to be "bad" like binaries from https://github.com/pal1000/mesa-dist-win/releases/tag/19.0.2

4) Disabling optimizations (/Od compiler switch) helps (binaries seems to be ok) for VS2019.

We'll look into it but for now we recommend to use VS2017 (MSVC 14.16.27023) for building mesa with swr.
Comment 7 pal1000 2019-06-07 20:28:31 UTC
Thanks for the very extended test. I'll implement a workaround for it for the next release of mesa-dist-win project.
Comment 8 pal1000 2019-06-08 13:19:44 UTC
I tested 19.0.6 release and couldn't reproduce the glitched rendering. Here is the build environment information:

https://raw.githubusercontent.com/pal1000/mesa-dist-win/19.0.6-2/buildinfo/msvc.txt
Comment 9 ayan908 2019-06-12 10:20:45 UTC
That has only seemed to fix swrAVX, swrAVX2 is still a black screen.
Comment 10 pal1000 2019-06-12 13:03:57 UTC
I think that requires another issue report as I don't know if it is caused by VS2019. Also I'll be a bystander to that one because my system doesn't meet the requirements to run swrAVX2.
Comment 11 GitLab Migration User 2019-09-18 18:24:51 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/204.


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.