cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

mvschenkelberg
Journeyman III

Issues with OpenGL application on Centos 6.4 with Dell M4800

I work on a major software project for the national weather service.  We develop in java and use jogl for opengl.  We have always used nvidia cards until recently a set of Dell M4800 laptops were ordered with the AMD FirePro M5100 card by mistake.  I took this as an opportunity to try and make our application work with non nvidia cards and have not had much success.  I've tried the driver from dell (Driver Details | Dell US) as well as the latest from the AMD site (AMD Linux Driver) and both had the same issues with our application (No issues found with the OS and compiz effects).  I haven't done a full test on everything that doesn't work but for starters:

1. Image tiles would be completely wrong occasionally.  See images here: Graphics Issues - Imgur.  We use LUMINANCE textures and apply colormapping in the fragment shader.  Zooming and panning around on our map would cause the tiles to display horribly at certain zoom/pan locations.  They were consistent in the locations they would display poorly in. I only saw the issue with internal format GL_LUMINANCE16 and texture type of GL_SHORT and could not get it to happen with textures GL_LUMINANCE8 (GL_BYTE) and GL_LUMINANCE32 (GL_FLOAT).

2. When doing a render to (luminance) texture with a frame buffer object, after the render to texture was done, when attempting to draw the texture that was rendered to, we get the error: GL_INVALID_FRAMEBUFFER_OPERATION_EXT (1286).  This only happens immediately after rendering to the texture.  We are able render the texture after we do the R2T and it displays correctly so I know the fbo was correctly rendered to.  The error occurs in this block of code when drawing the mesh for the image rendered to:

            // Clear error bit

            gl.glGetError();

            gl.glEnableClientState(GL.GL_VERTEX_ARRAY);

            gl.glEnableClientState(GL.GL_TEXTURE_COORD_ARRAY);

            gl.glInterleavedArrays(GL.GL_T2F_V3F, 0, fb.rewind());

            int error = gl.glGetError();

I'm guessing maybe the firepro card doesn't support rendering a texture that was just rendered to in the frame but I'm not sure.

I'm mostly concerned about #2 because I can always attempt to switch my short data to float data to see if it works (although I would like to save the graphics memory and keep it as floats). But for #2, I'm out of ideas.

Thanks

Max

0 Likes
6 Replies
gsellers
Staff

Hi,

Would it be possible to get access to your application or another repro case? That would really help us debug this.

Thanks,

Graham

0 Likes

I will post a small standalone program for the frame buffer issue today since it is easy to replicate for me in my environment.  Is there any ideas about the weird imagery issues? Somewhere I could start looking into?

Max

0 Likes

Okay, thanks.

As for things you can do, I don't have anything specific. In general, it seems you're using a lot of legacy functionality (client arrays, luminance textures, etc.). I would recommend against that and suggest looking at ways to use more modern functionality (VBO/VAO, GL_RED textures, etc.).

Also, if you can enable a debug context, that would probably help you track down the source of the error. I'm not sure if the Java bindings support that or not.

Graham

0 Likes

Interesting idea, I'll play around with switching to VBOs and see if that helps.  What is the difference between a GL_LUMINANCE and GL_RED texture? I didn't even realize LUMINANCE was deprecated.  The jogl api we are on doesn't expose GL functionality beyond 2.x.  Is it possible to create 8, 16, and 32 bit GL_RED textures?

I have some more info on the bad tiles.  I wanted to see if it was a mesh issue so I enabled our code to show the meshes and sudden the tiles all drew correctly under the mesh.  Here is an album showing that: AMD Rendering More Info - Imgur

I then switched the mesh color to transparent to see if the images still drew correctly and they did!  I then, switched to just drawing a transparent line at 0,0 -> 0,0 and the images still drew correctly.  We bulk render multiple images so enabling meshes adds a line draw operation between each image render.  When I get a change I was going to switch the mesh drawing logic to draw the meshes AFTER all the images have been drawn and see if it makes a difference.  My guess is the images will draw incorrectly still and it has something to do with adding that line draw operation between the image draws.

Edit: Solved the FBO issue by using VBOs for vertex/texture coordinates for the FBO.  I wonder if it was because the images being rendered to the FBO were using VBOs but when we went to render the FBO, we didn't use them.  I wonder if mixing the two in the same render pass caused issues because once the FBO was rendered to, we could render it on the screen not using VBOs without errors.

Still not sure what the issue with the image tiles is, will try to switch to GL_RED but it sounds like it won't be as efficient since it always uses 32 bits for storing a pixel based on my research.

Edit 2: Tried GL_R16  as the internal format, GL_RED as the format, and GL_SHORT as the type with no luck, still got the ugly tiles occasionally that draw correctly if I draw a line transparent line after each image render.

Thanks

Max

0 Likes

It sounds like we're missing some state validation and the extra draws with the transparent lines is making it kick back in. Once you get a smaller reproduction case together, we can investigate.

Graham

0 Likes

When looping over the images to render, if I do a glFlush() right after drawing the mesh, everything draws correctly.  Any idea why this might "fix" things and is there any downside to keeping this in place always?

Thanks,

Max

0 Likes