I have an OpenGL test application that is producing incredibly unusual results. When I start up the application it may or may not feature a severe graphical bug.
It might produce an image like this:
http://i.imgur.com/JwPoDrh.jpg
Or like this:
http://i.imgur.com/QEYwhBY.jpg
Or just the correct image, like this:
http://i.imgur.com/zUJbwCM.jpg
The scene consists of one spinning colored cube (made of 12 triangles) with a simple shader on it that colors the pixels based on the absolute value of their model space coordinates. The junk faces appear to spin with the cube as though they were attached to it and often junk triangles or quads flash on the screen briefly as though they were rendered in 2D.
The thing I find most unusual about this is that the behavior is highly inconsistent, starting the exact same application repeatedly without me personally changing anything else on the system will produce different results, sometimes bugged, sometimes not, the arrangement of the junk faces produced isn't consistent either.
I can't really post source code for the application as it is very lengthy and the actual OpenGL calls are spread out across many wrapper classes and such.
This is occurring under the following conditions:
Windows 10 64 bit OS (although I have observed very similar behavior under Windows 8.1 64 bit).
AMD FX-9590 CPU (Clocked at 4.7GHz on an ASUS Sabertooth 990FX).
AMD 7970HD GPU (It is a couple years old and occasionally areas of the screen in 3D applications become scrambled, but nothing on the scale of what I'm experiencing here).
Using SDL (https://www.libsdl.org/) for window and context creation.
Using GLEW (http://glew.sourceforge.net/) for OpenGL.
Using OpenGL versions 1.0, 3.3 and 4.3 (I'm assuming SDL is indeed using the versions I instructed it to).
AMD Catalyst driver version 15.7.1 (Driver Packaging Version listed as 15.20.1062.1004-150803a1-187674C, although again I have seen very similar behavior on much older drivers).
Catalyst Control Center lists my OpenGL version as 6.14.10.13399.
This looks like a broken graphics card to me. Most likely some problem with the memory (either the memory itself, or some soldering problem). Artifacts like those you see can happen if for some reason setting the address for a memory operation does not fully settle or happen at all, before starting the read; that can happen due to a bad connection between the GPU and the memory (solder connections failed) or because the memory itself failed.
Solution: Buy new graphics card. You may try out what happens if you resolder it using a reflow process; there are some tutorials on how to do this DIY, but a proper reflow oven gives better results.
Related
My problem may seem vague without code, but it actually isn't.
So, there I've got an almost properly-working widget, which renders video frames.
Qt 5.10 and QOpenGLWidget subclassing worked fine, I didn't make any sophisticated optimizations -- there are two textures and a couple of shaders, converting YUV pixel format to RGB -- glTexImage2D() + shaders, no buffers.
Video frames are obtained from FFMPEG, it shows great performance due to hardware acceleration... when there is only one video window.
The piece of software is a "video wall" -- multiple independent video windows on the same screen. Of course, multi-threading would be the preferred solution, but legacy holds for now, I can't change it.
So, 1 window with Full HD video consumes ~2% CPU & 8-10% GPU regardless of the size of the window. But 7-10 similar windows, launched from the same executable at the same time consume almost all the CPU. My math says that 2 x 8 != 100...
My best guesses are:
This is a ffmpeg decoder issue, hardware acceleration still is not magic, some hardware pipeline stalls
7-8-9 independent OpenGL contexts cost a lot more than 1 cost x N
I'm not using PUBO or some other complex techniques to improve OpenGL rendering. It still explains nothing, but at least it is a guess
The behavior is the same on Ubuntu, where decoding uses different codec (I mean that using GPU accelerated or CPU accelerated codecs makes no difference!), so, it makes more probable that I'm missing something about OpenGL... or not, because launching 6-7 Qt examples with dynamic textures shows normal growth of CPU usages -- it is approximately a sum for the number of windows.
Anyway, it becomes quite tricky for me to profile the case, so I hope someone could have been solving the similar problem before and could share his experience with me. I'd be appreciated for any ideas, how to deal with the described riddle.
I can add any pieces of code if that helps.
I'm building an OpenGL based application. It uses some high-res textures. Sometimes, when switching to other applications running on my computer, and coming back, the memory of some of my texture storages gets corrupted . I am not 100% sure of what is happening, but it feels like the driver is short on memory so it steals some blocks of memory of the texture storage of my application and gives it to other applications. Once I come back to my application, there are black rectangular holes in some of my textures.
I can totally understand that the system runs out of VRAM and things like this happen, but I would like to be informed about this when this happens, so when the user returns to the application, I can restore memory buffers if they got invalidated.
Is this behaviour normal, or is the driver supposed to sort of swap out texture data and restore it later (and is not doing that or failing to do so)? If this behaviour is normal, how do I detect that this happened and how do I deal with this?
For the sake of completeness: I'm experiencing this on macOS Sierra on a MacBook Pro 8,1 which has an Intel HD Graphics 3000 and 16 GB of ram.
I have a code which basically draws parallel coordinates using opengl fixed func pipeline.
The coordinate has 7 axes and draws 64k lines. SO the output is cluttered, but when I run the code on my laptop which has intel i5 proc, 8gb ddr3 ram it runs fine. One of my friend ran the same code in two different systems both having intel i7 and 8gb ddr3 ram along with a nvidia gpu. In those systems the code runs with shuttering and sometimes the mouse pointer becomes unresponsive. If you guys can give some idea why this is happening, it would be of great help. Initially I thought it would run even faster in those systems as they have a dedicated gpu. My own laptop has ubuntu 12.04 and both the other systems have ubuntu 10.x.
Fixed function pipeline is implemented using gpu programmable features in modern opengl drivers. This means most of the work is done by the GPU. Fixed function opengl shouldn't be any slower than using glsl for doing the same things, but just really inflexible.
What do you mean by coordinates having axes and 7 axes? Do you have screen shots of your application?
Mouse stuttering sounds like you are seriously taxing your display driver. This sounds like you are making too many opengl calls. Are you using immediate mode (glBegin glVertex ...)? Some OpenGL drivers might not have the best implementation of immediate mode. You should use vertex buffer objects for your data.
Maybe I've misunderstood you, but here I go.
There are API calls such as glBegin, glEnd which give commands to the GPU, so they are using GPU horsepower, though there are also calls to arrays, other function which have no relation to API - they use CPU.
Now it's a good practice to preload your models outside the onDraw loop of the OpenGL by saving the data in buffers (glGenBuffers etc) and then use these buffers(VBO/IBO) in your onDraw loop.
If managed correctly it can decrease the load on your GPU/CPU. Hope this helps.
Oleg
Started up remote debugging a C++ project today on a Win 7 machine running in VMWare and was astonished to see the following pattern on a random memory location:
Who might code this (it's not me!) and for what reason?? Just curious if anyone has seen something like this.
It looks like a rendered mask for a font (each character in a font (typeface+size+style) is rendered once in-memory, then blitted to the output surface) using 8bpp, which suggests you've got font anti-aliasing enabled.
I'm assuming your project involves a GUI, you might be looking at a shared-memory area that GDI uses for storing rasterized fonts.
If not, then this might just be leftover memory from a previous process or OS component that wasn't zeroed before being used by your application.
It's hard to say. Possibly memory used to buffer some fonts (in this case, zeros), or even buffered printer or screen content.
I just read about the "reference device' device type in direct3D.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb219625(v=vs.85).aspx
Does this mean I can develop and test (not performance, just visual result) a Direct3D 11 Application including fancy ShaderLevel5 stuff on any old hardware?
Is there an equivalent for OpenGL?
Yes effectively that IS what the reference driver does. Specifically it is there so that hardware rendering can be compared against it. If the hardware rendering does not equal the reference then this can indicate a driver bug (or an "optimisation").
To my knowledge there is no reference driver for OpenGL, unfortunately.
Does this mean I can develop and test (not performance, just visual result) a Direct3D 11 Application including fancy ShaderLevel5 stuff on any old hardware?
Yes. However, you should expect absolutely horrible performance. You could get about 1 frame per minute for complex pixel shaders (directx 9 reference device), and it can take even longer than that. Needless to say, same shader could work in real-time with hardware acceleration. Reference device weren't made for performance, and if I remember correctly, DirectX SDK states (somewhere) that main purpose of reference device was to allow developers to see if their scene looks the way it should and there are no unexpected driver bugs.
Another problem is that if you're running winxp, there will be no DirectX 10 or 11, reference device or not.
Is there an equivalent for OpenGL?
No. Closest thing is mesa3d, but it isn't OpenGL-certified. 1..2 years ago it could display very different picture when GLSL shaders were involved. It could also crash on shaders with flow control. I haven't used it since. however, when used without GLSL shaders, mesa3d was quite fast and comparable to OpenGL, and was significantly faster han reference device in DirectX 9.
Mesa3d has a software rasterizer. They recently added GL 3.0 support.