| Summary: | Geometry Shader - Incorrect Output | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | dan |
| Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED MOVED | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | normal | ||
| Priority: | medium | CC: | tom.stdenis |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Typical output
Trace |
||
Interesting, thanks for the report. Is this really an issue of having separate VBOs, or does the issue also occur when you use separate draw calls with a single VBO? Or a single draw call? Do you have a simple program that reproduces this? Alternatively, an apitrace is likely to help. I've just tried with multiple draw calls using the same VBO and it appears this does also cause the error. However, it appears there has to be 3 or more calls to cause the error (1 and 2 calls produce the expected output). Apologies for that. It was the way my application works that led me down that path. I currently do not have a simple program that demonstrates the error. I have amended the application I've been writing to call the test shaders as I was trying to work out what was wrong with my application. I could probably create something. What is the usual format to provide this in? Thanks. https://github.com/apitrace/apitrace This can be used to record (and replay) all the GL commands sent down to the driver. I created a minimal test program that simply draws the 3 polygons (12 sided). I have used apitrace with this test program to generate a trace and I'll upload this shortly. Thanks. Created attachment 129697 [details]
Trace
What hardware is this on? I wonder if it's a dup of 99850 (which was found on a Carrizo). FWIW it appears to render correctly on both nouveau (GK208) as well as i965 (SKL). The hardware is Radeon HD 4890. Also good on radeonsi (POLARIS10) and i965 (HSW). Looks good on Barts (6870) (mesa-git 903e1047) that actually uses r600g. When replaying the trace I see an api issue message though: 1430: message: api issue 1: FBO incomplete: no attachments and default width or height is 0 [-1] Hi, Is it likely this will be looked into or are there no plans to look into issues for older cards? No one has been able to reproduce, tried on various hardware including a Radeon 6870 (BARTS). Without more information, it's unlikely that anything will happen. At the very least (a) recheck on mesa master and if it's still broken, (b) supply information about your GPU. Hi, It is still a problem. I detailed the card in comment 8 (HD 4890). Could you advise what other information you would need about the GPU? Thanks. The 4890 has a RV790 GPU. I've run the trace again and also see an error similar to the one Gert mentioned: 1639 Message api issue 1: FBO incomplete: no attachments and default width or height is 0 [-1]. There are also more errors reported around glDrawArrays as follows: major api error 2: GL_INVALID_ENUM in glGetIntegerV(pname=GL_TEXTURE_BINDING_CUBE_MAP_ARRAY) warning: dumping of normalized attribute (vertexCoord) not yet supported warning: dumping of normalized attribute (textureCoord) not yet supported I was reading about the R600 driver and came across a TODO page that suggested testing using piglit. I downloaded and compiled this. I ran the "shader.py" test and it gave the following results: skip: 26496 Pass: 6567 Warn: 2 Fail:496 Crash: 5 I'm not sure if piglit is a good measure on this but the number of fails seems very high. -- 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/597. |
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.
Created attachment 129684 [details] Typical output Hi, I am developing a cross-platform application. I have recently found an issue that is only present when it is tested on a Ubuntu machine. I have managed to find a minimal example that shows the issue as follows: The vertex shader: #version 150 in vec2 pos; void main(void) { gl_Position = vec4(pos, 0.0, 1.0); } The fragment shader: #version 150 out vec4 outColour; void main(void) { outColour = vec4(1.0f, 1.0f, 1.0f, 1.0f); } The geometry shader: #version 150 layout(points) in; layout(line_strip, max_vertices = 13) out; uniform mat4 vpMatrix; void main() { for(int i = 0; i < 13; i++) { float polygonAngle = (i * 30) + 90.0f; vec4 vertexPosition = vec4((sin(radians(polygonAngle)) * 0.5f) + gl_in[0].gl_Position.x, (cos(radians(polygonAngle)) * 0.5f) + gl_in[0].gl_Position.y, 0.0f, 1.0f); gl_Position = vpMatrix * vertexPosition; EmitVertex(); } EndPrimitive(); } The problem occurs when the shader program is used with multiple VBO's. For example: 3 separate VBO's are created with {-1.0f, 1.0f}, {1.0f, 1.0f}, {1.0f, -1.0f} as the data. Then, for each repaint: for(int i = 0; i < 3; i++) { Bind array buffer i. glDrawArrays(GL_POINTS, 0, 1); } This produces strange results for the third polygon (shown in the attached image Output.JPG). If tested on a Windows 10 machine (exactly the same hardware) or an OSX machine, the results are as expected (3 regular polygons with 12 sides).