Bug 110468

Created attachment 144033 [details]
Image of failed rendering

Thanks for reporting the issue and providing the reproducer. We will look into it.

(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

Created attachment 144405 [details]
WGLINFO with GALLIUM_DRIVER=swr

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).

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.

Thanks for the very extended test. I'll implement a workaround for it for the next release of mesa-dist-win project.

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

That has only seemed to fix swrAVX, swrAVX2 is still a black screen.

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.

-- 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.